Analyse TTP : Injection de Code Next-Gen et Évasion EDR

Danger

Résumé exécutif : la “trinité classique” de l’injection de processus (injection de DLL classique, injection de DLL réflective et Process Hollowing basique) est effectivement morte dans les environnements d’entreprise. Les solutions modernes de détection et réponse des terminaux (EDR) utilisant le “User-Mode Hooking” et l’Event Tracing for Windows - Threat Intelligence (ETW-Ti) interceptent instantanément ces techniques héritées. Pour survivre, les menaces persistantes avancées (APT) et les opérateurs de ransomwares modernes ont évolué. L’injection de code “Next-Gen” repose sur la manipulation de structures profondes du noyau, l’exploitation des objets de section (Section Objects) pour le miroir mémoire (Memory Mirroring), l’écrasement de modules légitimes (Module Stomping) et l’effacement minutieux des artefacts forensiques de la RAM pour mettre en échec les scanners de mémoire.

1. Introduction : la mort de CreateRemoteThread

Comme établi dans notre guide sur les Fondations de l’Injection de Processus, l’injection héritée repose sur une chaîne d’API hautement prévisible : OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread.

En 2026, s’appuyer sur cette chaîne est un suicide opérationnel pour un acteur de la menace. Les EDR modernes la neutralisent via deux mécanismes principaux :

1. User-Mode Hooking (Détournement d’API) : les agents EDR injectent leurs propres DLL dans chaque processus en espace utilisateur. Ils placent des crochets (hooks) en ligne sur les fonctions NTAPI de bas niveau dans ntdll.dll (ex: NtAllocateVirtualMemory, NtWriteVirtualMemory, NtCreateThreadEx). Avant que le noyau Windows n’exécute la requête de l’attaquant, l’EDR inspecte les arguments.
2. Le stigmate du RWX : les EDR scrutent de très près les pages mémoire allouées avec les protections PAGE_EXECUTE_READWRITE (RWX). Si un EDR détecte un appel à WriteProcessMemory poussant des données dans un segment de mémoire marqué RWX d’un processus distant, l’action est bloquée et une alerte est générée.

Pour contourner ces défenses, les acteurs de la menace doivent atteindre deux objectifs : allouer de la mémoire sans déclencher les hooks comportementaux, et s’assurer que la charge utile s’exécute sans dépendre de régions mémoire RWX anormales.

2. Évasion des scanners de mémoire : Header Clearing & Mirroring

Une fois qu’une charge utile est injectée, elle fait face à un second ennemi redoutable : le scanner de mémoire continu de l’EDR. Les EDR balaient périodiquement la RAM des processus en cours d’exécution, utilisant des règles YARA pour chasser des séquences d’octets malveillantes ou des structures Portable Executable (PE) orphelines.

Les adversaires emploient des manipulations de mémoire avancées pour aveugler ces scanners.

A. Header Clearing (Effacement d’en-tête PE)

Lorsqu’une charge utile (comme une balise Cobalt Strike) est chargée de manière réflective en mémoire, ses en-têtes structurels (les octets magiques MZ, le stub DOS et les en-têtes PE/COFF) sont mappés dans la RAM avec le code exécutable.

Les scanners de mémoire et les outils DFIR (comme le plugin malfind de Volatility) chassent explicitement ces en-têtes MZ (0x4D5A) résidant dans des régions de mémoire “non adossées” (unbacked - une mémoire non liée à un fichier légitime sur le disque).

La technique d’évasion : pour déjouer cela, les chargeurs (loaders) avancés utilisent une technique connue sous le nom de Header Clearing. Une fois que la charge utile a été mappée avec succès en mémoire et que ses importations sont résolues, le chargeur écrase dynamiquement ses propres en-têtes PE avec des octets nuls (0x00) ou des données aléatoires inutiles. Pour un scanner de mémoire EDR s’appuyant sur des signatures structurelles, la région mémoire malveillante apparaît désormais comme un bloc de données ambiguës et non structurées, réduisant considérablement le taux de détection.

B. Memory Mirroring (Mappage d’objet de section)

Afin d’éviter l’API WriteProcessMemory hautement surveillée, les acteurs de la menace se sont tournés vers un mécanisme de communication inter-processus (IPC) natif de Windows : les objets de section (Section Objects). Cette technique est souvent appelée “Memory Mirroring” (miroir mémoire) ou “Mapping Injection”.

Au lieu d’injecter de force des données dans un processus distant, l’attaquant crée un pont de mémoire partagée.

