Module 1 – Techniques Anti-VM et Anti-Sandbox
Le premier obstacle qu’un malware essaiera souvent de franchir est la détection de l’environnement dans lequel il est exécuté. En identifiant s’il tourne dans une machine virtuelle ou une sandbox automatisée, il peut alors décider d’adopter un comportement inoffensif ou tout simplement de s’arrêter. C’est un moyen simple mais efficace d’éviter la détection par les chercheurs et les outils automatisés de sécurité.
La détection s’effectue généralement en recherchant certains artefacts : clés de registre, fichiers, services ou processus spécifiques à un hyperviseur. Par exemple, des noms comme VBoxGuest, vmtoolsd.exe, vm3dservice ou vboxservice sont des cibles communes. Des outils comme Procmon permettent d’observer ces recherches en temps réel.
Mais les malwares ne se limitent pas à ces signatures. Ils inspectent également des paramètres système tels que la taille du disque dur, la quantité de mémoire vive disponible, ou encore le nombre de cœurs processeur. Ces caractéristiques étant souvent faibles dans les environnements de test, elles constituent des indices fiables pour le malware.
Une autre tactique consiste à énumérer les processus en cours d’exécution. Si le malware détecte un processus lié à une sandbox, à un outil de debug ou à un produit de sécurité, il peut décider de ne pas poursuivre. C’est une technique utilisée notamment par la famille de malware Bumblebee, qui interrompt son exécution si elle détecte procmon.exe, processhacker.exe, ou wireshark.exe.
Enfin, certains malwares vérifient la présence d’activité réseau ou d’historique utilisateur, pour s'assurer qu'ils ne sont pas dans un environnement stérile. Cela peut se traduire par la vérification du cache navigateur ou des fichiers récemment ouverts. Si rien n’est trouvé, ils en concluent qu’ils sont surveillés.
Pour contourner ces techniques, plusieurs options s’offrent à l’analyste :
- Modifier ou masquer les artefacts des éditeurs de machine virtuelle (fichiers, clés de registre, services).
- Utiliser des outils comme VBoxCloak qui automatisent la dissimulation d’un environnement VirtualBox.
- Simuler l’activité d’un utilisateur, en ouvrant des fichiers, en lançant des applications légitimes ou en remplissant le cache navigateur.
- Simuler une connexion réseau crédible à l’aide d’outils comme FakeNet-NG, qui interceptent et répondent au trafic du malware de manière contrôlée.
Lorsqu’il s’agit de contournement plus avancé, x64dbg peut être utilisé pour patcher dynamiquement les instructions du malware, afin de sauter les vérifications ou modifier leurs résultats (par exemple, forcer un cmp à toujours réussir). De même, l’analyse statique dans IDA Pro permet d’identifier les appels suspects à RegOpenKeyEx, FindFirstFileW, GetDiskFreeSpaceEx, etc.
Ce qu’il faut retenir
- Les malwares recherchent des indices d’un environnement virtuel : clés de registre, chemins de fichiers, processus suspects.
- Ils peuvent mesurer des ressources matérielles minimales pour éviter les environnements de test (ex. < 4 Go RAM, < 80 Go disque).
- La vérification des processus ou de l’absence d’activité utilisateur permet de détecter les sandboxs automatisées.
- En cas d’absence de connectivité réseau, les malwares cessent souvent leur exécution : FakeNet permet de simuler un environnement réaliste.
- Les outils comme VBoxCloak et VMwareCloak masquent les traces de virtualisation.
- Le rétro-ingénieur peut modifier les chemins, valeurs ou sauter les instructions critiques via IDA ou x64dbg.
Module 2 – Techniques Anti-Débogage
Une fois l’environnement de virtualisation contourné, le malware va chercher à savoir s’il est débogué activement. Cette phase est particulièrement critique pour l’analyste car le malware va tenter de s’autodétruire, masquer son comportement ou piéger l’analyste.
Les appels API Windows comme IsDebuggerPresent ou CheckRemoteDebuggerPresent sont souvent utilisées pour détecter un débogueur. Ces fonctions lisent des valeurs dans la structure PEB (Process Environment Block), notamment le champ BeingDebugged. Il est aussi courant de vérifier le flag NtGlobalFlag dans le PEB.
Mais les techniques ne s’arrêtent pas là. Certaines utilisent des appels comme OutputDebugString, NtQueryInformationProcess, ou des appels systèmes bas niveau. D’autres emploient des méthodes temporelles comme :
- GetTickCount, qui retourne le temps depuis le démarrage du système (utile pour détecter un démarrage récent).
- GetLocalTime, qui permet d’implémenter des « time bombs » (ex. : ne s'exécute qu’après le 1er juin 2025).
- RDTSC (Read Time-Stamp Counter), qui mesure la durée entre deux instructions, révélant les interruptions dues au débogueur.
Le malware peut également tenter de retarder l’exécution volontairement, via Sleep, NtDelayExecution, ou des boucles de « stalling ». Ce délai peut dépasser la fenêtre d’exécution
d’une sandbox, rendant le comportement malveillant invisible.Enfin, certaines techniques visent à détecter des breakpoints logiciels (0xCC) ou des hooks logiciels (0xE9) sur les fonctions critiques. Pour cela, le malware peut scanner la mémoire à l’aide de VirtualQuery ou ReadProcessMemory.
Face à ces mécanismes, plusieurs solutions existent :
- Modifier dynamiquement les instructions via x64dbg (ex. : remplacer « je » par « jmp »).
- Changer la date système ou laisser le système tourner quelques minutes avant l’analyse.
- Utiliser ScyllaHide, un plugin de x64dbg capable de cacher automatiquement le débogueur.
- Préférer les points d’arrêt matériels, plus discrets, lorsqu’un malware détecte les points d’arrêt logiciels.
Ce qu’il faut retenir
- Les malwares utilisent IsDebuggerPresent, NtQueryInformationProcess, GetTickCount, RDTSC pour détecter les débogueurs.
- Les « time bombs » ou vérifications du temps d’allumage permettent de s’exécuter uniquement dans des contextes réels.
- RDTSC mesure les cycles CPU : toute latence anormale peut signaler la présence d’un debugger.
- Les délais (Sleep) sont utilisés pour échapper aux sandboxs automatisées qui fonctionnent généralement pour une courte durée : leur valeur peut être modifiée.
- Les points d’arrêt logiciels (0xCC) et les hooks (0xE9) peuvent être détectés via l’inspection mémoire.
- L’utilisation de ScyllaHide ou de patchs dynamiques est essentielle pour contourner ces obstacles.
- Il est possible de forcer un saut (jmp) ou de simuler une valeur système via modification des registres.
Module 3 – Appels système indirects et MutationGate
Ce module aborde des techniques plus avancées et récentes visant à échapper aux systèmes de détection comportementale comme les EDRs (Endpoint Detection & Response). Plutôt que d’appeler directement les fonctions API classiques de Windows, les malwares vont générer leurs propres appels système, de manière indirecte, afin de passer sous le radar.
Indirect Syscalls
L’approche des indirect syscalls, popularisée par SysWhispers3, permet de contourner les hooks placés par les EDRs autour de fonctions sensibles (comme NtOpenProcess ou NtAllocateVirtualMemory). En construisant manuellement l’appel système — en initialisant les registres, plaçant l’identifiant de la fonction (SSN) dans EAX, et exécutant l’instruction syscall —le malware évite les points de surveillance classiques.
SysWhispers propose plusieurs méthodes :
- Jumper : saute directement à l’instruction syscall dans ntdll.dll.
- Embedded : intègre l’appel syscall directement dans le binaire.
- Egg-hunter : code volontairement « cassé » mais réparé en mémoire par un loader.
- Jumper-randomized : ajoute de l’aléatoire dans le choix de la fonction appelée.
Ces techniques rendent l’analyse complexe, car aucune API n’est visible dans la table d’import et les noms des fonctions ne sont pas présents.
MutationGate : une technique d’évasion encore plus discrète
La technique décrite sous le nom de MutationGate, récemment documentée dans la communauté, introduit une méthode encore plus furtive. Il utilise des vectored exception handlers (VEH) pour détourner dynamiquement les appels système. L’idée est simple mais brillante : le malware appelle une fonction innocente (comme NtDrawText) sur laquelle un point d’arrêt matériel est placé. Lorsqu’il atteint ce point, une exception est levée. Le handler associé intercepte l’exception et modifie à la volée le registre RAX, y injectant le SSN de la vraie fonction
désirée (par exemple NtOpenProcess), juste avant l’exécution de syscall.
Ce mécanisme permet de masquer totalement l’intention réelle du code :
- Aucune trace dans la table d’imports.
- Aucun appel direct à des fonctions dangereuses.
- Masquage du comportement jusqu’au dernier moment, au sein du handler.
Lors de l’analyse, seule une inspection fine du handler VEH permet d’identifier le vrai comportement. Le malware utilise souvent plusieurs breakpoints matériels (jusqu’à 4) pour gérer différentes redirections d’appel.
Ce qu’il faut retenir
- Les indirect syscalls permettent de contourner les hooks EDR en appelant directement les syscall via des stubs personnalisés.
- MutationGate va plus loin en injectant le SSN dans le registre RAX au moment d’une exception, rendant l’appel système indétectable.
- Il est possible d’analyser ces comportements via x64dbg et IDA, en plaçant des breakpoints sur les instructions critiques (syscall, RAX, handlers VEH).
Conclusion
À travers ces trois modules, on constate que les techniques d’évasion des malwares ne sont plus uniquement défensives, mais deviennent proactives. Elles visent à perturber l’analyste, tromper les outils automatisés, et manipuler les couches inférieures du système pour rester furtives. Afin de contrer ces techniques, l’analyste doit se munir d’une méthodologie rigoureuse, d’outils adéquats, et surtout, d’une compréhension approfondie des mécanismes internes de Windows.
Ce rapport illustre l’évolution technologique et stratégique des malwares. Des simples tests de virtualisation jusqu'aux appels système obfusqués par le biais de gestionnaires d’exception, les techniques d’évasion se complexifient, requérant de l’analyste une vigilance permanente ainsi qu’une mise à niveau constante de ses méthodes.
Pour chaque niveau d’évasion, il existe néanmoins des solutions : dissimulation d’environnement, modification dynamique du code, émulation réseau... Cette expertise est désormais cruciale dans les domaines tels que la réponse aux incidents, le threat hunting, ou encore l’analyse post-mortem.
