Au cœur des stratégies de défense des terminaux, les EDR se positionnent comme des compléments, voire remplaçants, efficaces des solutions antivirales classiques. Cet article étudie différentes techniques permettant de contourner les mécanismes de supervision des EDR (user-land hooking, Kernel Callbacks, et évènements Threat Intelligence). Dans le cadre de cet article, une « boite à outils » implémentant les diverses techniques d’évasion mentionnées a été développée [EDRSANDBLAST].
Les mécanismes permettant aux EDR de superviser les opérations réalisées sur un système Windows sont étudiés et présentés plus en détail dans l’article « Tour d’horizon des mécanismes de supervision des EDR », publié dans MISC n°116 [ARTICLE].
1. Contournement du user-land hooking
Un produit de sécurité souhaitant intercepter une action d’un processus sur le système pour l’analyser peut injecter du code dans la chaîne d’exécution de l’opération. Suite à l’introduction de Kernel Patch Protection (KPP), aussi connu sous le nom de « PatchGuard », cette injection ne peut être réalisée que côté user-land. Elle est généralement réalisée en utilisant la technique du hooking ou détour, consistant à écraser une partie du code d’une fonction ciblée afin d’injecter un appel à une fonction d’analyse dans le flot normal d’exécution (voir [DETOUR]).
La technique du user-land hooking présente toutefois un inconvénient majeur pour le produit de sécurité : les modifications apportées par l’EDR sont visibles en mémoire par le processus sous surveillance et sont potentiellement réversibles, sans aucun privilège spécifique. Cette partie décrit différentes techniques (dont certaines sont implémentées dans le projet EDRSandblast) permettant de détecter la présence de ces hooks en mémoire et de contourner cette surveillance.
1.1 Détection du hook
Une approche naïve de détection d’un hook en mémoire consisterait à scanner l’ensemble des débuts des fonctions exportées de ntdll.dll à la recherche d’une instruction de jmp (telle que couramment implémenté). Les hooks pouvant être implémentés différemment ou l’instruction jmp pouvant être présente légitimement, on préfèrera donc une approche moins heuristique.
Afin de détecter systématiquement toute modification introduite dans les bibliothèques chargées en mémoire, il est possible par exemple de comparer le contenu présent dans le fichier DLL sur disque avec le contenu chargé en mémoire. Pour cela, quelques considérations techniques sont à prendre en compte pour éviter les faux-positifs :
- seules les sections non-écrivables doivent être comparées (dont font normalement partie les sections exécutables) ;
- les sections présentes dans le fichier DLL doivent être positionnées correctement en mémoire relativement les unes par rapport aux autres afin de faciliter la comparaison ;
- les relocations, mécanismes pouvant introduire des modifications légitimes dans des sections non écrivables lors du chargement de la DLL, doivent être prises en compte avant d’effectuer la comparaison.
Une implémentation d’un mini parser PE visant à implémenter ces points et comparer une DLL en mémoire avec son contenu sur disque est présente dans le projet EDRSandblast. La sortie présente ci-dessous montre les différentes modifications détectées dans les bibliothèques chargées par le programme, et les interprète comme des hooks lorsque possible.
1.2 Suppression du hook
Une fois la modification identifiée, il est aisé de restaurer le code écrasé par le hook placé par l’EDR, puisqu'il correspond à celui présent sur disque, utilisé lors de la détection du hook. Il est donc possible par exemple de restaurer le code en appelant la fonction VirtualProtect pour rendre la page contenant le hook écrivable et en recopiant le code correspondant issu de la DLL afin de supprimer la surveillance de l’EDR sur la fonction ciblée.
Néanmoins, cette stratégie est risquée puisqu’elle implique l’utilisation d’un appel système très probablement surveillé, NtProtectVirtualMemory, pour passer écrivable une section de code de ntdll.dll. De plus, l’EDR pourrait surveiller périodiquement la présence des hooks en mémoire, et lever une alerte en cas d’altération.
1.3 Contournement via trampoline
Au lieu de supprimer les hooks en mémoire, il est possible de créer des variantes « non-surveillées » des fonctions ciblées par l’EDR en exploitant le concept de trampoline (voir [DETOUR]). Pour une fonction hookée donnée (ex. NtOpenProcess), il est en effet possible d’allouer de la mémoire exécutable contenant les instructions écrasées par l’EDR suivies d’un saut vers les instructions qui suivent le hook dans la fonction originale.
L’utilisation du trampoline (à gauche sur la Figure 1) permet l’appel à la fonction NtOpenProcess sans déclencher le code de l’EDR.
Cette technique nécessite l’allocation d’une faible quantité de mémoire écrivable puis exécutable à une position arbitraire, ce qui a peu de chance de déclencher une alerte côté EDR.
Une variante possible ne nécessitant aucune allocation serait la recherche du trampoline alloué par l’EDR (inclus dans la partie droite de la figure) dans la mémoire virtuelle du processus. Selon l’EDR utilisé, ce trampoline pourrait être utilisable en l’état, et fournirait donc au processus « malveillant » une variante non surveillée dans la fonction à laquelle il est associé.
1.4 Duplication de bibliothèque
L’installation des hooks par l’EDR est toujours réalisée sur des fonctions préalablement identifiées par l’éditeur, incluses dans des bibliothèques spécifiques (ntdll.dll, kernel32.dll…). Cependant sur Windows (comme sur Linux), il est tout à fait possible de charger plusieurs fois une même bibliothèque dans l’espace mémoire d’un processus, si celle-ci est également dupliquée sur le disque.
Par exemple, afin d'utiliser une version non-surveillée de ntdll.dll, un processus peut copier cette bibliothèque sous un autre nom à un endroit arbitraire du disque (C:\Windows\Temp\ntdlol.dl par exemple), la charger à l’aide de LoadLibrary, puis récupérer les adresses des fonctions souhaitées à l’aide de GetProcAddress.
Bien que techniquement simple à implémenter, cette technique peut être détectée par un EDR de plusieurs manières (bien que ce ne soit pas nécessairement le cas sur les EDR testés par les auteurs) :
- La copie d’un binaire connu du système sous un nouveau nom et chemin doit éveiller la suspicion d’un EDR.
- Les fonctions de chargement de bibliothèques (LoadLibrary, LdrLoadDll) peuvent être interceptées par l’EDR pour vérifier si le nom du fichier DLL correspond au nom enregistré dans les en-têtes de celui-ci (l’export directory d’un PE contient un pointeur “Name” vers le nom original de la DLL).
- Si la bibliothèque est reconnue lors de son chargement, l’EDR pourrait réinstaller la surveillance sur les fonctions habituellement surveillées.
1.5 Direct syscalls
Une autre méthode d’évasion des hooks consiste simplement à ne pas utiliser les fonctions surveillées et les réimplémenter au sein du programme souhaitant échapper à la surveillance de l’EDR. Par exemple, au lieu d'appeler la fonction NtOpenProcess présente dans ntdll.dll, le code assembleur réalisant l’appel système correspondant est embarqué au sein du programme et utilisé lorsque nécessaire. Il s’agit de la méthode sur laquelle se base l’outil Dumpert [DUMPERT] pour récupérer la mémoire du processus LSASS.
Si la méthode est conceptuellement simple et efficace pour contourner l’user-land hooking, elle présente quelques inconvénients mineurs. Tout d’abord, elle nécessite une implémentation spécifique de chaque appel système utilisé, alors que celles-ci varient d’une version à l’autre de Windows. De plus, telle qu’implémentée dans Dumpert, la technique est non pas employée pour effectuer le dump mémoire, mais pour retirer les hooks sur les fonctions utilisées par MiniDumpWriteDump (telles que NtReadVirtualMemory), ce qui rend l’implémentation vulnérable à de potentielles détections de l’intégrité des hooks ou à la surveillance de la fonction MiniDumpWriteDump par l’EDR.
2. Suppression des Kernel Callbacks déployés par les EDR
Les EDR sont notifiés par le noyau Windows de divers évènements (création de processus, accès au registre, interaction avec le système de fichiers…) générés par tous les processus en exécution sur le système grâce à des Kernel Callbacks. Notamment, les callbacks permettant d’être informés par le noyau des créations de processus et threads ainsi que des chargements de fichiers PE sont enregistrés, en mémoire noyau, dans les tableaux PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine et PspLoadImageNotifyRoutine. Afin de disposer d’une exécution de code non supervisée, une stratégie de contournement de cette surveillance est donc de retrouver et supprimer les callbacks enregistrés par les EDR au sein de ces tableaux [CALLBACK1] [CALLBACK2].
Bien qu’il serait théoriquement possible pour un EDR de vérifier que ses callbacks soient toujours enregistrés, cette vérification nécessite de l’exécution de code côté kernel et, par besoin de limiter l’usage des ressources système, peut ne pas être réalisée en temps réel. Ce délai entre la suppression des callbacks et leur réenregistrement peut donc être exploité pour exécuter un processus non supervisé.
L’extension pour WinDBG SwishDbgExt peut être utilisée pour automatiser l’énumération des Kernel Callbacks présents au sein des tableaux en mémoire noyau PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine et PspLoadImageNotifyRoutine :
DSE (Driver Signature Enforcement
Introduit dans Windows Vista, Driver Signature Enforcement (DSE) est un mécanisme de protection limitant les installations de pilotes Windows aux produits satisfaisant un certain nombre de prérequis (différents selon la version du système d’exploitation). DSE ne s’applique qu’aux systèmes ayant le mode de démarrage Secure Boot activé.Pour être installés sur les dernières versions de Windows 10, les pilotes doivent :
- être signés numériquement avec un certificat « Extended Validation Code Signing » émis par un organisme approuvé par Microsoft pour les signatures de code noyau (kernel-mode code signing) ;
- être certifiés par le « Windows Hardware Quality Labs (WHQL) » de Microsoft.
Pour des raisons de rétrocompatibilité, les pilotes signés avant le 29/07/2015 peuvent être installés sur les systèmes d’exploitation Windows 10 1803 (et antérieurs) sans besoin de satisfaire aux prérequis ci-dessus. Cette tolérance n’est toutefois plus vraie à partir de Windows 10 1809.
Les tableaux de callbacks étant conservés en mémoire côté noyau, le code exécuté au travers d’un pilote sera en mesure de les modifier (la mémoire entre le noyau Windows et les différents pilotes étant partagée). Étant donné la présence de DSE sur les systèmes Windows, une stratégie possible est d’installer un pilote satisfaisant les prérequis d’installation, mais toutefois affecté par des vulnérabilités de lecture et écriture arbitraires (tel que le pilote Micro-Star MSI Afterburner en version 4.6.2.15658 [AFTERBURNER], vulnérable à la faille de sécurité CVE-2019-16098), afin d'être utilisé pour modifier ces callbacks.
On notera toutefois que l’installation de pilotes requiert le privilège SeLoadDriverPrivilege, usuellement restreint aux membres du groupe local Administrators. Ce privilège est donc nécessaire à la mise en place de la technique décrite ci-après.
Afin de supprimer les callbacks noyau, il est nécessaire de connaître les adresses en mémoire des tableaux PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine et PspLoadImageNotifyRoutine. Le parti a été pris dans l’implémentation de EDRSandblast de faire usage d’offsets, correspondant aux positions des tableaux au sein du module ntoskrnl.exe, plutôt que d’effectuer des recherches de patterns (suites d’octets « caractéristiques » correspondant à des fragments d’instructions ou de données) supposés comme étant présents en mémoire. Ce choix se justifie par le fait qu’aucun pattern permettant d’identifier les positions de ces tableaux de manière fiable et indépendante des différentes versions du noyau n’ait pu être identifié. En cas d’utilisation d’un pattern incompatible avec la version ciblée du noyau, le programme serait donc au mieux non fonctionnel, au pire, source de « Bug Check » (et donc d’« écran bleu de la mort »). Dans le but d’être compatible avec un maximum de versions du système d’exploitation Windows, le script Python NotifyRoutineOffsetsExtract.py a été développé dans le cadre du projet EDRSandblast.
Ce script permet d’automatiser :
- la récupération des versions du ntoskrnl.exe publiées au sein des packages de mises à jour Windows, tel que centralisé par le site Winbindex [WINBINDEX] ;
- le téléchargement des différentes versions du ntoskrnl.exe, depuis les serveurs de symboles Microsoft, à la suite du calcul de l’identifiant propre à chaque version [SYMBOLS] ;
- le téléchargement des symboles de débogage puis l’extraction des offsets à l’aide de la bibliothèque r2pipe (du projet radare2) [R2PIPE].
Suivant ce procédé, les offsets des tableaux PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine et PspLoadImageNotifyRoutine ont pu être obtenus pour plus de 350 versions du noyau Windows.
Sous condition de disposer des offsets pour la version de Windows ciblée, le processus implémenté par EDRSandblast de suppression des callbacks et réalisation du dump mémoire du processus LSASS peut se résumer au :
- parcours des tableaux PspCreateProcessNotifyRoutine, PspCreateThreadNotifyRoutine et PspLoadImageNotifyRoutine ;
- l’extraction, pour chaque structure _EX_CALLBACK_ROUTINE_BLOCK, de la fonction de callback via la primitive de lecture de mémoire virtuelle noyau arbitraire ;
- l’identification, parmi les fonctions énumérées, de celles définies au sein de l’espace mémoire d’un pilote d’EDR pour la mise à 0x0 du pointeur vers la structure de callback associée via la primitive d’écriture de mémoire virtuelle noyau arbitraire ;
- l’exécution d’un nouveau processus dont l’EDR, en l’absence de callback, ne sera pas informé et qui ne sera donc pas sujet aux autres types de surveillance, tels que l'installation de hooks user-land ;
- la réalisation du dump mémoire du processus LSASS (après la désactivation préalable du fournisseur ETW TI, comme explicité dans la partie ci-après) au travers du processus non supervisé nouvellement créé ;
- la restauration des fonctions de callbacks EDR à la suite de la réalisation du dump mémoire afin de préserver l’intégrité du système.
3. Désactivation du fournisseur d’évènements Microsoft-Windows-Threat-Intelligence
Le fournisseur d’évènements pour Windows (« Event Tracing for Windows (ETW) ») « Windows-Threat-Intelligence (TI) », abrégé ETW TI dans la suite de l’article, permet aux EDR de recevoir des informations sur les utilisations faites de certaines API Windows. Par exemple, le fournisseur d’évènements ETW TI permet de journaliser les appels système NtReadVirtualMemory via la fonction EtwTiLogReadWriteVm, ainsi que les informations contextuelles associées (processus source et destination, taille lue, adresse de la mémoire virtuelle concernée...). Les fonctions ETW TI vérifiant systématiquement que le fournisseur d’évènements ETW TI est activé (via un appel à la fonction EtwProviderEnabled), une possibilité de contournement est de faire paraître le fournisseur comme étant désactivé.
Les informations du fournisseur d’évènements étant conservées en mémoire côté noyau, la technique de désactivation présentée ci-dessous, basée sur des travaux de recherche de @slaeryan [DISABLE_ETWTI] implémentée dans EDRSandblast, sera réalisée au travers d’un pilote vulnérable (selon le même principe que pour la suppression des callbacks noyau).
La première étape de la désactivation du fournisseur est de déterminer l’adresse virtuelle de EtwThreatIntProvRegHandle, qui correspond au handle du fournisseur d’évènement ETW TI en mémoire côté noyau. Ce handle, notamment utilisé pour l’écriture des évènements par la fonction EtwWrite, correspond à un pointeur vers la structure _ETW_REG_ENTRY (non documentée officiellement, mais dont la définition est incluse dans les fichiers PDB fournis avec le noyau).
La structure _ETW_REG_ENTRY contient un attribut GuidEntry (offset 0x20 pour la version Windows 10 20H2, build 19042.985) stockant un pointeur vers une structure _ETW_GUID_ENTRY. Cette structure, elle aussi non officiellement documentée, correspond à l’objet ETW TI tel que conservé en mémoire côté noyau.
Au sein de cet objet se trouve le champ ProviderEnableInfo (de type _TRACE_ENABLE_INFO) qui détermine si le fournisseur d’évènements est activé ou non :
Les commandes WinDBG suivantes permettent de consulter l’état du fournisseur d’évènements ETW TI :
La désactivation, puis réactivation, du fournisseur ETW TI est automatisée par EDRSandblast afin de réaliser un dump mémoire du processus LSASS sans génération d’évènements de Threat Intelligence. De manière similaire à la suppression des callbacks noyau, l’identification de l’adresse mémoire virtuelle de l’attribut IsEnabled est réalisée au travers d’offsets, connus pour la version spécifique du noyau ciblé.
Conclusion
Cet article avait pour vocation de donner des exemples de techniques de contournement pouvant être employées pour échapper aux mécanismes de supervision employés par les EDR modernes. Il pourra néanmoins être utile de construire des mécanismes plus complexes s’appuyant sur ces techniques de base, notamment lorsque des contre-mesures seront plus couramment mises en place par les éditeurs.
De nombreuses autres techniques existent pour contourner la supervision des EDR, et n’ont pas été mentionnées dans cet article, par souci de concision et également, car spécifiques à certains produits EDR. Parmi ces techniques, on évoquera la présence de vulnérabilités logiques dans certains produits qui, lorsqu’exploitées, peuvent agir comme killswitch sur des pans entiers de surveillance.
Autre technique propre à chaque produit : la récupération et le décodage des listes d’exclusion (souvent définies en entreprise pour éviter les faux-positifs) permettant à un attaquant d’exécuter du code échappant à la surveillance de l’EDR, ou ne générant jamais d’alerte, si celui-ci répond à des règles spécifiques (chemin d’exécution, nom de fichier, etc.).
Encore aujourd’hui, certaines techniques simples et génériques se basant sur le détournement de binaires légitimes (comsvcs.dll, taskmgr.exe, WerFault.exe…) pour réaliser un dump mémoire du processus LSASS sont toujours tolérées et non assimilées comme un comportement malveillant par de nombreux EDR. Cela peut être dû à un manque de maturité du produit, mais aussi s’expliquer par un choix d’implémentation dont le but serait de limiter les risques de faux positifs.
Enfin, des techniques basées sur l’extraction de mémoire physique via l’utilisation d’un pilote idoine signé (DumpIt, winpmem…) permettent également de contourner la supervision des EDR quant à l’extraction de la mémoire de LSASS, si tant est que le pilote n’est pas explicitement interdit par le produit de sécurité (et que la taille de la RAM du système ciblé permette la création et le transfert du fichier de vidage).
Remerciements
Remerciements à @brsn76945860, @fdiskyou, Benjamin DELPY (@gentilkiwi), @slaeryan et l’ensemble des auteurs ayant réalisé les travaux de recherche sur lesquels se base cet article.
Références
[ARTICLE] https://connect.ed-diamond.com/MISC/misc-116/tour-d-horizon-des-mecanismes-de-supervision-des-edr
[DETOURS] Microsoft, Documentation du framework Detours : https://github.com/microsoft/Detours
[EDRSANDBLAST] Thomas DIOT & Maxime MEIGNAN, EDRSandblast :
https://github.com/wavestone-cdt/EDRSanblast
[CALLBACK1] rui (@fdiskyou), « Windows Kernel Ps Callbacks Experiments » : http://blog.deniable.org/posts/windows-callbacks/
[CALLBACK2] brsn (@brsn76945860), « Removing Kernel Callbacks Using Signed Drivers » :
https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers/
[DUMPERT] Outflank B.V., Dumpert : https://github.com/outflanknl/Dumpert
[AFTERBURNER] Pilote Micro-Star MSI Afterburner version 4.6.2.15658 : http://download-eu2.guru3d.com/afterburner/%5BGuru3D.com%5D-MSIAfterburnerSetup462Beta2.zip
[WINBINDEX] Michael Maltsev (@m417z), Winbindex « The Windows Binaries Index » : https://winbindex.m417z.com/
[SYMBOLS] Bruce Dawson (BruceDawson0xB), « Symbols the Microsoft Way » : https://randomascii.wordpress.com/2013/03/09/symbols-the-microsoft-way/
[R2PIPE] radare org, r2pipe : https://github.com/radareorg/radare2-r2pipe
[DISABLE_ETWTI] Upayan (@slaeryan), « Data Only Attack: Neutralizing EtwTi Provider » : https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider
[WINPMEM] Mike Cohen (@scudette), WinPmem : https://github.com/Velocidex/WinPmem