1. Création de section : le processus injecteur malveillant appelle NtCreateSection pour créer un objet de section mémoire adossé au fichier d’échange (page file).
2. Mappage local (RW) : l’injecteur mappe une vue de cette section dans son propre espace d’adressage en utilisant NtMapViewOfSection avec des permissions PAGE_READWRITE (RW).
3. Copie de la charge utile : l’injecteur écrit le shellcode malveillant dans cette vue locale. Puisque l’injecteur modifie sa propre mémoire, les hooks EDR sur les écritures inter-processus ne sont pas déclenchés.
4. Mappage distant (RX) : l’injecteur appelle NtMapViewOfSection une seconde fois, mais mappe cette fois le même objet de section dans l’espace d’adressage du processus victime cible, en demandant des permissions PAGE_EXECUTE_READ (RX).

Le résultat forensique : la charge utile malveillante apparaît comme par magie dans l’espace mémoire du processus cible. L’attaquant ayant séparé la phase “d’écriture” (RW) de la phase “d’exécution” (RX), la mémoire n’est jamais marquée comme étant le très suspect RWX. De plus, la charge utile ayant été partagée via le gestionnaire de mémoire du noyau plutôt qu’explicitement écrite via WriteProcessMemory, les hooks EDR traditionnels en espace utilisateur sont complètement contournés.

Astuce

Focus de chasse DFIR : bien que le Memory Mirroring mette en échec les hooks d’API de base, les analystes DFIR peuvent toujours le détecter grâce à une forensique mémoire avancée. L’analyse des Virtual Address Descriptors (VAD) du processus victime révélera des régions de mémoire marquées comme PAGE_EXECUTE_READ qui sont dépourvues d’un fichier de support légitime sur le disque. Même avec le Header Clearing appliqué, la présence de mémoire exécutable et non adossée (ou adossée uniquement au pagefile) reste un indicateur de compromission de haute fidélité.

3. Écrasement de module (Module Stomping)

Bien que le miroir mémoire (Memory Mirroring) évite les permissions RWX, il laisse derrière lui de la mémoire “non adossée” (unbacked memory) — des régions de mémoire exécutables qui ne correspondent à aucun fichier physique sur le disque dur. Les scanners de mémoire avancés scrutent minutieusement les pages exécutables non adossées.

Pour atteindre la furtivité ultime, les adversaires utilisent une technique appelée écrasement de module (Module Overwriting), également connue sous le nom de Module Stomping ou DLL Hollowing. L’objectif est de cacher la charge utile malveillante à l’intérieur d’une région mémoire qui est légitimement “adossée” à une DLL Microsoft hautement fiable et signée numériquement.

Le flux d’exécution du “Stomping”

Au lieu d’allouer de la nouvelle mémoire, l’attaquant réutilise de la mémoire existante.

1. Forcer le chargement d’une bibliothèque : l’injecteur malveillant force le processus cible à charger une DLL Microsoft légitime mais rarement utilisée (ex: xpsprint.dll ou amsi.dll) en utilisant LoadLibrary ou NtLoadDriver.
2. Modification des permissions : l’injecteur localise la section .text (le segment de code exécutable) de cette DLL nouvellement chargée en mémoire. Il utilise VirtualProtectEx pour changer temporairement les permissions de la mémoire de RX (Lecture-Exécution) à RW ou RWX.
3. L’écrasement (The Stomp) : l’injecteur écrit sa charge utile malveillante directement par-dessus le code Microsoft légitime et signé.
4. Restauration : l’injecteur appelle à nouveau VirtualProtectEx pour restaurer les permissions de la mémoire à RX.
5. Exécution : la charge utile est exécutée.

Le résultat forensique : si un EDR ou un scanner de mémoire examine le processus victime, il voit une page mémoire marquée RX (normale) qui pointe directement vers C:\Windows\System32\xpsprint.dll sur le disque (adossée et hautement fiable). Le scanner suppose que la mémoire contient le code Microsoft légitime et passe à autre chose. Le malware opère en toute furtivité.

Astuce

Focus de chasse DFIR : pour détecter le Module Stomping, les analystes ne peuvent pas s’appuyer sur de simples vérifications de métadonnées. Les intervenants sur incident doivent effectuer une comparaison mémoire-disque. En vidant la mémoire vive de la DLL suspecte et en comparant le hash de sa section .text avec le hash du fichier physique résidant sur le disque dur, les analystes peuvent détecter la falsification. Si le code en mémoire diverge significativement du binaire sur disque, le module a subi un écrasement (stomped).

4. Masquage du PEB et détournement de thread (Thread Hijacking)

Une fois le code malveillant solidement caché en mémoire (via Stomping ou Mirroring), l’attaquant doit l’exécuter. Comme nous l’avons établi, l’appel à CreateRemoteThread génère une télémétrie hautement visible (Événement Sysmon 8). Les adversaires contournent cela en détournant des threads qui existent déjà.

A. Détournement d’exécution de thread

