Depuis la première apparition de malware en 1971, Creeper, les mécanismes de protection se sont continuellement adaptés ; à commencer par Reaper, le premier antivirus. Cela a marqué le début d'une longue dynamique de jeu du “chat et de la souris” entre les fournisseurs de sécurité et les auteurs de malwares.
De nos jours, les attaquants déposent rarement une charge utile non protégée sur le disque. La charge utile est soit reconnaissable et facilement identifiable car elle contient des signatures connues, soit elle est conçue sur mesure pour éviter (ou ralentir) l'ingénierie inverse et l'exposition de l'infrastructure de l’attaquant. Une charge utile est donc généralement stockée sur disque sous sa forme chiffrée et déchiffrée uniquement en mémoire grâce à des techniques d'injection de processus utilisées par divers loader, packer et crypters.
Cependant, l 'évasion ne s'arrête pas à éviter la détection sur disque. Les défenseurs peuvent également scanner la mémoire à la recherche d'indicateurs, bien que l’analyse de la mémoire soit coûteuse et ne puisse pas être effectuée en continu. De plus, la mémoire des processus est volatile, changeante, et il n'y a pas qu'un seul processus à surveiller sur une machine. C'est pourquoi les mécanismes de défense modernes reposent sur des déclencheurs comportementaux pour décider quand effectuer une inspection plus approfondie de la mémoire.
L'API Windows est très permissive, dotant les développeurs de capacités significatives. En conséquence, il existe de nombreuses façons d'exécuter une charge utile en mémoire, que ce soit dans l'espace d'adressage du stager ou dans un autre processus. La charge utile peut prendre plusieurs formes ;
S'il s'agit d'un exécutable, il nécessitera sa propre implémentation d'un loader, effectuera ses relocations, chargera des bibliothèques importées et résoudra son IAT.
S'il s'agit d'une bibliothèque, similaire à un exécutable, elle nécessitera une implémentation d'un ReflectiveLoader et effectuera un RDI / sRDI.
Enfin, s'il s'agit d'un shellcode, la seule exigence est l'allocation de mémoire exécutable, pour écrire la charge utile et démarrer un thread.
À titre d'exemple en évasion, certains attaquants ont tenté de retirer les patchs des hooks de l’EDR dans ntdll.dll en chargeant manuellement la bibliothèque depuis le disque, mais ces derniers ont commencé à surveiller l'intégrité du module.
Les attaquants ont ensuite tenté de contourner les hooks ntdll.dll en utilisant syswhispers et les directs syscalls. Mais les EDR se sont de nouveau adaptés et ont ajoutés des détections statiques pour les en-têtes syswhispers intégrés au malware.
Cela conduit à la saga de Hell's Gate, Halo's Gate, Tartarus' Gate et FreshyCalls, où toutes ces techniques ont tenté de résoudre dynamiquement les numéros des syscalls.
Les défenseurs se sont de nouveau adaptés en s'assurant que si un syscall est appelé, l'adresse de retour doit pointer vers une adresse dans ntdll.dll. En réponse, les attaquants ont commencé à faire des indirects syscalls et du Stack Spoofing.
Restreindre la télémétrie (comme le patching ETW / AMSI et unhook ntdll.dll) peut sembler une bonne idée pour réduire légèrement les capacités de vision de la solution défensive déployée. Cependant, cela peut aussi introduire de nouveaux indicateurs de compromission. Il faut aussi garder à l'esprit qu’il n’est seulement possible que d'entraver la télémétrie envoyée à la solution défensive, sans la bloquer complètement : certains types de télémétrie sont inaltérables, en particulier ceux provenant du noyau, comme les kernel callbacks ou le kernel ETW (TI).
Cette évolution constante a déplacé l'attention pour l'évasion au sein même de la mémoire. Des techniques comme le Sleep Mask Kit de Cobalt Strike et des approches plus récentes comme SleepyCrypt, Foliage, Ekko, DeepSleep et Cronos chiffrent ou modifient les charges utiles pendant qu'elles sont en sommeil pour éviter les scans mémoire. Une méthode apparentée, la fluctuation de mémoire, modifie les protections de la page (par exemple, passer des permissions RX en RW quand elle est inactive, et inversement) et chiffre éventuellement le contenu pendant les phases de sommeil.
Lors d’une enquête forensique, durant l'analyse de la mémoire, cette technique peut également aider à contourner le plugin de malfind de Volatility, conçu pour détecter le code caché ou injecté ainsi que des DLL dans la mémoire en “user land” en fonction de caractéristiques telles que les balises VAD et les permissions de page.
Le concept de fluctuation mémoire est apparu pour la première fois en 2017 avec les travaux de Gargoyle, qui a introduit un modèle de shellcode auto-fluctuant en exploitant les timer APC et des ROP chains qui invoquent VirtualProtect. En 2021, Mariusz Banach a publié le dépôt ShellcodeFluctuation, offrant une mise en œuvre claire et pédagogique des mécanismes de fluctuation. Cet article s'appuie fortement sur ce projet.
L'intérêt pour ces techniques s'est considérablement accru en 2023. En mai, John Uhlmann a présenté à la Black Hat Asia un aperçu des techniques de détection et d'évasion résidentes en mémoire. Plus tard en octobre, Maldev Academy a publié un module PEFluctuation enseignant aux étudiants à développer un loader PE complet et à appliquer la fluctuation en mémoire. En novembre, John Hammond a publié une vidéo sur le sujet, il est un influenceur bien connu dans le domaine de la cybersécurité, ce qui a permis de sensibiliser un large public à cette technique.
À mesure que l'adoption de ces techniques s'est accrue, le besoin d'une détection efficace a également augmenté. Des outils comme pe-sieve et moneta constituent la base de la majorité des heuristiques également implémentées dans les scanners mémoire de produits commerciaux de protection des terminaux, tandis que des projets plus spécialisés (par exemple, TickTock, Patriot, Hunt-Sleeping-Beacons) tentent de détecter des comportements spécifiques ; bien que certains aient été contournés par de nouvelles techniques d’évasion (par exemple, BusySleepBeacon)
Cet article se concentre sur le mécanisme obfuscate-and-sleep inspirés du "sleep mask” de Cobalt Strike, ainsi que sur une simple fluctuation de shellcode. Comme les équipes de sécurité manquent actuellement de lignes directrices précises pour détecter ces méthodes, cet article vise à sensibiliser et à mettre en lumière des indicateurs pratiques pour les analystes SOC, les threat hunters, les experts DFIR, les chercheurs en malwares et les développeurs d’EDR.
Développement du loader
Pour comprendre la technique de fluctuation, cette section détaillera la mise en œuvre d'un loader, en se concentrant sur l'architecture x86_64.
À des fins de test, un environnement expérimental a été mis en place, composé d'un serveur C2, d'un SIEM et d'un EDR (Elastic), avec Sysmon déployé sur une machine Windows servant de victime. Plus de détails sur la mise en place de cette infrastructure sont disponibles dans les annexes de cet article.
Pour le processus de développement de malwares, les flakes nix sont utilisés pour créer un environnement de développement reproductible et auto-documenté. L'utilisation de llvm-mingw comme toolchain spécialisée permet l'utilisation d'un backend LLVM en C++ tout en cross-compilant vers Windows.
A noter qu'une grande partie des extraits de code ci-dessous proviennent du code source de mgeeky.
Hooker sleep
Le premier objectif est d'afficher un message à chaque fois que la fonction sleep est appelée. Cela peut être réalisé en définissant une fonction principale comme suit :
La fonction hookSleep() est responsable de placer un hook sur la fonction Sleep. Dans le code ci-dessous, l'adresse de la fonction de Sleep dans le module NTDLL est récupérée. De même, l'adresse de la fonction MySleep, qui remplacera le Sleep légitime, est obtenue. Ces adresses sont ensuite transmises à fastTrampoline(), qui s'occupe de placer et de retirer l'hameçon.
La fonction fastTrampoline() est relativement grande et est divisée en plusieurs parties pour plus de clarté.
D'abord, une template de trampoline est défini, qui déplace une adresse dans le registre r10 et effectue un saut vers cette adresse. Les espaces réservés par des zéros dans le modèle sont ensuite remplacés par addressToHook.
Lors de l'installation du hook, le code original de Sleep est d'abord sauvegardé pour une restauration ultérieure. Le corps de la fonction est alors écrasé par le code du trampoline.
Pour supprimer l'hameçon, le code original est simplement restauré :
Enfin, les applications doivent appeler FlushInstructionCache si elles modifient du code en mémoire. Le processeur ne peut pas détecter la modification et peut exécuter l'ancien code qu'il a mis en cache. Il est également important de restaurer les protections mémoire correctes par la suite.
La dernière fonction qui n’a pas encore été évoquée est MySleep(), qui est l’adresse de destination du trampoline lorsque le programme appelle kernel32!Sleep.
Tout d’abord, une portion de code est exécutée (actuellement un simple print vers stdout), qui sera ensuite remplacé par la routine de chiffrement de la charge utile. Le code du sleep légitime est ensuite restauré pour éliminer d’éventuels IoC associés au hooking. Ensuite, la fonction originale est exécutée, et le hook est réinstallé au cycle suivant.
Lorsque le programme est exécuté, le hook fonctionne comme prévu ; cependant, ce comportement est détecté par l'EDR.
Cela a déclenché une alerte critique sur la console :
Comment Elastic détecte le hooking de la fonction sleep ?
Le principal avantage (et inconvénient) d'Elastic est qu'il s'agit d'une solution open source. Cela signifie que les analystes SOC, les chercheurs en cybersécurité, mais aussi les redteamers et les attaquants peuvent comprendre exactement pourquoi une alerte a été déclenchée.
Protection-artifacts est le package déployé sur les terminaux. Il contient toutes les règles de détection comme YARA, les comportementales, etc... Une recherche GitHub sur ce dépôt peut être utilisée pour identifier la règle de détection qui s’est appliquée.
La règle ci-dessus indique qu'une alerte est déclenchée si l'une des fonctions WinAPI suivantes — WriteProcessMemory, VirtualProtect ou VirtualProtectEx — cible l'adresse de kernel32.dll!Sleep. À ce stade, un développeur de malware pourrait potentiellement contourner cette règle en utilisant des direct / indirect syscalls, en écrivant légèrement avant l’adresse de kernel32!Sleep, ou en utilisant une fonction alternative qui produirait un effet de bord similaire. Il est aussi intéressant de noter que malapi.io peut être utilisé pour identifier des fonctions de la WinAPI présentant des fonctionnalités intéressantes pour les reverse-engineers et les développeurs de malwares.
Remarque : En attachant un débogueur au loader et en allant directement à l’adresse du symbole de kernel32!Sleep, la présence du hook peut être constatée. Placer un breakpoint à cet endroit suffit à déclencher l'alerte.
Ce comportement peut probablement être expliqué par le fait que le débogueur utilise des software breakpoints. En fixant un point d'arrêt à cette adresse, il écrit un opcode INT 3 dans la mémoire du processus, ayant ainsi le même effet qu'une injection de code.
Identifier un contournement de l’EDR dépasse le cadre de cet article. Cependant, l'analyse d'Elastic fournit une vision précieuse sur les composants internes de l'EDR et permet de lever plusieurs indicateurs potentiels de détection.
Chiffrement basique de sleep et fluctuation
Il est désormais possible d’implémenter une routine d'auto-injection, par exemple en utilisant la séquence classique VirtualAlloc + memcpy + CreateThread. Bien que cette approche produise encore de forts indicateurs de compromission, des méthodes d'exécution en mémoire plus discrètes existent en faisant preuve d’un peu de créativité. Pour illustrer, l'appel à CreateThread est remplacé ici par un simple JMP.
L'adresse et la taille du shellcode sont stockées dans des variables globales pour garder une référence vers le buffer tant que la mémoire est chiffrée. Une clé de chiffrement codée en dur est utilisée pour simplifier ; dans un contexte de production, une clé générée aléatoirement serait requise pour l'OPSEC. Ces métadonnées sont ensuite utilisées par la fonction toggleEncryption(), qui applique une simple opération xor avec la clé fournie vers l'adresse ciblée
Pour chiffrer la région mémoire, sa protection doit d'abord être modifiée pour autoriser l’écriture. Grâce à VirtualProtect, les permissions sont commutées de RX à RW, permettant ainsi de chiffrer le buffer. Le déchiffrement suit le processus inverse : puisque la région est écrivable, la charge utile déchiffrée peut être réécrite, puis VirtualProtect est réutilisé pour restaurer les permissions de RW vers RX.
En conséquence, cette implémentation du chiffrement en sommeil introduit également une fluctuation basique.
Parce que cette approche repose fortement sur VirtualProtect, elle produit des indicateurs clairs associés aux malwares fluctuants. Les opportunités de détection liées à ce comportement seront abordées plus tard.
La fonction toggleEncryption() peut désormais être invoquée dans MySleep, où l'exécution est redirigée depuis le kernel32!Sleep hooké.
Le hook aura le cycle de vie suivant :
Déchiffrer -> Unhook -> Dormir -> Chiffrer -> Hook -> Retour
Fluctuation via le gestionnaire d'exception vectorielle
Un gestionnaire d'exception vectorielle (VEH) est un mécanisme Windows qui permet aux développeurs d'enregistrer directement des gestionnaires d'exceptions personnalisés auprès du système d'exploitation. Contrairement à la gestion des exceptions structurée (SEH), qui est basée sur la stack et portée sur une fonction ou un module spécifique, les gestionnaires VEH sont globaux et reçoivent toutes les exceptions avant les gestionnaires SEH. Cela rend VEH particulièrement utile pour le débogage, l'instrumentation, les techniques anti-exploitation et la gestion des crashs, car il offre un contrôle bas niveau sur la manière dont les exceptions sont traitées à l'échelle du système.
Cette approche enregistre un VEH et alterne la protection des pages mémoire entre RX et PAGE_NOACCESS. Lorsque le pointeur d'instruction (RIP) tente d'exécuter du code sur une page actuellement définie en NOACCESS, Il provoque une exception, interceptée par le VEH, qui lève la protection de la charge utile et en déclenche l’exécution. Cette variante est basée sur le travail de ORCA666 présenté dans le projet 0x41 injector ; malheureusement, le dépôt original de GitHub n'est plus disponible.
Avant d'exécuter la charge utile, un VEH est enregistré à l'aide de AddVectoredExceptionHandler. La fonction de gestion est définie comme VectoredExceptionHandler.
Lorsque la charge utile est protégée, ses permissions de page sont définies à PAGE_NOACCESS au lieu de RW. Toute tentative d'exécution de cette région déclenche une violation d'accès (0xC0000005), qui est interceptée par le VEH. Le gestionnaire rétablit alors la protection sur RX, permettant ainsi l'exécution de se poursuivre. Le rôle du hook placé sur sleep est de réappliquer PAGE_NOACCESS à la charge utile juste avant d'invoquer ::Sleep().
Une note à propos du C2 Sliver
Lors des tests, le serveur de C2 Sliver a été initialement utilisé. Cependant, les hooks sur sleep n'ont pas été déclenchés. Sous Windows, un agent Sliver n'invoque pas kernel32!Sleep directement. Cela dépend des fonctions time.Sleep et time.After pour assurer la gestion des intervalles entre les communications du C2. Le runtime Go abstrait les mécanismes d'attente spécifiques à chaque plateforme et utilise des primitives internes ; comme les waitable timers ou SleepEx, au lieu d'appeler kernel32!Sleep.
L'extrait suivant montre comment le thread est mis en pause entre les interactions avec le serveur :
La branche time.After(duration) met la goroutine en pause entre les interactions avec le C2, le délai étant entièrement géré par le système de minuterie interne de Go. Pour le reste de cet article, le framework Adaptix C2 a été utilisé à la place, puisque ses agents sont implémentés en C++.
Avec Adaptix, le hook fonctionne comme prévu :
À la recherche d’indicateurs
Les scanners mémoire
Maintenant que le loader met en œuvre de la fluctuation utilisant à la fois RW et NOACCESS, et qu'un environnement de test adapté est disponible, l'étape suivante consiste à évaluer les outils mentionnés précédemment et à observer leurs capacités lors de l'analyse des fluctuations.
Moneta
Moneta est un outil d'analyse mémoire en temps réel et en “user land” pour Windows, capable de détecter les IoC laissés par de potentiels malwares, principalement basé sur la détection d'anomalies.
Dans les résultats des scans présentés ci-dessous, le processus du loader a été analysé à la fois en utilisant les approches RW et NOACCESS. Le scanner a tout de même identifié un comportement anormal et signalé FluctuateLdr.exe comme suspect.
PE-sieve
Comme Moneta, PE-sieve scanne un processus cible à la recherche d'implants ou de patchs potentiellement malveillants. Lorsque de telles modifications sont identifiées, il extrait le PE suspect. Lors des essais, il s'est révélé très efficace : il a détecté l'injection et extrait avec succès le shellcode sous sa forme non protégée. Cette capacité est particulièrement utile pour les analystes cherchant à récupérer une charge utile à partir d'un loader.
Hunt-sleeping-beacons
HSB a détecté avec succès FluctuateLdr.exe suite à plusieurs appels vers Sleep. Comme les EDR se comportent souvent de manière similaire à un « C2 de blueteamer», en alternant des phases de sommeil à intervalles réguliers et des communications avec un serveur de contrôle, ils peuvent déclencher HSB plus fréquemment que le malware lui-même, ce qui entraîne un nombre significatif de faux positifs.
Hunting au travers des logs
Avant de mener des recherches via le SIEM, les journaux EVTX ont été collectés, et des outils d’investigation forensique rapide ont été utilisés, simulant une analyse DFIR typique, pour identifier tout artefact notable. En utilisant chainsaw et hayabusa aucun artefact de fluctuation en mémoire n'a été détecté avec les règles de hunt par défaut.
Puisque la technique opère entièrement en mémoire, une visibilité limitée est attendue sur le SIEM, même avec Sysmon installé. Les journaux Application, System, Security et Sysmon ont été collectés depuis la machine.
Aucun artefact concluant n'a été identifié, à l'exception des interactions réseau avec le C2, qui fournissent des informations insuffisantes pour être classées comme un indicateur fiable. À ce stade, l'analyse doit se concentrer sur les objectifs de l'attaquant et les comportements manifestés après l'accès initial.
Note : Sans rapport avec la fluctuation, l'en-tête du PE «original filename» est absent, probablement en raison de la compilation avec llvm-mingw. Bien que ce ne soit pas intrinsèquement malveillant, cela peut indiquer une activité inhabituelle sur le système.
Pour ce test, les alertes EDR ainsi que la télémétrie associée ont été volontairement ignorées. L’objectif est d’identifier de nouveaux indicateurs plutôt que de s’appuyer sur les détections Elastic déjà existantes.
Une note à propos de volatility
Pour des raisons d’exhaustivité, la mémoire de la machine cible a également été examinée. Un dump complet de la mémoire a été acquis à l’aide de WinPmem et analysé avec le framework Volatility3. Bien que l’on puisse s’attendre à une valeur ajoutée limitée de l’analyse forensique mémoire face à une technique conçue pour échapper à l’inspection en mémoire, cette analyse a été réalisée à des fins de vérification.
Comme prévu, le plugin malfind n'a pas identifié la charge utile intégrée : le loader la place dans des pages marquées RW ou NOACCESS, ce qui empêche une détection simple. Les tentatives d'identification du hook de Sleep ont également échoué, puisque ce dernier est intentionnellement retiré juste avant d'appeler Sleep() pour éviter de laisser cet artefact, tel que présenté lors de la phase de développement.
Dans ce contexte, volatility n'a fourni aucun indicateur exploitable. Cela ne faisait que confirmer que le loader était actif au moment de l'acquisition, ce qui suppose également que la charge utile restait dans l'espace d'adressage du loader plutôt que d'être injectée dans un autre processus.
VirtualProtect comme indicateur fort
Comme expliqué dans la présentation de John Uhlmann, toutes les techniques de fluctuation reposent en fin de compte sur VirtualProtect pour modifier les protections mémoire, ce qui invoque en interne la fonction non documentée NtProtectVirtualMemory. Parce que la télémétrie du noyau ETW TI ne peut pas être modifiée de la même manière que les hooks dans NTDLL en “user land”, le fournisseur Microsoft-Windows-Threat-Intelligence, en particulier l'événement THREATINT_PROTECTVM_LOCAL identifié dans la TelemetrySource, offre une source fiable de détection.
Cependant, cette approche profite principalement aux développeurs de solution de sécurité. S'abonner à ce fournisseur nécessite un processus fonctionnant avec des privilèges Protected Process Light (PPL) au niveau « Anti-Malware » ou supérieur. L'accès légitime à ce niveau nécessite un pilote co-signé par Microsoft, ce qui limite sa disponibilité.
Pour les analystes prêts à exploiter le système qu'ils devraient initialement analyser, des outils comme SealighterTI : un outil de recherche de type Sysmon pour l’ETW, peut accéder à la télémétrie ETW Threat Intelligence via un exploit PPLdump. Bien que cet exploit ait été corrigé depuis Windows 10 v21H2 (Build 19044.1826), il peut encore être réalisable via un scénario de BYOVD.
Dans la même catégorie, EtwTi-FluctuationMonitor utilise la télémétrie ETW TI pour suivre l'activité de VirtualProtect(). Il maintient une liste des régions mémoire et incrémente les compteurs pour chaque changement de protection d'accès ; lorsqu'un compteur dépasse un seuil défini, la région associée est classée comme fluctuante.
Un outil qui ne nécessite pas d'exploiter l'hôte est CFG-FindHiddenShellcode. Il repose sur la bitmap Control Flow Guard (CFG), qui enregistre toutes les régions mémoire qui sont ou ont été exécutables. Toute région qui était auparavant exécutable mais n'est plus marquée comme telle est signalée par le scanner. Lors des tests, l'outil détectait systématiquement à la fois les transitions PAGE_READWRITE et PAGE_NOACCESS de ShellcodeFluctuation.exe, ce qui en fait l'une des options les plus efficaces pour identifier les fluctuations du shellcode en mémoire
Pour les développeurs de solution de sécurité, la surveillance de NtProtectVirtualMemory offre un moyen simple de détecter les fluctuations de mémoire en observant les changements d'état répétés pour la même page. Les systèmes modernes ont rarement besoin de modifier les protections mémoire, sauf dans des scénarios tels que le JIT, bien que s'appuyer uniquement sur cette heuristique produira toujours des faux positifs.
En tant que threat hunter, Etw-SyscallMonitor (utilisé avec PPLKiller) permet de comparer le comportement attendu des appels système et l'activité réelle basée sur la télémétrie ETW.
Pour plus de détails sur le fonctionnement interne de ces outils, consultez la présentation à la Black Hat Asia 2023 d'Uhlmann.
Durcissement
Enfin, pour les organisations visant à renforcer la sécurité des terminaux Windows, deux mesures de renforcement méritent d'être prises en compte :
- Activez la protection de la stack appliquée par le matériel (HSP).
HSP maintient une “shadow stack” en lecture seule qui stocke des adresses de retour légitimes. Cela offre deux avantages : il atténue les techniques d'exploitation telles que les ROP chains ou certaines approches basées sur la fluctuations (par exemple, Gargoyle) et crée une opportunité de détection pour les solutions de sécurité. Des techniques telles que celles démontrées dans CallStackSpoofer et ThreadStackSpoofer peuvent dissimuler l’activité face aux analyses de thread stack, toutefois, la comparaison entre la pile d’exécution classique et son équivalent, la “shadow stack”, peut révéler une usurpation de la stack.
- Activez Arbitrary Code Guard (ACG).
L’ACG empêche un processus de créer des pages exécutables ou de transformer de la mémoire non exécutable en mémoire exécutable, il garantit que le code exécuté est assuré par un fichier sur le disque (backed memory), bloquant ainsi les techniques d’injection courantes ainsi que les techniques d’attaque basées sur du JIT, telles que l’exécution de shellcode, le chargement réflectif de DLL et le process hollowing. Cependant, l'ACG se veut très restrictif et peut perturber les applications légitimes, ce qui limite sa praticité pour un déploiement large en production.
Conclusion
Comme mentionné dans l’introduction, le jeu du chat et de la souris ne s’est pas arrêté ; loin de là. Il s’est simplement poursuivi en mémoire. Cette évolution a fait des menaces résidentes en mémoire un centre d’intérêt à part entière, stimulant l’innovation tant dans les techniques de détection que dans celles d’évasion.
Points pratiques clés :
- Analystes SOC : Les journaux EVTX seuls offrent une valeur limitée. Comptez principalement sur la télémétrie et les alertes EDR et appliquez des mesures de durcissement des machines tel que HSP et ACG. Corrélez plusieurs sources de données plutôt que de faire confiance à un seul signal.
- Threat hunter : les journaux EVTX sont souvent insuffisants. Des outils comme Etw-SyscallMonitor peuvent surveiller l’ETW pour les appels système pertinents en sécurité, en maintenant un ensemble appelé pour chaque processus.
- Analystes DFIR : CFG-FindHiddenShellcode propose une méthode rapide pour détecter les fluctuations de shellcode. L'investigation des EVTX est généralement de faible valeur comparée à l'analyse ciblée de la mémoire.
- Reverseur : PE-sieve est capable d’extraire le shellcode pour une analyse hors ligne supplémentaire.
- Chercheurs en sécurité : Des outils tels que SealighterTI et EtwTi-FluctuationMonitor permettent d'exploiter les fournisseurs ETW TI à des fins expérimentales et de recherche.
- Développeurs de solution de sécurité : Surveillez les séquences d'appels consécutifs vers VirtualProtect et s'inspirer de l'approche d'Elastic pour la détection des hooks d’API (par exemple, les hooks de monitoring de kernel32!Sleep), ainsi que l'observation des appels vers WriteProcessMemory, VirtualProtect et VirtualProtectEx. Cela dit, la détection comportementale seule est susceptible de générer des faux positifs ; Combinez les signaux de plusieurs sources et envisagez de déclencher un scan mémoire à la demande lorsque les preuves le justifient.
Dans tous les contextes, PE-sieve et Moneta demeurent des outils essentiels pour examiner les techniques avancées d’évasion en mémoire. L’association d’une télémétrie approfondie, d’un scan en mémoire et d’investigations en environnement de test augmente significativement la capacité à conserver une conscience situationnelle.
Note spéciale pour les lecteurs redteam qui lisent un article blueteam : même si se cacher en mémoire est très utile pour éviter un antivirus ou un EPP, il est clair que toutes ces techniques d'évasion reposent sur de nombreux syscalls et fonctions de la WinAPI, générant du bruit ainsi que des anomalies (par exemple : compter sur VirtualProtect pour inverser la protection mémoire est un gros indicateur). Cette approche de « vivre en mémoire » est susceptible d’être peu pratique et difficilement durable à long terme, surtout face à un EDR mature. Une autre approche consiste à minimiser les IoC statiques dans l'implant (en utilisant ThreatCheck ou avred) et à s’exécuter depuis de la mémoire assurée par un fichier sur le disque (backed memory). Il est important de souligner que la plupart des règles de détection statique, comme les règles YARA, dépendent largement de strings spécifiques, qui peuvent être facilement modifiées ou obscurcies. De plus, le code machine généré par les compilateurs est très variable, ce qui signifie que même de petits changements dans le code source, la version du compilateur ou les paramètres de compilation peuvent produire des binaires significativement différents. Cette variabilité inhérente limite la fiabilité des approches de détection purement statique.
Références
- JLospinoso/gargoyle
- mgeeky/ShellcodeFluctuation
- Présentation de John Uhlmann à la Black Hat Asia 2023
- DEF CON 30 - Kyle Avery - Avoiding Memory Scanners - Customizing Malware to Evade YARA, PE-siev
- https://blog.tofile.dev/2022/11/30/kdu_sealighter.html
Annexe
Mise en place de l'environnement de test
Pour reproduire un environnement de production réaliste et soutenir à la fois la recherche défensive et l'émulation d'adversaires, nous déployons un laboratoire dédié composé de deux machines virtuelles :
- Une VM Windows « victime » utilisée pour tester les malwares, les expériences de fluctuation de shellcode et la collecte de télémétrie sur les endpoints.
- Une VM d'infrastructure basée sur Debian hébergeant la stack Elastic (SIEM + EDR) et un serveur C2 séparé.
Cette configuration offre un écosystème équilibré où l'activité offensive peut être surveillée, mesurée et utilisée pour dériver de nouveaux indicateurs de détection sans dépendre des règles de détection existantes.
La VM Windows victime
La machine victime fonctionne sous Windows 11 25H2 (x86_64).
Sysmon et l’EDR Elastic EDR sont installés pour enrichir la télémétrie disponible lors des tests.
Gestion de Windows Defender lors du développement du malware
Lorsqu'on reverse ou développe des logiciels malveillants, Windows Defender devient rapidement un obstacle majeur. Même lorsqu'il est temporairement désactivé (y compris la soumission cloud pour des raisons OPSEC), ses mécanismes d'autoprotection finissent par le réactiver, souvent sans préavis. Les astuces classiques de « désactiver Defender » (modifications du registre, ajustements de la politique de groupe, etc.) sont désormais largement inefficaces sur les versions modernes de Windows. Heureusement, l'outil windows-defender-remover offre actuellement un moyen fiable et automatisé de supprimer complètement Defender pour les scénarios de test et de recherche. Au moment où j'écris ces lignes, il fonctionne parfaitement sur les versions modernes de Windows.
Sysmon pour une meilleure télémétrie
Les journaux natifs de Windows manquent de structure et de cohérence pour l'analyse. Pour obtenir une télémétrie plus riche, plus lisible et plus exploitable, installez Sysmon en utilisant le one-liner suivant :
La stack Elastic (VM Debian)
Sur la deuxième VM (Debian Trixie), la stack Elastic est déployée. Bien qu'Elastic soit souvent présenté comme lourd et difficile à installer, il reste l'un des meilleurs écosystèmes SIEM/EDR open source disponible aujourd'hui. Utiliser Elastic Container Project pour mettre en place un environnement Elastic et Fleet pleinement fonctionnel simplifie considérablement le déploiement grâce à docker.
Configuration de la politique d'agent elastic
Lors de la configuration de la politique déployée sur l'agent, les intégrations suivantes sont activées :
- system – Fournit des capacités de surveillance basique de l’hôte. Il collecte les métriques système ainsi que les journaux d'événements principaux de Windows tels que les EVTX des canaux Application, System, et Security.
- Windows – Étend la couverture télémétrique spécifique à Windows. Cette intégration regroupe des canaux d'événements supplémentaires, notamment AppLocker, Defender et Sysmon.
- Elastic Defend – Il s’agit de la composante EDR. Toutes les règles de prévention ont été modifiées de « bloquer » à « détecter », afin de ne pas interférer avec les tests offensifs en
cours. Cette configuration garantit que les détections sont enregistrées pour analyse, sans interrompre les processus ni bloquer les comportements malveillants pendant les tests.
Notez que si vous ne savez pas quelle télémétrie une solution de sécurité collecte réellement, edr-telemetry.com offre un aperçu objectif des capacités de collecte des principaux EDR.
