Analyse d'Artefact : Fondations de l'Injection de Processus

Danger

Résumé exécutif : l’injection de processus (Process Injection) est une technique d’évasion de défense très répandue (MITRE ATT&CK T1055) par laquelle un processus malveillant force l’exécution de code arbitraire au sein de l’espace d’adressage d’un autre processus légitime en cours d’exécution. En se cachant à l’intérieur de binaires de confiance (comme explorer.exe ou svchost.exe), les acteurs de la menace peuvent contourner les pare-feux applicatifs, échapper aux plateformes de protection des terminaux (EPP) et voler des jetons de sécurité sensibles appartenant au processus victime.

1. Introduction : disque vs mémoire

Avant d’analyser la mécanique de l’injection de processus, les analystes DFIR doivent tracer une frontière stricte entre deux paradigmes d’évasion distincts : les attaques basées sur le disque et celles basées sur la mémoire.

Alors que nous avons précédemment couvert le DLL Hijacking et Sideloading, qui manipule la façon dont le système d’exploitation Windows charge les fichiers depuis le disque au démarrage, l’injection de processus opère presque entièrement dans la RAM au cours de l’exécution (runtime).

• Sideloading de DLL (Disque/Chargeur) : l’attaquant dépose un fichier physique sur le disque et trompe le chargeur Windows (ntdll.dll) pour qu’il l’importe dans un processus légitime lors de son lancement initial.
• Injection de processus (Mémoire/Exécution) : l’attaquant exécute un processus malveillant (l’injecteur) qui force agressivement l’ouverture d’un “handle” (jeton d’accès) vers un processus légitime distinct déjà en cours d’exécution (la cible), et écrit du code malveillant directement dans sa mémoire volatile.

Pourquoi les attaquants injectent-ils du code ?

1. Furtivité et contournement des listes blanches : si un pare-feu ou un EDR est configuré pour n’autoriser que chrome.exe ou explorer.exe à établir des connexions HTTP sortantes, un malware peut injecter sa balise C2 dans chrome.exe afin d’hériter de ses permissions réseau de confiance.
2. Vol d’identifiants : pour voler des mots de passe dans les navigateurs ou extraire des hashs du sous-système de l’autorité de sécurité locale (lsass.exe), les malwares doivent injecter du code dans ces processus spécifiques pour accéder à leurs structures mémoire isolées.
3. Évasion de défense : en terminant le processus malveillant original, la charge utile continue de s’exécuter silencieusement à l’intérieur d’un processus hôte bénin, rompant ainsi la chaîne de filiation des processus.

---

2. Anatomie de la mémoire Windows et abus d’API

Pour comprendre comment se produisent les injections, les analystes doivent d’abord comprendre comment Windows protège les processus.

Les systèmes Windows modernes reposent sur les espaces d’adressage virtuels (VAS - Virtual Address Spaces). Chaque processus en cours d’exécution est isolé ; il “croit” posséder son propre bloc de mémoire contigu et ne peut pas, nativement, lire ou écrire dans la mémoire d’un autre processus.

Pour briser cette isolation, le processus injecteur d’un attaquant doit abuser d’une séquence d’interfaces de programmation applicative (API) légitimes de Windows. L’injection de processus “classique” suit généralement un cycle de vie d’API strict en quatre étapes :

1. Ciblage (OpenProcess) : l’injecteur malveillant appelle l’API OpenProcess, demandant un “Handle” (un ticket d’accès) vers le processus cible (ex: notepad.exe). Il demande des privilèges élevés, spécifiquement PROCESS_VM_WRITE et PROCESS_VM_OPERATION.
2. Allocation (VirtualAllocEx) : une fois le handle obtenu, l’injecteur appelle VirtualAllocEx. Cela force le processus cible à allouer un nouveau bloc de mémoire vide au sein de son propre espace d’adressage. Fait crucial, l’attaquant demande souvent que cette nouvelle mémoire soit marquée comme PAGE_EXECUTE_READWRITE (RWX), ce qui signifie que du code peut y être écrit puis exécuté.
3. Écriture (WriteProcessMemory) : l’injecteur utilise WriteProcessMemory pour copier la charge utile malveillante (un shellcode ou un chemin de DLL) depuis sa propre mémoire vers le nouvel espace RWX alloué à l’intérieur du processus cible.
4. Exécution (CreateRemoteThread) : enfin, l’injecteur appelle CreateRemoteThread. Cette API force le processus cible à générer un nouveau thread (fil d’exécution), pointant le pointeur d’instruction directement sur la charge utile malveillante écrite à l’Étape 3. La charge utile s’exécute désormais sous le couvert du processus légitime.