Au lieu de créer un nouveau thread, l’attaquant prend le contrôle, de manière parasitaire, d’un thread bénin existant au sein du processus cible.

1. Ciblage : l’injecteur énumère les threads s’exécutant à l’intérieur du processus victime et en sélectionne un (de préférence un thread inactif ou en sommeil) à l’aide de OpenThread.
2. Suspension : l’attaquant interrompt l’exécution du thread en utilisant SuspendThread.
3. Manipulation du contexte : l’attaquant récupère le contexte d’exécution du thread via GetThreadContext. Fait crucial, il modifie le registre du pointeur d’instruction (le registre RIP sur les systèmes x64) pour qu’il pointe vers l’adresse mémoire où la charge utile malveillante a été injectée.
4. Reprise : l’attaquant applique le contexte modifié avec SetThreadContext et réveille le thread avec ResumeThread.

Parce qu’aucun nouveau thread n’a été créé, les hooks d’API surveillant la création de threads restent totalement silencieux, aveuglant le SOC face à l’exécution.

B. Masquage du PEB (L’art de mentir au Gestionnaire des tâches)

Pour tromper davantage les analystes et les agents EDR de base, les acteurs de la menace manipulent le Process Environment Block (PEB).

Le PEB est une structure de données en mode utilisateur (user-mode) dans Windows qui contient des informations critiques sur un processus, notamment ses modules chargés, le nom du processus et les arguments de la ligne de commande. Puisqu’il réside dans l’espace utilisateur, il est entièrement lisible et inscriptible par le processus lui-même (ou une charge utile injectée).

Les attaquants modifient la structure RTL_USER_PROCESS_PARAMETERS au sein du PEB. Par exemple, un processus malveillant pourrait réécrire ses champs ImagePathName et CommandLine dans le PEB pour imiter C:\Windows\System32\svchost.exe -k netsvcs.

Si un analyste junior utilise le Gestionnaire des tâches ou Process Explorer, l’outil lit le PEB et affiche le nom et la ligne de commande factices et bénins.

Danger

La contre-mesure DFIR : ne faites jamais confiance aux structures en mode utilisateur lors d’une intrusion avancée. Bien que le PEB puisse être modifié par l’attaquant, le noyau conserve la vérité absolue dans le bloc EPROCESS, qui réside dans la mémoire isolée du noyau. Lors de l’utilisation de Volatility, la comparaison de la ligne de commande rapportée par le PEB avec la ligne de commande consignée par la télémétrie du noyau ou ETW-Ti révélera instantanément la tentative de masquage.

5. Investigation forensique avancée (chasser les fantômes)

Lorsque les acteurs de la menace contournent les hooks EDR en mode utilisateur, utilisent le miroir mémoire pour éviter les pages RWX et écrasent des modules légitimes pour s’assurer que la mémoire reste adossée à un fichier, les outils de triage à chaud (live triage) traditionnels deviennent aveugles. Les analystes DFIR doivent plonger dans la forensique mémoire profonde et la télémétrie au niveau du noyau pour chasser ces “fantômes”.

A. Forensique de la mémoire : au-delà de malfind

Dans l’analyse mémoire standard, le plugin windows.malfind de Volatility 3 est l’outil de prédilection. Il scanne l’arborescence des VAD (Virtual Address Descriptor) à la recherche de régions de mémoire exécutables mais non adossées (unbacked). Cependant, face au Module Stomping, malfind échouera très probablement car la page mémoire écrasée est bel et bien adossée à une DLL légitime sur le disque.

Pour détecter les injections avancées, les analystes doivent scruter l’arborescence VAD à l’aide de windows.vadinfo et effectuer des vérifications croisées :

1. Mémoire privée vs mappée : investiguez les sections de mémoire qui sont adossées à un fichier mais qui ont été modifiées. Lorsqu’un attaquant écrase un module, le système d’exploitation effectue une opération de copie sur écriture (Copy-on-Write ou CoW), transformant le type de mémoire de MEM_MAPPED à MEM_PRIVATE. Une DLL Microsoft signée résidant dans une mémoire exécutable MEM_PRIVATE est une alerte rouge absolue.
2. Comparaison de hash mémoire-disque : extrayez la section .text en mémoire de la DLL suspectée et hachez-la. Extrayez la DLL physique depuis le disque et hachez sa section .text. Une divergence confirme que le module a été écrasé ou patché en cours d’exécution.
3. Analyse des threads : utilisez les plugins windows.pslist et windows.threads. Recherchez les threads dont l’adresse de départ pointe vers un décalage (offset) inhabituel au sein d’un module, ou des threads s’exécutant complètement en dehors des modules mappés connus.

B. L’œil du noyau : ETW-Ti

