La structure `OB_CALLBACK` mentionnée ci-dessus est également non documentée, et est définie
par :```C
typedef struct OB_CALLBACK_t {
    USHORT Version;                           // usually 0x100
    USHORT OperationRegistrationCount;        // number of registered callbacks
    PVOID RegistrationContext;                // arbitrary data passed at registration time
    UNICODE_STRING AltitudeString;            // used to determine callbacks order
    struct OB_CALLBACK_ENTRY_t EntryItems[1]; // array of OperationRegistrationCount items
    WCHAR AltitudeBuffer[1];                  // is AltitudeString.MaximumLength bytes long, and pointed by AltitudeString.Buffer
} OB_CALLBACK;

Faire pointer les pointeurs `Flink` et `Blink` de la `LIST_ENTRY` de `CallbackList` vers
la `LIST_ENTRY` elle-même rend effectivement la liste vide. Comme la structure `_OBJECT_TYPE`
est publiée dans les symboles du noyau, la technique ne repose pas sur des décalages/structures
codés en dur. Cependant, elle présente quelques inconvénients.

Le premier est de ne pas pouvoir désactiver uniquement les callbacks de l'EDR ; en effet, la technique
affecte tous les callbacks d'objets qui auraient pu être enregistrés par un logiciel « légitime ».
Il convient néanmoins de noter que les callbacks d'objets ne sont utilisés par aucun composant
préinstallé sur Windows 10 (au moment de la rédaction), donc leur désactivation ne devrait pas affecter
la stabilité de la machine (encore moins si la désactivation n'est que temporaire).

Le second inconvénient est que les opérations sur les handles de processus ou de threads sont vraiment
fréquentes (presque continues) dans le fonctionnement normal du système d'exploitation. Ainsi, si la
primitive d'écriture dans le noyau utilisée ne peut pas effectuer une écriture `QWORD` « de manière
atomique », il y a de fortes chances que le pointeur `_OBJECT_TYPE.CallbackList.Flink` soit accédé
par le noyau au milieu de sa réécriture. Par exemple, le pilote vulnérable MSI `RTCore64.sys` ne peut
effectuer qu'une écriture `DWORD` à la fois, donc 2 IOCTL distincts seront nécessaires pour écraser
le pointeur, entre lesquels le noyau a une forte probabilité de l'utiliser (provoquant un crash).
En revanche, le pilote vulnérable DELL `DBUtil_2_3.sys` peut effectuer des écritures de tailles
arbitraires en un seul IOCTL, donc utiliser cette méthode avec lui ne risque pas de provoquer un
crash.

#### Désactiver complètement les callbacks d'objets
Une dernière technique que nous avons trouvée consiste à désactiver entièrement le support des
callbacks d'objets pour les threads et les processus. À l'intérieur de la structure `_OBJECT_TYPE`
correspondant aux types processus et thread se trouve un champ `TypeInfo`, suivant la structure
documentée `_OBJECT_TYPE_INITIALIZER`. Ce dernier contient un champ de bits `ObjectTypeFlags`,
dont le drapeau `SupportsObjectCallbacks` détermine si le type d'objet décrit (Processus, Thread,
Bureau, Jeton, Fichier, etc.) supporte ou non l'enregistrement de callbacks d'objets. Comme indiqué
précédemment, seuls les types d'objets Processus, Thread et Bureau supportent ces callbacks sur une
installation Windows au moment de la rédaction.

Puisque le bit `SupportsObjectCallbacks` est vérifié par `ObpCreateHandle` ou `ObDuplicateObject`
avant même de lire la `CallbackList` (et avant d'exécuter les callbacks, bien sûr), inverser ce bit
à l'exécution dans le noyau désactive effectivement toute exécution de callbacks d'objets.

Le principal inconvénient de cette méthode est simplement que *KPP* (« *PatchGuard* ») surveille
l'intégrité de certaines (toutes ?) structures `_OBJECT_TYPE`, et déclenche un
[`0x109 Bug Check`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption)
avec le paramètre 4 égal à `0x8`, ce qui signifie qu'une structure de type d'objet a été modifiée.

Cependant, effectuer la désactivation / réactivation (et l'action « malveillante » entre les deux)
assez rapidement devrait suffire à « distancer » *PatchGuard* (sauf si vous êtes malchanceux et
qu'une vérification périodique est effectuée au mauvais moment).

### Contournement de l'EDR via le déliement des callbacks des minifiltres
Le système Windows Filter Manager permet à un EDR de charger un pilote « minifilter » et
d'enregistrer des callbacks afin d'être notifié des opérations d'E/S, telles que l'ouverture de
fichiers, la lecture, l'écriture, etc.

Voici un bref résumé des différentes structures internes utilisées par le gestionnaire de filtres :
- Le gestionnaire de filtres établit un « frame » (`_FLTP_FRAME`) comme structure racine ;
- Une structure « volume » (`_FLT_VOLUME`) est instanciée pour chaque « disque » géré par le
gestionnaire de filtres (peut être des partitions, des clichés instantanés, ou des volumes spéciaux
correspondant aux pipes nommés ou aux systèmes de fichiers distants) ;
- À chaque pilote minifilter enregistré correspond une structure « filtre » (`_FLT_FILTER`),
décrivant diverses propriétés telles que ses opérations supportées ;
- Ces minifiltres ne sont pas tous attachés à chaque volume ; une structure « instance »
(`_FLT_INSTANCE`) est créée pour marquer chaque association
filtre<->volume ;
- Les minifiltres enregistrent des fonctions de callback qui doivent être exécutées avant et/ou après
des opérations spécifiques (ouverture de fichier, écriture, lecture, etc.). Ces callbacks sont
décrits dans des structures `_CALLBACK_NODE`, et peuvent être accédés de différentes manières :
  - Un tableau de tous les `_CALLBACK_NODE` implémentés par une instance d'un minifilter
    peut être trouvé dans la structure `_FLT_INSTANCE` ; le tableau est indexé par le code
    « fonction majeure » IRP, une constante représentant les opérations gérées par les
    callbacks (`IRP_MJ_CREATE`, `IRP_MJ_READ`, etc.).
  - De plus, tous les `_CALLBACK_NODE` implémentés par les instances liées à un volume spécifique
  sont regroupés dans des listes chaînées, stockées dans le tableau
  `_FLT_VOLUME.Callbacks.OperationLists` indexé par les codes de fonction majeure IRP.

Ces différentes structures sont parcourues par `EDRSandblast` pour détecter les filtres qui sont
associés à des pilotes liés à l'EDR, et les nœuds de callback contenant des fonctions de
surveillance sont énumérés. Pour désactiver leur effet, les nœuds sont déliés de leurs listes,
les rendant temporairement invisibles pour le gestionnaire de filtres.

Ainsi, pendant une période spécifiée, l'EDR peut être complètement inconscient de toute opération
sur les fichiers. Un exemple simple serait la création d'un fichier de dump mémoire lsass sur le
disque, qui ne déclencherait aucune analyse de la part de l'EDR, et donc aucune détection basée
sur le fichier lui-même.

### Contournement de l'EDR via la désactivation du fournisseur ETW Microsoft-Windows-Threat-Intelligence

Le fournisseur `ETW Microsoft-Windows-Threat-Intelligence` enregistre des données sur les
utilisations de certaines API Windows couramment utilisées de manière malveillante. Cela inclut
l'API `nt!MiReadWriteVirtualMemory`, appelée par `nt!NtReadVirtualMemory` (qui est
utilisée pour dumper la mémoire de `LSASS`) et surveillée par la fonction
`nt!EtwTiLogReadWriteVm`.

Les produits EDR peuvent consommer les journaux produits par le fournisseur `ETW TI` via
des services ou des processus s'exécutant respectivement sous les droits
`SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT` ou
`PS_PROTECTED_ANTIMALWARE_LIGHT`, et associés à un pilote
`Early Launch Anti Malware (ELAM)`.

Comme publié par
[`slaeryan` dans un article de blog `CNO Development Labs`](https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider),
le fournisseur `ETW TI` peut être désactivé complètement en patchant, dans la mémoire du noyau,
son attribut `ProviderEnableInfo` à `0x0`. Référez-vous à l'excellent article de blog susmentionné
pour plus d'informations sur la technique.

De manière similaire à la suppression des callbacks du noyau, les décalages nécessaires de
`ntoskrnl.exe` (`nt!EtwThreatIntProvRegHandleOffset`, `GuidEntry` de `_ETW_REG_ENTRY`, et
`ProviderEnableInfo` de `_ETW_GUID_ENTRY`) sont calculés dans le fichier
`NtoskrnlOffsets.csv` pour un certain nombre de versions du noyau Windows.

### Contournement de l'EDR via le contournement du hooking en espace utilisateur
#### Comment fonctionne le hooking en espace utilisateur
Afin de surveiller facilement les actions effectuées par les processus, les produits EDR déploient
souvent un mécanisme appelé *hooking en espace utilisateur*. Tout d'abord, les produits EDR
enregistrent un callback du noyau (généralement des callbacks de *chargement d'image* ou de
*création de processus*, voir ci-dessus) qui leur permet d'être notifiés à chaque démarrage de
processus.

Lorsqu'un processus est chargé par Windows, et avant qu'il ne démarre réellement, l'EDR est capable
d'injecter une DLL personnalisée dans l'espace d'adressage du processus, qui contient sa logique
de surveillance. Pendant le chargement, cette DLL injecte des « hooks » au début de chaque fonction
qui doit être surveillée par l'EDR. À l'exécution, lorsque les fonctions surveillées sont appelées
par le processus sous surveillance, ces hooks redirigent le flux de contrôle vers un code de
supervision présent dans la DLL de l'EDR, ce qui lui permet d'inspecter les arguments et les
valeurs de retour de ces appels.

La plupart du temps, les fonctions surveillées sont des appels système (tels que
`NtReadVirtualMemory`, `NtOpenProcess`, etc.), dont les implémentations résident dans `ntdll.dll`.
Intercepter les appels aux fonctions `Nt*` permet aux produits d'être aussi proches que possible
de la frontière espace utilisateur / espace noyau (tout en restant en espace utilisateur), mais
les fonctions de certaines DLL de plus haut niveau peuvent également être surveillées.

Voici des exemples de la même fonction, avant et après avoir été hookée par le produit EDR :```assembly
NtProtectVirtualMemory   proc near
	mov r10, rcx
	mov eax, 50h
	test byte ptr ds:7FFE0308h, 1
	jnz short loc_18009D1E5
	syscall
	retn