L’indicateur forensique “RWX”

Astuce

Focus DFIR : les logiciels légitimes ont rarement besoin que des pages mémoire soient marquées simultanément comme inscriptibles (Writable) et exécutables (Executable) — d’où l’acronyme RWX. Le code devrait être exécutable mais non inscriptible, et les données inscriptibles mais non exécutables. Lorsque les outils d’analyse mémoire (comme Volatility) ou les EDR scannent la RAM, la localisation d’une section mémoire anormale marquée comme PAGE_EXECUTE_READWRITE est l’un des indicateurs de la plus haute fidélité signalant qu’une injection de processus a eu lieu.

3. La “trinité classique” de l’injection de processus

Au cours de la dernière décennie, les développeurs de malwares ont itéré sur les API Windows de base pour créer trois techniques d’injection fondamentales. Bien que les EDR modernes les détectent facilement aujourd’hui, leur compréhension est un prérequis obligatoire pour tout analyste DFIR.

A. Injection de DLL classique (Classic DLL Injection)

C’est la forme la plus ancienne et la plus simple d’injection de processus. Au lieu d’écrire une charge utile complète dans le processus cible, l’attaquant écrit simplement le chemin d’accès d’une DLL malveillante (ex: C:\Temp\evil.dll) dans la mémoire de la cible. Il appelle ensuite CreateRemoteThread et le fait pointer vers une API Windows native nommée LoadLibraryA.

• Le résultat : le processus cible est forcé de charger la DLL malveillante depuis le disque, exécutant ainsi sa fonction DllMain.
• Faiblesse forensique : c’est incroyablement bruyant. La DLL malveillante doit physiquement exister sur le disque, et elle est enregistrée en tant que module chargé au sein du processus victime (visible dans des outils comme Process Explorer).

B. Injection de DLL réflective (Reflective DLL Injection - RDI)

Afin de surmonter les limites de l’injection de DLL classique, les attaquants sont passés à l’exécution “sans fichier” (fileless). Lancée par Stephen Fewer et massivement utilisée par des frameworks comme Cobalt Strike et Metasploit, la RDI contourne entièrement le chargeur Windows (Windows Loader).

• Le mécanisme : l’attaquant alloue de la mémoire dans le processus cible et copie l’intégralité de la DLL malveillante directement dans la RAM. Comme la fonction Windows LoadLibrary ne fonctionne qu’avec des fichiers sur le disque, l’attaquant injecte une fonction de “chargeur réflectif” personnalisée aux côtés de la DLL. Ce chargeur personnalisé mappe manuellement la DLL en mémoire, résout ses importations et l’exécute.
• Faiblesse forensique : parce que la DLL a été chargée manuellement par le malware et non par Windows, les pages mémoire contenant la DLL ne sont pas “adossées” (unbacked - elles ne correspondent à aucun fichier légitime sur le disque dur) et sont généralement marquées comme RWX.

C. Évidage de processus (Process Hollowing / RunPE)

Également connue sous le nom de “RunPE”, cette technique ne se contente pas d’injecter du code dans un processus en cours d’exécution ; elle usurpe l’identité d’un binaire légitime pour se cacher à la vue de tous.

