Injection de processus¶

ID : crt MITRE ATT&CK : T1055.003 - Détournement de l'exécution des threads

Comment ça marche : Alloue de la mémoire dans le processus distant avec VirtualAllocEx(PAGE_READWRITE), copie le shellcode via WriteProcessMemory, modifie la protection en PAGE_EXECUTE_READ via VirtualProtectEx, puis crée un thread distant à l'adresse du shellcode avec CreateRemoteThread. Tous les appels API sont acheminés via BeaconGate lorsqu'ils sont activés.

Chaîne d'appels API :

1. VirtualAllocEx(processHandle, PAGE_READWRITE)
2. WriteProcessMemory(processHandle, shellcode)
3. VirtualProtectEx(processHandle, PAGE_EXECUTE_READ)
4. CreateRemoteThread(processHandle, shellcodeAddr)

Artefacts médico-légaux :

• Événement Sysmon 8 : CreateRemoteThread détecté
• Événement Sysmon 10 : ProcessAccess avec PROCESS_VM_WRITE
• Mémoire : transition de protection RW -> RX dans le processus cible
• ETW : création de thread à partir d'un processus parent inattendu

Limites : Technique la plus surveillée. Chaque produit EDR majeur détecte CreateRemoteThread des appelants non standard. À utiliser uniquement dans des environnements de laboratoire ou lorsque la détection n'est pas un problème.

Prend en charge InjectByPID : Oui - ouvre le processus par PID, injecte, ferme le handle.

Prend en charge InjectByHandle : Oui - injection directe avec le handle de processus existant.

ID : ntmap MITRE ATT&CK: T1055.012 - Procédé Creux (variante)

Comment ça marche : Crée une section de mémoire partagée sauvegardée par le fichier d'échange à l'aide de NtCreateSection, mappe une vue inscriptible dans le processus de beacon (NtMapViewOfSection avec PAGE_READWRITE), copie le shellcode dans la vue locale, mappe une vue exécutable dans le processus cible (PAGE_EXECUTE_READ), démappe la vue locale, puis s'exécute via RtlCreateUserThread.

Chaîne d'appels API :

1. NtCreateSection(PAGE_EXECUTE_READWRITE) -- protection maximale de la section, pas protection de la page
2. NtMapViewOfSection(local, PAGE_READWRITE) -- vue inscriptible dans le beacon
3. memcpy vers la vue locale
4. NtMapViewOfSection(remote, PAGE_EXECUTE_READ) -- vue exécutable dans la cible
5. NtUnmapViewOfSection(local) -- nettoyage
6. RtlCreateUserThread(remote, shellcodeAddr)

Artefacts médico-légaux :