loc_18009D1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp			

#### Détection des hooks
Les hooks en espace utilisateur ont la « faiblesse » de se trouver dans la mémoire utilisateur, ce qui signifie qu'ils sont
directement observables et modifiables par le processus surveillé. Pour détecter automatiquement
les hooks dans l'espace d'adressage du processus, l'idée principale est de comparer les différences entre
la DLL originale sur disque et la bibliothèque résidant en mémoire, qui a été potentiellement
modifiée par un EDR. Pour effectuer cette comparaison, EDRSandblast suit les étapes suivantes :
* La liste de toutes les DLL chargées est énumérée grâce à la `InLoadOrderModuleList` située
  dans le `PEB` (pour éviter d'appeler une API qui pourrait être surveillée et suspecte)
* Pour chaque DLL chargée, son contenu sur disque est lu et ses en-têtes analysés. La
  bibliothèque correspondante, résidant en mémoire, est également analysée pour identifier les sections, les exports,
  etc.
* Les relocalisations de la DLL sont analysées et appliquées, en tenant compte de l'adresse de base de la
  bibliothèque chargée correspondante. Cela permet au contenu de la bibliothèque en mémoire et de la DLL
  provenant du disque d'avoir exactement le même contenu (sur les sections où les relocalisations sont appliquées),
  rendant ainsi la comparaison fiable.
* Les fonctions exportées sont énumérées et les premiers octets des versions « en mémoire » et « sur disque »
  sont comparés. Toute différence indique une altération effectuée après
  le chargement de la DLL, et est donc très probablement un hook d'EDR.

Remarque : Le processus peut être généralisé pour trouver des différences n'importe où dans les sections non inscriptibles
et pas seulement au début des fonctions exportées, par exemple si les produits EDR commencent à
appliquer des hooks au milieu d'une fonction :) Ainsi, non utilisé par l'outil, cela a été
implémenté dans `findDiffsInNonWritableSections`.

Afin de contourner la surveillance effectuée par ces hooks, plusieurs techniques sont
possibles, chacune ayant ses avantages et inconvénients.

#### Contournement de hook par ... dé-hooking
La méthode la plus intuitive pour contourner la surveillance basée sur les hooks est de supprimer les
hooks. Puisque les hooks sont présents dans une mémoire accessible par le processus lui-même, pour
supprimer un hook, le processus peut simplement :
* Modifier les permissions de la page où se trouve le hook (RX -> RWX ou RW)
* Écrire les octets d'origine connus grâce au contenu de la DLL sur disque
* Rétablir les permissions à RX

Cette approche est assez simple et peut être utilisée pour supprimer tous les hooks détectés d'un seul
coup. Effectuée par un outil offensif au début de son exécution, elle permet au reste du code
d'être complètement ignorant du mécanisme de hooking et de fonctionner normalement sans être
surveillé.

Cependant, elle présente deux inconvénients majeurs. L'EDR surveille probablement l'utilisation de
`NtProtectVirtualMemory`, donc l'utiliser pour modifier les permissions de la page où les
hooks ont été installés est (au moins conceptuellement) une mauvaise idée. Aussi, si un thread est
exécuté par l'EDR et vérifie périodiquement l'intégrité des hooks, cela pourrait également
déclencher une détection.

Pour les détails d'implémentation, consultez le chemin de code de la fonction `unhook()` lorsque `unhook_method` est
`UNHOOK_WITH_NTPROTECTVIRTUALMEMORY`.

**Remarque importante : par souci de simplicité, cette technique est implémentée dans EDRSandblast comme la
technique de base utilisée pour *démontrer* les autres techniques de contournement ; chacune d'elles montre
comment obtenir une version non surveillée de `NtProtectVirtualMemory`, mais effectue la même opération ensuite (dé-hooking d'un hook spécifique).**

#### Contournement de hook par un trampoline personnalisé
Pour contourner un hook spécifique, il est possible de simplement « sauter par‑dessus » et d'exécuter le reste de
la fonction tel quel. D'abord, les octets d'origine de la fonction surveillée, qui ont été
écrasés par l'EDR pour installer le hook, doivent être récupérés à partir du fichier DLL. Dans notre
exemple de code précédent, cela correspondrait aux octets correspondant aux instructions suivantes :```assembly
mov r10, rcx
mov eax, 50h

Enfin, nous concaténons ces opcodes, les stockons dans une mémoire (nouvellement) exécutable et conservons un pointeur vers eux. Cet objet est appelé un "*trampoline*" et peut ensuite être utilisé comme un pointeur de fonction, strictement équivalent à la fonction originale `NtProtectVirtualMemory`.

Le principal avantage de cette technique, comme pour toutes les techniques ci-dessous, est que le hook n'est jamais effacé, donc toute vérification d'intégrité effectuée sur les hooks par l'EDR devrait réussir. Cependant, elle nécessite d'allouer de la mémoire d'abord accessible en écriture puis exécutable, ce qui est typique d'une allocation de shellcode, attirant ainsi l'attention de l'EDR.

Pour les détails d'implémentation, consultez le chemin de code de la fonction `unhook()` lorsque `unhook_method` est `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`. Veuillez noter que la technique n'est démontrée que dans notre implémentation et est, en fin de compte, utilisée pour **supprimer** les hooks de la mémoire, comme toutes les techniques ci-dessous.

#### Contournement de hook en utilisant le trampoline de l'EDR lui-même
Le produit EDR, pour que son hook fonctionne, doit sauvegarder quelque part en mémoire les opcodes qu'il a supprimés. Pire (*ou "mieux", du point de vue de l'attaquant*), pour utiliser efficacement les instructions originales, l'EDR s'est probablement alloué un *trampoline* quelque part pour exécuter la fonction originale après avoir intercepté l'appel.

Ce trampoline peut être recherché et utilisé comme remplacement de la fonction hookée, sans avoir besoin d'allouer de la mémoire exécutable, ni d'appeler une API autre que `VirtualQuery`, qui n'est très probablement pas surveillée étant une fonction anodine.

Pour trouver le trampoline en mémoire, nous parcourons tout l'espace d'adressage en utilisant `VirtualQuery` à la recherche de mémoire validée et exécutable. Pour chaque région de mémoire de ce type, nous la scannons pour trouver une instruction de saut qui cible l'adresse suivant les instructions écrasées (`NtProtectVirtualMemory+8` dans notre exemple précédent). Le trampoline peut alors être utilisé pour appeler la fonction hookée sans déclencher le hook.

Cette technique fonctionne étonnamment bien car elle récupère presque tous les trampolines sur les EDR testés. Pour les détails d'implémentation, consultez le chemin de code de la fonction `unhook()` lorsque `unhook_method` est `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`.

#### Contournement de hook en utilisant une DLL en double
Une autre méthode simple pour accéder à une version non surveillée de la fonction `NtProtectVirtualMemory` consiste à charger une copie en double de la bibliothèque `ntdll.dll` dans l'espace d'adressage du processus. Étant donné que deux DLL identiques peuvent être chargées dans le même processus, à condition qu'elles aient des noms différents, nous pouvons simplement copier le fichier légitime `ntdll.dll` vers un autre emplacement, le charger en utilisant `LoadLibrary` (ou réimplémenter le processus de chargement), et accéder à la fonction en utilisant `GetProcAddress` par exemple.

Cette technique est très simple à comprendre et à implémenter, et a de bonnes chances de succès, car la plupart des produits EDR ne réinstallent pas de hooks sur les DLL nouvellement chargées une fois le processus en cours d'exécution. Cependant, le principal inconvénient est que copier des binaires signés par Microsoft sous un nom différent est souvent considéré comme suspect par les produits EDR eux-mêmes.

Cette technique est néanmoins implémentée dans `EDRSandblast`. Pour les détails d'implémentation, consultez le chemin de code de la fonction `unhook()` lorsque `unhook_method` est `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY`.

#### Contournement de hook en utilisant des appels système directs
Afin d'utiliser des fonctions liées aux appels système, un programme peut réimplémenter les appels système (en assembleur) pour appeler les fonctionnalités correspondantes du système d'exploitation sans toucher au code dans `ntdll.dll`, qui pourrait être surveillé par l'EDR. Cela contourne complètement tout hook en espace utilisateur effectué sur les fonctions d'appel système dans `ntdll.dll`.

Cela a néanmoins quelques inconvénients. Premièrement, cela implique de pouvoir connaître la liste des numéros d'appel système des fonctions dont le programme a besoin, qui changent pour chaque version de Windows. Cela est néanmoins atténué en implémentant plusieurs heuristiques connues pour fonctionner sur toutes les versions passées de Windows NT (tri des exports `Zw*` de `ntdll`, recherche de l'instruction `mov rax, #syscall_number` dans la fonction `ntdll` associée, etc.), et en vérifiant qu'elles renvoient toutes le même résultat (voir `Syscalls.c` pour plus de détails).

De plus, les fonctions qui ne sont techniquement pas des appels système (par exemple `LoadLibraryX`/`LdrLoadDLL`) pourraient également être surveillées, et ne peuvent pas simplement être réimplémentées en utilisant un appel système.

La technique des appels système directs est implémentée dans EDRSandblast. Comme indiqué précédemment, elle est uniquement utilisée pour exécuter `NtProtectVirtualMemory` en toute sécurité, et supprimer tous les hooks détectés.

Pour les détails d'implémentation, consultez le chemin de code de la fonction `unhook()` lorsque `unhook_method` est `UNHOOK_WITH_DIRECT_SYSCALL`.

### Exploitation de drivers vulnérables
Comme indiqué précédemment, toute action nécessitant une lecture ou écriture en mémoire noyau repose sur un driver vulnérable pour fournir cette primitive. Dans EDRSandblast, ajouter le support d'un nouveau driver fournissant la primitive de lecture/écriture peut être fait "facilement", seules trois fonctions doivent être implémentées :

* Une fonction `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`, qui copie `Size` octets de l'adresse noyau `Address` vers le tampon espace utilisateur `Buffer` ;
* Une fonction `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`, qui copie `Size` octets du tampon espace utilisateur `Buffer` vers l'adresse noyau `Address` ;
* Une fonction `CloseDriverHandle_DRIVERNAME()` qui garantit que tous les handles du driver sont fermés (nécessaire avant l'opération de désinstallation qui est indépendante du driver, pour le moment).

À titre d'exemple, deux drivers sont actuellement supportés par EDRSandblast, `RTCore64.sys` (SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`) et `DBUtils_2_3.sys` (SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`). Le code suivant dans `KernelMemoryPrimitives.h` doit être mis à jour si le driver vulnérable utilisé doit être changé, ou si un nouveau est implémenté.```C
#define RTCore 0
#define DBUtil 1
// Select the driver to use with the following #define
#define VULN_DRIVER RTCore

#if VULN_DRIVER == RTCore
#define DEFAULT_DRIVER_FILE TEXT("RTCore64.sys")
#define CloseDriverHandle CloseDriverHandle_RTCore
#define ReadMemoryPrimitive ReadMemoryPrimitive_RTCore
#define WriteMemoryPrimitive WriteMemoryPrimitive_RTCore
#elif VULN_DRIVER == DBUtil
#define DEFAULT_DRIVER_FILE TEXT("DBUtil_2_3.sys")
#define CloseDriverHandle CloseDriverHandle_DBUtil
#define ReadMemoryPrimitive ReadMemoryPrimitive_DBUtil
#define WriteMemoryPrimitive WriteMemoryPrimitive_DBUtil
#endif

### Options```
-h | --help             Show this help message and exit.
-v | --verbose          Enable a more verbose output.

Actions mode:

        audit                     Display the user-land hooks and / or Kernel callbacks without taking actions.
        dump                      Dump the process specified by --process-name (LSASS process by default), as '<process_name>' in the current directory or at the
                                  specified file using -o | --output <DUMP_FILE>.
        cmd                       Open a cmd.exe prompt.
        credguard                 Patch the LSASS process' memory to enable Wdigest cleartext passwords caching even if
                                  Credential Guard is enabled on the host. No kernel-land actions required.
        firewall                  Add Windows firewall rules to block network access for the EDR processes / services.
        load_unsigned_driver      Load the specified unsigned driver, bypassing Driver Signature Enforcement (DSE).
                                  WARNING: currently an experimental feature, only works if KDP is not present and enabled.

--usermode              Perform user-land operations (DLL unhooking).
--kernelmode            Perform kernel-land operations (Kernel callbacks removal and ETW TI disabling).


Hooking-related options:

--add-dll <dll name or path>            Loads arbitrary libraries into the process' address space, before starting
                                        anything.This can be useful to audit userland hooking for DLL that are not
                                        loaded by default by this program. Use this option multiple times to load
                                        multiple DLLs all at once.
                                        Example of interesting DLLs to look at: user32.dll, ole32.dll, crypt32.dll,
                                        samcli.dll, winhttp.dll, urlmon.dll, secur32.dll, shell32.dll...

--unhook-method <N>                     Choose the userland un-hooking technique, from the following:

        0                               Do not perform any unhooking (used for direct syscalls operations).
        1 (Default)                     Uses the (probably monitored) NtProtectVirtualMemory function in ntdll to remove all
                                        present userland hooks.
        2                               Constructs a 'unhooked' (i.e. unmonitored) version of NtProtectVirtualMemory, by                                        allocating an executable trampoline jumping over the hook, and remove all present
                                        userland hooks.
        3                               Searches for an existing trampoline allocated by the EDR itself, to get an 'unhooked'
                                        (i.e. unmonitored) version of NtProtectVirtualMemory, and remove all present userland
                                        hooks.
        4                               Loads an additional version of ntdll library into memory, and use the (hopefully                                        unmonitored) version of NtProtectVirtualMemory present in this library to remove all
                                        present userland hooks.
        5                               Allocates a shellcode that uses a direct syscall to call NtProtectVirtualMemory,                                        and uses it to remove all detected hooks

--direct-syscalls       Use direct syscalls to dump the selected process memory without unhooking unserland hooks.


BYOVD options:

--dont-unload-driver                    Keep the vulnerable driver installed on the host
                                        Default to automatically unsinstall the driver.
--no-restore                            Do not restore the EDR drivers' Kernel Callbacks that were removed.
                                        Default to restore the callbacks.
--vuln-driver <gdrv.sys>                Path to the vulnerable driver file.
                                        Default to 'gdrv.sys' in the current directory.
--vuln-service <SERVICE_NAME>           Name of the vulnerable service to intall / start.


Driver sideloading options:

--unsigned-driver <evil.sys>            Path to the unsigned driver file.
                                        Default to 'evil.sys' in the current directory.
--unsigned-service <SERVICE_NAME>       Name of the unsigned driver's service to intall / start.
--no-kdp                                Switch to g_CiOptions patching method for disabling DSE (default is callback swapping).


Offset-related options:

--nt-offsets <NtoskrnlOffsets.csv>      Path to the CSV file containing the required ntoskrnl.exe's offsets.
                                        Default to 'NtoskrnlOffsets.csv' in the current directory.
--fltmgr-offsets <FltmgrOffsets.csv>    Path to the CSV file containing the required fltmgr.sys's offsets
                                        Default to 'FltmgrOffsets.csv' in the current directory.
--wdigest-offsets <WdigestOffsets.csv>  Path to the CSV file containing the required wdigest.dll's offsets
                                        (only for the 'credguard' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
--ci-offsets <CiOffsets.csv>            Path to the CSV file containing the required ci.dll's offsets
                                        (only for the 'load_unsigned_driver' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
-i | --internet                         Enables automatic symbols download from Microsoft Symbol Server
                                        If a corresponding *Offsets.csv file exists, appends the downloaded offsets to the file for later use
                                        OpSec warning: downloads and drops on disk a PDB file for the corresponding image

Dump options:

-o | --dump-output <DUMP_FILE>          Output path to the dump file that will be generated by the 'dump' mode.
                                        Default to 'process_name' in the current directory.
--process-name <NAME>                   File name of the process to dump (defaults to 'lsass.exe')

## Détection
Du point de vue du défenseur (éditeur d'EDR, Microsoft, analystes SOC examinant la télémétrie de l'EDR, ...), plusieurs indicateurs peuvent être utilisés pour détecter ou prévenir ce type de techniques.

### Liste blanche de pilotes
Étant donné que chaque action effectuée par l'outil en mémoire en mode noyau repose sur un pilote vulnérable pour lire/écrire du contenu arbitraire, les événements de chargement de pilotes devraient être lourdement scrutés par le produit EDR (ou les analystes SOC), et déclencher une alerte pour tout chargement de pilote inhabituel, voire bloquer les pilotes vulnérables connus. Cette dernière approche est même [recommandée par Microsoft eux-mêmes](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules) : tout appareil Windows avec HVCI (*Hypervisor-protected code integrity*) activé intègre une liste de blocage de pilotes, et cela deviendra progressivement un comportement par défaut sur Windows (c'est déjà le cas sur Windows 11).

### Vérifications d'intégrité de la mémoire du noyau
Puisqu'un attaquant pourrait quand même utiliser un pilote vulnérable inconnu pour effectuer les mêmes actions en mémoire, le pilote de l'EDR pourrait vérifier périodiquement que ses callbacks du noyau sont toujours enregistrés, directement en inspectant la mémoire du noyau (comme le fait cet outil), ou simplement en déclenchant des événements (création de processus, création de thread, chargement d'image, etc.) et en vérifiant que les fonctions de callback sont bien appelées par le noyau exécutif.

En remarque, ce type de structure de données pourrait être protégé via le récent mécanisme [Kernel Data Protection (KDP)](https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/), qui repose sur la sécurité basée sur la virtualisation, afin de rendre le tableau de callbacks du noyau non inscriptible sans appeler les bonnes API.

La même logique pourrait s'appliquer à des variables ETW sensibles telles que `ProviderEnableInfo`, abusée par cet outil pour désactiver la génération d'événements ETW Threat Intelligence.

### Détection en mode utilisateur
Le premier indicateur qu'un processus tente activement de contourner le hooking en mode utilisateur est l'accès aux fichiers pour chaque DLL correspondant aux modules chargés ; dans une exécution normale, un processus en mode utilisateur a rarement besoin de lire des fichiers DLL en dehors d'un appel `LoadLibrary`, en particulier `ntdll.dll`.

Afin de protéger le hooking des API contre un contournement, les produits EDR pourraient vérifier périodiquement que les hooks ne sont pas modifiés en mémoire, à l'intérieur de chaque processus surveillé.

Enfin, pour détecter un contournement de hooking (abus d'une trampoline, utilisation d'appels système directs, etc.) qui n'implique pas la suppression des hooks, les produits EDR pourraient potentiellement s'appuyer sur les callbacks du noyau associés aux appels système abusés (ex. `PsCreateProcessNotifyRoutine` pour l'appel système `NtCreateProcess`, `ObRegisterCallbacks` pour l'appel système `NtOpenProcess`, etc.), et effectuer une analyse de la pile d'appels en mode utilisateur afin de déterminer si l'appel système a été déclenché depuis un chemin normal (`kernel32.dll` -> `ntdll.dll` -> syscall) ou anormal (ex. `program.exe` -> syscall direct).


## Remerciements

- Énumération et suppression des callbacks du noyau :
  https://github.com/br-sn/CheekyBlinder

- Primitives de lecture / écriture en mémoire du noyau via le pilote vulnérable
  `Micro-Star MSI Afterburner` :
  https://github.com/Barakat/CVE-2019-16098/

- Désactivation du fournisseur ETW Threat Intelligence :
  https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider

- Installation / désinstallation de pilote : https://github.com/gentilkiwi/mimikatz

- Liste initiale des noms de pilotes EDR :
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- Contournement de Credential Guard en réactivant `Wdigest` via le patching
  mémoire de `LSASS` : https://teamhydra.blog/2020/08/25/bypassing-credential-guard/


## Auteurs

[Thomas DIOT (Qazeer)](https://github.com/Qazeer/)
[Maxime MEIGNAN (themaks)](https://github.com/themaks)

## Remerciements aux contributeurs
- [v1k1ngfr](https://github.com/v1k1ngfr) : pour le contournement de la vérification de signature des pilotes (via le patching de `g_CiOptions`) et le support du pilote GDRV.sys
- [Windy Bug](https://github.com/0mWindyBug) : pour un contournement de la vérification de signature des pilotes compatible KDP (via l'échange de callbacks) et leur contribution majeure sur la fonctionnalité de contournement du minifiltre


## Licence

Licence CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/