Expliquez les techniques courantes d'injection de processus et les signatures d'API et comportementales qui les révèlent.
Réponse courte
L'injection de processus exécute du code malveillant à l'intérieur d'un autre processus pour se cacher et hériter de sa confiance. L'injection distante classique alloue de la mémoire dans une cible avec VirtualAllocEx, écrit une charge utile via WriteProcessMemory, et l'exécute avec CreateRemoteThread. Les variantes incluent l'injection de DLL via LoadLibrary, le process hollowing qui démappe un processus légitime suspendu et remplace son image, l'injection APC qui met du code en file d'attente sur un thread, et le chargement réflexif ou mappé manuellement qui évite LoadLibrary entièrement. On les repère par les séquences d'API révélatrices, la mémoire RWX dans un processus normalement propre, les threads sans fichier de sauvegarde sur le disque et les anomalies parent-enfant.
L'injection de processus permet à un malware d'exécuter son code à l'intérieur d'un autre processus — pour se cacher de l'inspection de la liste des processus, pour échapper aux défenses qui font confiance au processus hôte, et pour accéder à la mémoire d'un autre programme. Les recruteurs posent cette question aux seniors parce que l'injection est partout dans les malwares modernes, et que la reconnaître exige une vraie connaissance des internes de Windows.
La technique classique
L'injection par thread distant suit une séquence d'API reconnaissable :
OpenProcesspour obtenir un handle sur la cible.VirtualAllocExpour allouer de la mémoire dans la cible — fréquemment en RWX (lisible, inscriptible, exécutable).WriteProcessMemorypour y copier la charge utile.CreateRemoteThread(ouNtCreateThreadEx/QueueUserAPC) pour l'exécuter.
Voir cette chaîne dans les imports ou à l'exécution est un indice d'injection quasi certain.
Variantes courantes
- Injection de DLL. Écrire un chemin de DLL dans la cible et appeler
LoadLibraryvia un thread distant pour que le loader mappe votre DLL. - Process hollowing. Démarrer un processus légitime suspendu (
CREATE_SUSPENDED), démapper son image originale, écrire une image malveillante à sa place, corriger le point d'entrée et reprendre — le processus semble légitime par son nom mais exécute le code de l'attaquant. - Injection APC. Mettre en file d'attente un appel de procédure asynchrone sur un thread alertable existant pour que la charge utile s'exécute quand ce thread entre ensuite dans une attente alertable.
- Chargement réflexif / mapping manuel. La charge utile se mappe elle-même en mémoire et résout ses propres imports, n'appelant jamais LoadLibrary, déjouant les détections qui hookent le loader.
Comment vous le détectez
Comportementalement : de la mémoire privée RWX dans un processus qui n'en a normalement pas, des threads sans fichier de sauvegarde sur le disque, une relation parent-enfant qui n'a aucun sens (par ex. winword.exe engendrant cmd.exe), et les séquences d'API ci-dessus attrapées par l'EDR ou dans un débogueur. En forensique mémoire, des outils comme malfind de Volatility signalent les régions injectées. Une réponse senior associe chaque technique à son empreinte d'API et à l'artefact qu'elle laisse derrière elle.
Questions de suivi probables
- En quoi le process hollowing diffère-t-il de l'injection classique par CreateRemoteThread ?
- Pourquoi la mémoire RWX sans fichier de sauvegarde est-elle un fort indicateur d'injection ?
- Comment le chargement réflexif de DLL échappe-t-il aux détections qui hookent LoadLibrary ?