• Création d'objet de section (visible dans le gestionnaire d'objets du noyau)
• Vue mappée dans le processus cible (pas d'artefact VirtualAllocEx)
• Création de thread via RtlCreateUserThread (différent de CRT dans ETW)

Limitations : Les objets de section peuvent être visibles par les analyseurs de mémoire avancés. La protection maximale de la section est PAGE_EXECUTE_READWRITE (requis pour la technique), bien que les protections réelles des pages ne soient jamais RWX.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : setthreadctx MITRE ATT&CK : T1055.003 - Détournement de l'exécution des threads

ID : queueapc MITRE ATT&CK : T1055.004 - Appel de procédure asynchrone

Comment ça marche : Alloue et écrit le shellcode, trouve le thread principal du processus enfant suspendu, ouvre le thread et met en file d'attente un APC pointant vers l'adresse du shellcode via QueueUserAPC. Lorsque l'appelant reprend le thread, l'APC se déclenche avant le point d'entrée normal du thread - c'est le modèle « early-bird ».

Chaîne d'appels API :

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. OpenThread(THREAD_SET_CONTEXT)
3. QueueUserAPC(shellcodeAddr, threadHandle)
4. L'appelant appelle ResumeThread -- APC se déclenche en premier

Artefacts médico-légaux :

• Mémoire : transition RW -> RX dans le processus cible
• Modification de la file d'attente APC (visible dans les structures du noyau)
• Aucun artefact CreateRemoteThread
• Early-bird : le shellcode s'exécute avant le point d'entrée du processus

Limitations : Fonctionne de manière fiable uniquement avec fork-and-run (modèle de lève-tôt). Pour InjectByPID, la technique revient à CRT car APC sur les threads existants nécessite un état d'attente pouvant être alerté (SleepEx, WaitForMultipleObjectsEx), qui n'est pas fiable pour les processus arbitraires.

Prend en charge InjectByPID : Revient au CRT. Prend en charge InjectByHandle : Oui (fork-and-run uniquement).

ID : rtlthread MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Allocation de mémoire et écriture standard, puis crée un thread distant en utilisant RtlCreateUserThread de ntdll au lieu de CreateRemoteThread de kernel32. Cela contourne les hooks du mode utilisateur que les produits EDR placent sur les exportations kernel32.dll.

Chaîne d'appels API :

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. RtlCreateUserThread(processHandle, shellcodeAddr)

Artefacts médico-légaux :

• Mémoire : transition RW -> RX dans le processus cible
• Création de thread via l'API NT (événement ETW différent du kernel32 CRT)
• Adresse de début du thread dans la mémoire du processus distant

Limitations : Bien qu'elle contourne les hooks kernel32, l'instrumentation ETW au niveau du noyau enregistre toujours la création du thread. Moins évasive que les techniques qui évitent complètement la création de threads.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : selfinject MITRE ATT&CK : T1055 - Injection de procédé

ID : udrl MITRE ATT&CK : T1620 - Chargement de code réfléchissant

Comment ça marche : L'opérateur fournit un shellcode de chargeur réfléchissant personnalisé via un script d'agresseur (SetUDRL()). Le chargeur est ajouté au début de le payload du beacon. Lors de l'injection, le payload combinée (chargeur + beacon) est écrite dans le processus cible. Le thread distant démarre au point d'entrée du chargeur, qui gère son propre mappage PE, sa résolution d'importation et sa relocalisation - en contournant complètement la détection LoadLibrary standard.

Chaîne d'appels API :

1. Ajouter le shellcode du chargeur à le payload du beacon
2. VirtualAllocEx(PAGE_READWRITE) via BeaconGate
3. WriteProcessMemory(loader + beacon) via BeaconGate
4. Suivre les régions dans BUD (Beacon User Data) pour le masque de sommeil
5. VirtualProtectEx(PAGE_EXECUTE_READ) via BeaconGate
6. CreateRemoteThread(loaderAddr) via BeaconGate

Artefacts médico-légaux :

• Mémoire exécutable non sauvegardée (pas de fichier correspondant sur le disque)
• Anomalies d'en-tête PE (le chargeur personnalisé peut omettre/modifier les en-têtes)
• La disposition de la mémoire diffère du chargeur PE standard
• Contrôlé par l'opérateur : les artefacts varient selon l'implémentation du chargeur

Limitations : Non enregistré par défaut - disponible uniquement lorsque l'opérateur fournit le shellcode du chargeur au moment de l'exécution via SetUDRL(). La qualité et la furtivité du chargeur dépendent entièrement de la mise en œuvre de l'opérateur. Si le chargeur nécessite RWX pour l'auto-modification, la configuration UseRWX peut être définie, mais cela dégrade OPSEC.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : obfsetthreadctx MITRE ATT&CK : T1055.003 - Détournement de l'exécution des threads

Comment ça marche : Contrairement au SetThreadContext standard qui détourne un thread existant, cette technique crée un NOUVEAU thread à une adresse de fonction légitime (par exemple, ntdll!RtlUserThreadStart+0x21) en utilisant CreateRemoteThread avec CREATE_SUSPENDED. L'adresse de début du thread semble légitime pour les outils EDR qui analysent les origines des threads. Après la création, GetThreadContext capture l'état complet du registre, RIP est modifié pour pointer vers le shellcode, SetThreadContext applique la modification et ResumeThread exécute le shellcode.

Chaîne d'appels API :

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx
2. Résoudre ntdll!RtlUserThreadStart+0x21 dans le processus distant
3. CreateRemoteThread(processHandle, legitimateAddr, CREATE_SUSPENDED)
4. GetThreadContext(threadHandle, CONTEXT_FULL)
5. Définir ctx.Rip = shellcodeAddr
6. SetThreadContext(threadHandle, ctx)
7. ResumeThread(threadHandle)

Artefacts médico-légaux :

• Sujet créé à une adresse légitime basée sur une image (plus difficile à détecter)
• Mémoire : transition RW -> RX dans le processus cible
• Modification du contexte du thread (détectable via ETW)
• Appel CreateRemoteThread présent, mais l'adresse de départ semble légitime

Limitations : Nécessite ntdll ou kernel32 pour une résolution d'adresses inter-processus fiable (ASLR est par démarrage pour les DLL système, donc les adresses correspondent entre les processus). Les autres modules ne sont pas pris en charge pour l'adresse de départ.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : cloneprocess MITRE ATT&CK: T1055.012 - Procédé Creux (variante)

Comment ça marche : Utilise RtlCloneUserProcess pour créer une copie d'un processus cible avec un thread principal suspendu. Le shellcode est écrit dans le clone à l'aide d'une allocation standard, puis un appel QueueUserAPC cible le thread principal du clone. Lorsque ResumeThread est appelé, l'APC se déclenche et le shellcode s'exécute dans le processus cloné. Cela évite de créer des threads distants dans les processus existants.

Chaîne d'appels API :

1. RtlCloneUserProcess(CREATE_SUSPENDED | NO_SYNCHRONIZE)
2. Extraire les poignées de processus/thread de clonage
3. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx dans le clone
4. QueueUserAPC(shellcodeAddr, cloneThread)
5. ResumeThread(cloneThread)

Artefacts médico-légaux :

• Création de clone de processus (appel RtlCloneUserProcess inhabituel)
• Mémoire : transition RW -> RX dans un processus cloné
• Modification de la file d'attente APC sur le thread principal du clone
• Aucun artefact CreateRemoteThread dans les processus existants

Limitations : Nécessite Windows 10+ (disponibilité RtlCloneUserProcess). Revient au CRT sur les anciennes versions. Le processus cloné est une copie du processus en cours, ce qui peut être suspect si le beacon s'exécute comme un exécutable inhabituel.

Prend en charge InjectByPID : Oui (ouvre le processus, puis clone). Prend en charge InjectByHandle : Oui.

ID : tpdirect MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Basé sur la recherche PoolParty de SafeBreach Labs. Alloue le shellcode dans le processus distant, puis crée une fausse structure TP_DIRECT avec son pointeur de rappel au décalage 0x08 pointant vers l'adresse du shellcode. Le shellcode (RX) et la structure TP_DIRECT (RW) sont écrits dans le processus cible. Un thread distant est créé pour s'exécuter via le chemin de rappel du pool de threads, faisant apparaître l'exécution comme un élément de travail légitime du pool de threads.

Chaîne d'appels API :

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
2. Construire une fausse structure TP_DIRECT (rappel = adresse du shellcode)
3. VirtualAllocEx(PAGE_READWRITE) pour la structure TP_DIRECT
4. WriteProcessMemory (TP_DIRECT vers la cible)
5. CreateRemoteThread(shellcodeAddr, tpDirectAddr) -- répartition du pool de threads

Artefacts médico-légaux :

• Mémoire : transition RW -> RX pour le shellcode
• Allocation RW supplémentaire pour la fausse structure TP_DIRECT
• Création de threads à distance ciblant l'infrastructure du pool de threads
• L'exécution du rappel du pool de threads apparaît comme une activité de travail légitime

Limitations : La disposition de la structure TP_DIRECT est spécifique à la version (rappel au décalage 0x08 sous Windows 10/11 x64). Peut tomber en panne sur les futures versions de Windows si la disposition de la structure interne change.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : earlycascade MITRE ATT&CK: T1055.012 - Procédé Creux (variante)

ID : tpstartroutinestub MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Basé sur la variante 7 de PoolParty (SafeBreach Labs). Crée une fausse structure TP_WORK dont le pointeur CleanupGroupMember.Callback (au décalage 0x40) pointe vers le shellcode. Le champ Task LIST_ENTRY (au décalage 0x20) est initialisé en tant que liste à double lien auto-référencée pour éviter les plantages. La structure est écrite dans le processus cible et un thread distant est créé avec le shellcode comme point d'entrée et le pointeur TP_WORK comme paramètre, simulant la façon dont TppWorkerThread distribue les éléments de travail via TpStartRoutineStub.

Chaîne d'appels API :

1. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
2. Construisez une fausse structure TP_WORK (0x68 octets) :
   • Décalage 0x20 : tâche LIST_ENTRY (Flink/Blink auto-référencé)
   • Décalage 0x40 : CleanupGroupMember.Callback = adresse du shellcode
3. VirtualAllocEx(PAGE_READWRITE) pour la structure TP_WORK
4. WriteProcessMemory (TP_WORK vers la cible)
5. CreateRemoteThread(shellcodeAddr, tpWorkAddr) -- répartition des travailleurs

Artefacts médico-légaux :

• Mémoire : transition RW -> RX pour le shellcode
• Allocation RW supplémentaire pour la fausse structure TP_WORK
• Création de threads à distance ciblant l'infrastructure du pool de threads
• L’exécution de l’élément de travail du pool de threads apparaît comme une activité de travail légitime

Limitations : La disposition de la structure TP_WORK est spécifique à la version (rappel au décalage 0x40, tâche au décalage 0x20 sous Windows 10/11 x64). Contrairement à tpdirect qui manipule les structures de pool existantes, cette technique crée de nouveaux éléments de travail, qui peuvent être détectables par une surveillance avancée en mode noyau.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : modulestomp MITRE ATT&CK : T1055.001 - Injection de bibliothèque de liens dynamiques (variante)

ID : dllinject MITRE ATT&CK : T1055.001 - Injection de bibliothèque de liens dynamiques

Comment ça marche : Convertit une DLL en shellcode indépendant de la position à l'aide de la technique sRDI (Shellcode Reflective DLL Injection). Le stub de shellcode gère le mappage PE, la résolution d’importation et la relocalisation entièrement en mémoire – aucun appel LoadLibrary n’est effectué. Le shellcode converti est ensuite injecté à l'aide de la technique d'injection par défaut (CRT).

Chaîne d'appels API :

1. Valider l'en-tête PE (vérification MZ)
2. Convertir la DLL en shellcode via sRDI
3. Injecter le shellcode à l'aide de l'injecteur par défaut (InjectByPID)

Artefacts médico-légaux :

• Mémoire exécutable non sauvegardée (DLL mappée sans LoadLibrary)
• L'en-tête PE peut être présent en mémoire (détectable par les scanners de mémoire)
• Les artefacts d'injection dépendent de la technique sous-jacente (par défaut : CRT)

Limitations : La DLL est spécifiée par l'opérateur via la commande dllinject. La conversion sRDI ajoute un stub de shellcode qui gère le chargement réfléchissant. La technique d'injection sous-jacente est toujours celle par défaut (CRT) et ne peut pas être remplacée pour l'injection de DLL.

Prend en charge InjectByPID : Oui (via l'injecteur par défaut après la conversion sRDI). Prend en charge InjectByHandle : Non (commande autonome uniquement).

ID : threadless MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Accroche une fonction exportée dans le processus cible en écrivant un trampoline (enregistrer les registres + appeler le shellcode + jmp à la fonction d'origine) sur le point d'entrée de la fonction. Lorsque le processus cible appelle naturellement la fonction hookée, le trampoline redirige l'exécution vers le shellcode. Aucun thread n'est jamais créé dans le processus cible - l'exécution s'appuie sur les threads existants. Cible de hook par défaut : ntdll!RtlExitUserProcess.

Chaîne d'appels API :

1. Résoudre l'adresse de fonction exportée dans un processus distant
2. Lire les octets de fonction d'origine (pour le retour du trampoline)
3. VirtualAllocEx (RW) pour shellcode + trampoline
4. Construire un trampoline : pousser les registres, appeler le shellcode, restaurer les registres, jmp original
5. WriteProcessMemory (shellcode + trampoline)
6. VirtualProtectEx (RW -> RX)
7. WriteProcessMemory pour écraser l'entrée de fonction avec jmp sur le trampoline

Artefacts médico-légaux :

• Prologue de fonction modifié dans le processus cible (détectable par des contrôles d'intégrité du code)
• Mémoire : transition RW -> RX pour l'allocation du shellcode
• Aucun artefact CreateRemoteThread ou APC
• Aucun nouvel événement de création de thread (Sysmon Event 8 absent)

Limitations : La fonction hookée doit être appelée par le processus cible pour que le shellcode puisse s'exécuter. Le timing n’est pas déterministe. La cible par défaut RtlExitUserProcess se déclenche à la sortie du processus, ce qui peut ne pas être immédiat. Choisissez une exportation fréquemment appelée pour un déclenchement plus rapide.

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : hollowing MITRE ATT&CK : T1055.012 - Processus de creusement

Comment ça marche : Crée un nouveau processus en état suspendu (CREATE_SUSPENDED | CREATE_NO_WINDOW), puis remplace sa mémoire image par un shellcode. Le RIP du thread principal est redirigé vers le shellcode via SetThreadContext et le thread reprend. Le shellcode s'exécute comme le fil principal d'un processus apparemment légitime. Processus sacrificiel par défaut : svchost.exe.

Chaîne d'appels API :

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext(CONTEXT_FULL) sur le fil principal
4. Définir ctx.Rip = shellcodeAddr
5. SetThreadContext(mainThread, ctx)
6. ResumeThread(mainThread)

Artefacts médico-légaux :

• Création de processus suspendu (indicateur CREATE_SUSPENDED)
• Modification du contexte du thread sur le thread principal
• Mémoire : transition RW -> RX en processus creux
• Incompatibilité d'image de processus (le contenu de la mémoire ne correspond pas au binaire du disque)

Limitations : Les produits EDR qui comparent la mémoire de processus à l'image sur disque détecteront la non-concordance. Le processus sacrificiel peut être configuré via les paramètres d'apparition. Si l’injection échoue, le processus suspendu est terminé pour éviter les orphelins.

Prend en charge InjectByPID : Oui (crée un nouveau processus suspendu). Prend en charge InjectByHandle : Oui.

ID : poolparty_workitem MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Basé sur la recherche PoolParty de SafeBreach Labs. Localise le handle d'usine de travail du pool de threads du processus cible via NtQuerySystemInformation, puis insère un faux élément TP_WORK pointant vers le shellcode. Lorsque le pool de threads distribue l'élément de travail suivant, le shellcode s'exécute en tant que rappel légitime du travailleur du pool de threads.

Chaîne d'appels API :

1. NtQuerySystemInformation(SystemHandleInformation) pour trouver le handle de l'usine du travailleur
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Construire une fausse structure TP_WORK avec rappel → adresse shellcode
4. VirtualAllocEx(PAGE_READWRITE) pour la structure TP_WORK
5. WriteProcessMemory (TP_WORK vers la cible)
6. Insérer un élément de travail dans la file d'attente du pool de threads via NtSetInformationWorkerFactory

Artefacts médico-légaux :

• Non CreateRemoteThread - exécution via la répartition du pool de threads
• Mémoire : transition RW -> RX pour le shellcode
• Allocation RW supplémentaire pour la structure TP_WORK
• L'activité du pool de threads apparaît comme une exécution légitime du travailleur

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : poolparty_timer MITRE ATT&CK : T1055 - Injection de procédé

ID : poolparty_io MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Utilise le mécanisme d'achèvement des E/S du pool de threads. Crée une fausse structure TP_IO avec le rappel pointant vers le shellcode et l'associe à un port d'achèvement d'E/S dans le processus cible. Lorsqu'un paquet de fin d'E/S arrive, le pool de threads distribue le rappel.

Chaîne d'appels API :

1. NtQuerySystemInformation(SystemHandleInformation) pour trouver le handle du port de fin d'E/S
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Construire une fausse structure TP_IO avec rappel → adresse shellcode
4. Écrire la structure dans le processus cible
5. Mettre en file d'attente le paquet d'achèvement d'E/S pour déclencher le rappel

Artefacts médico-légaux :

• Aucun artefact CreateRemoteThread
• Le rappel d'achèvement des E/S apparaît comme une gestion légitime des E/S asynchrones
• Mémoire : transition RW -> RX pour le shellcode

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : poolparty_alpc MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Utilise le mécanisme ALPC (Advanced Local Procedure Call) du pool de threads. Crée une fausse structure TP_ALPC avec le rappel pointant vers le shellcode et l'associe à un port ALPC dans le processus cible. Lorsqu'un message ALPC arrive sur le port, le pool de threads distribue le rappel.

Chaîne d'appels API :

1. NtQuerySystemInformation(SystemHandleInformation) pour trouver le handle du port ALPC
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. Construire une fausse structure TP_ALPC avec rappel → adresse shellcode
4. Écrire la structure dans le processus cible
5. Envoyer un message ALPC pour déclencher l'envoi de rappel

Artefacts médico-légaux :

• Aucun artefact CreateRemoteThread
• Le rappel ALPC apparaît comme une gestion légitime des communications inter-processus
• Mémoire : transition RW -> RX pour le shellcode

Prend en charge InjectByPID : Oui. Prend en charge InjectByHandle : Oui.

ID : cb_fontenum MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Utilise l'API Windows GDI EnumFontFamiliesExW comme déclencheur de shellcode. Crée un processus suspendu, y écrit du shellcode, puis crée un thread distant qui appelle EnumFontFamiliesExW avec l'adresse du shellcode comme paramètre de rappel. Lorsque GDI énumère les polices, il appelle le rappel (shellcode) pour chaque famille de polices.

Chaîne d'appels API :

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modifier RIP pour pointer vers le stub EnumFontFamiliesExW
4. Appels EnumFontFamiliesExW(NULL, NULL, shellcodeAddr, 0)
5. ResumeThread -- L'énumération des polices GDI déclenche le rappel du shellcode

Artefacts médico-légaux :

• Création de processus suspendue
• L'appel API GDI semble légitime (l'énumération des polices est courante)
• Mémoire : transition RW -> RX pour le shellcode
• Modification du contexte du thread

Prend en charge InjectByPID : Oui (crée un nouveau processus suspendu). Prend en charge InjectByHandle : Oui.

ID : cb_timer MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Utilise CreateTimerQueueTimer comme déclencheur de shellcode. Crée un processus suspendu, écrit le shellcode, puis redirige l'exécution vers un stub qui appelle CreateTimerQueueTimer avec l'adresse du shellcode comme rappel du minuteur. Le minuteur se déclenche immédiatement (période d'échéance = 0), exécutant le shellcode.

Chaîne d'appels API :

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modifier RIP pour pointer vers le stub CreateTimerQueueTimer
4. Appels CreateTimerQueueTimer(NULL, NULL, shellcodeAddr, NULL, 0, 0, WT_EXECUTEDEFAULT)
5. ResumeThread -- le minuteur se déclenche immédiatement, déclenchant le rappel du shellcode

Artefacts médico-légaux :

• Création de processus suspendue
• Création de file d'attente de minuterie (modèle d'API Windows légitime)
• Mémoire : transition RW -> RX pour le shellcode
• Modification du contexte du thread

Prend en charge InjectByPID : Oui (crée un nouveau processus suspendu). Prend en charge InjectByHandle : Oui.

ID : cb_winenum MITRE ATT&CK : T1055 - Injection de procédé

Comment ça marche : Utilise l'API EnumWindows comme déclencheur de shellcode. Crée un processus suspendu, écrit le shellcode, puis redirige l'exécution vers un stub qui appelle EnumWindows avec l'adresse du shellcode comme rappel d'énumération. Lorsque user32 énumère les fenêtres de niveau supérieur, il appelle le rappel (shellcode) pour chaque fenêtre.

Chaîne d'appels API :

1. CreateProcessW(sacrificialProcess, CREATE_SUSPENDED | CREATE_NO_WINDOW)
2. VirtualAllocEx + WriteProcessMemory + VirtualProtectEx (shellcode, RX)
3. GetThreadContext → modifier RIP pour pointer vers le stub EnumWindows
4. Appels EnumWindows(shellcodeAddr, 0)
5. ResumeThread -- l'énumération de la fenêtre déclenche le rappel du shellcode

Artefacts médico-légaux :

• Création de processus suspendue
• Appel d'API d'énumération de fenêtre (activité user32 courante)
• Mémoire : transition RW -> RX pour le shellcode
• Modification du contexte du thread

Prend en charge InjectByPID : Oui (crée un nouveau processus suspendu). Prend en charge InjectByHandle : Oui.