1. Création : le malware génère un processus Windows légitime (ex: svchost.exe) dans un état suspendu (SUSPENDED).
2. Évidage (Hollowing) : il utilise l’API NtUnmapViewOfSection pour “évider” (dé-mapper) le code légitime de svchost.exe de son espace mémoire.
3. Remplacement : le malware alloue de la nouvelle mémoire et écrit sa propre charge utile malveillante dans la coquille désormais vide du processus.
4. Reprise : l’attaquant modifie le contexte du thread (registre EIP/RIP) pour pointer vers la charge utile malveillante et relance le thread.

• Le résultat : pour le Gestionnaire des tâches ou un analyste junior, le processus ressemble exactement à un svchost.exe normal. Cependant, le code s’exécutant en mémoire appartient au malware.
• Faiblesse forensique : il existe une divergence flagrante entre le Process Environment Block (PEB), qui affiche le chemin de l’exécutable légitime, et le mappage mémoire réel, qui contient du code exécutable non adossé à un fichier (unbacked).

4. Détection et triage (Blue Team)

La détection de l’injection de processus fondamentale repose sur la capture des appels d’API spécifiques utilisés pour franchir les limites des processus et sur l’analyse des anomalies de la mémoire.

A. Chasse dans la télémétrie : Événement Sysmon 8

Sysmon a spécifiquement conçu l’Événement 8 (CreateRemoteThread) pour intercepter les injections de DLL classiques et réflectives. Il se déclenche chaque fois qu’un processus crée un thread dans un autre processus.

KQL (Sysmon EID 8)

hunt_remote_thread_injection.kql

// Détecte les processus injectant des threads dans des processus système critiques
DeviceEvents
| where ActionType == "CreateRemoteThreadApiCall"
// Se concentrer sur les processus cibles couramment abusés pour l'injection/l'évidage
| where FileName in~ ("svchost.exe", "explorer.exe", "lsass.exe", "winlogon.exe", "notepad.exe")
// Exclure les outils administratifs légitimes connus pour réduire le bruit
| where InitiatingProcessFileName !in~ ("csrss.exe", "wbemprox.exe", "taskmgr.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FileName, ActionType
| sort by TimeGenerated desc

B. Forensique de la mémoire (Volatility 3)

Lors de l’analyse d’un vidage (dump) de RAM, les analystes DFIR recherchent les indicateurs RWX et Unbacked Memory laissés par l’injection de DLL réflective et le Process Hollowing. Le plugin windows.malfind.Malfind de Volatility 3 est explicitement conçu pour scanner les espaces mémoire à la recherche de balises VAD (Virtual Address Descriptor) marquées comme PAGE_EXECUTE_READWRITE qui ne correspondent pas à un fichier mappé sur le disque.

volatility_malfind.sh

# Exécuter malfind pour identifier la mémoire exécutable injectée et non adossée à un fichier
python3 vol.py -f memory_dump.raw windows.malfind

5. Conclusion et évolution des EDR

La “trinité classique” des techniques d’injection de processus a défini le paysage des malwares pendant une décennie. Cependant, les solutions modernes de détection et de réponse des terminaux (EDR) se sont adaptées. En utilisant le “User-Mode Hooking” (l’interception des appels aux API de ntdll.dll comme NtAllocateVirtualMemory et NtCreateThreadEx), les EDR peuvent bloquer instantanément ces techniques fondamentales.

Pour survivre en 2026, les menaces persistantes avancées (APT) ont été contraintes d’évoluer, abandonnant la mémoire RWX et le CreateRemoteThread au profit de techniques hyper-furtives manipulant les structures profondes du noyau.

Comment les acteurs de la menace contournent-ils les scanners de mémoire des EDR modernes en utilisant le Module Stomping, le Header Clearing et le Memory Mirroring ?

👉 Lire le guide avancé : Injection de Code Next-Gen et Évasion EDR

---

Références et lectures complémentaires

• MITRE ATT&CK : Process Injection (T1055)
• Palo Alto Networks : What Is Process Injection?
• MCSI Library : Malware Injection Techniques: Introduction
• Artefact lié : Analyse de la télémétrie Sysmon