Alors que les attaquants maîtrisaient le “Unhooking” (décharger les hooks en mode utilisateur de l’EDR présents dans ntdll.dll et recharger une copie fraîche et non modifiée depuis le disque), Microsoft a introduit une source de télémétrie révolutionnaire : Event Tracing for Windows - Threat Intelligence (ETW-Ti).

Contrairement aux hooks en espace utilisateur, ETW-Ti opère entièrement au sein du noyau Windows (ntoskrnl.exe). Les acteurs de la menace opérant dans l’espace utilisateur (Ring 3) ne peuvent ni décrocher (unhook) ni contourner les capteurs ETW-Ti sans déployer préalablement un pilote noyau vulnérable (BYOVD) pour s’élever au niveau Ring 0.

ETW-Ti fournit aux EDR une visibilité brute et inaltérée sur les API exactes utilisées dans les injections avancées, telles que :

• NtAllocateVirtualMemory (allocations inter-processus)
• NtWriteVirtualMemory (écritures inter-processus)
• NtSetContextThread (détournement de thread)

6. Détection et Threat Hunting

Lors de la chasse aux techniques d’injection Next-Gen dans un SIEM, les analystes doivent pivoter de la simple création de processus (Événement 4688) vers les appels d’API d’accès à la mémoire inter-processus et de manipulation de threads générés par ETW-Ti (souvent remontés dans Defender XDR ou l’Événement Sysmon 10).

KQL (Defender XDR / ETW-Ti)

hunt_thread_hijacking.kql

// Détecte la manipulation du contexte d'un thread (Thread Hijacking) via la télémétrie ETW-Ti
DeviceEvents
| where ActionType in~ ("SetThreadContextApiCall", "QueueUserApcApiCall")
// Filtrer les modifications au sein du même processus (les attaquants ciblent généralement un processus distant)
| where InitiatingProcessId != TargetProcessId
// Se concentrer sur les processus cibles couramment abusés pour cacher des threads malveillants
| where TargetProcessName in~ ("svchost.exe", "explorer.exe", "spoolsv.exe", "lsass.exe", "winlogon.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, TargetProcessName, ActionType, InitiatingProcessCommandLine
| sort by TimeGenerated desc

Sigma (Sysmon EID 10)

sigma_suspicious_process_access.yaml

title: Accès inter-processus suspect (Injection potentielle)
id: 4d5e6f7a-8b9c-0d1e-2f3a-4b5c6d7e8f9a
status: experimental
description: Détecte lorsqu'un processus ouvre un handle hautement privilégié vers un processus système critique, souvent le précurseur d'un Module Stomping ou d'un Thread Hijacking.
logsource:
    category: process_access
    product: windows
detection:
    selection:
        # Événement Sysmon 10
        TargetImage|endswith:
            - '\svchost.exe'
            - '\explorer.exe'
            - '\spoolsv.exe'
        # Le masque d'accès 0x1F0FFF correspond à PROCESS_ALL_ACCESS
        # 0x1400 correspond à PROCESS_QUERY_INFORMATION + PROCESS_VM_WRITE
        GrantedAccess|contains|any:
            - '0x1F0FFF'
            - '0x1400'
    filter_legit:
        SourceImage|startswith: 'C:\Windows\System32\'
    condition: selection and not filter_legit
level: high
tags:
    - attack.defense_evasion
    - attack.privilege_escalation
    - attack.t1055

7. Conclusion

La course à l’armement entre les acteurs de la menace et les plateformes EDR a poussé l’injection de processus hors des simples charges utiles bruyantes basées sur le disque vers un domaine de sophistication extrême en mémoire.

En maîtrisant le Memory Mirroring, le Header Clearing, le Module Stomping et le Thread Hijacking, les adversaires parviennent à contourner la grande majorité des contrôles de sécurité en espace utilisateur. Pour les intervenants sur incident et les Threat Hunters, se fier uniquement aux alertes EDR de base n’est plus suffisant. Sécuriser l’entreprise moderne exige une compréhension profonde de l’architecture de la mémoire Windows, une maîtrise de la forensique mémoire brute (Volatility), et l’ingestion d’une télémétrie de niveau noyau (ETW-Ti) pour chasser les fantômes cachés dans la machine.

---

Sources et références

• ACM / arXiv (2025/2026) : Advanced Process Injection and Memory Evasion Techniques (2403.06428, 2512.22043, 2512.21818).
• Conand.me : Deep Dive into Code Injection (2023)
• MCSI Library : Malware Injection Techniques: Process Hollowing
• TechSpot : New Code Injection Method Avoids Malware Detection
• Analyse liée : Fondations de l’injection de processus et trinité classique
• Analyse liée : Architecture du DLL Hijacking et Sideloading