wavestone-cdt/edrsandblastArme des pilotes signés vulnérables pour contourner les rappels noyau de l'EDR, les rappels d'objets, le fournisseur ETW TI et les hooks en espace utilisateur pour le vidage mémoire de LSASS et l'extraction d'identifiants.
EDRSandBlast est un outil écrit en C qui exploite un pilote signé vulnérable pour contourner les détections EDR (callbacks de routines de notification, callbacks d'objets et fournisseur ETW TI) et les protections LSASS. De multiples techniques de désaccrochage (unhooking) en mode utilisateur sont également implémentées pour échapper à la surveillance en mode utilisateur.
À la date de publication, la combinaison de techniques en mode utilisateur (--usermode) et en mode noyau (--kernelmode) a été utilisée pour vider la mémoire de LSASS sous la surveillance d'EDR, sans être bloquée ni générer d'événements liés au « Credential Dumping » dans la console (cloud) du produit. Les tests ont été effectués sur 3 produits EDR distincts et ont été couronnés de succès dans chaque cas.
Les produits EDR utilisent les callbacks « Notify Routines » du noyau sous Windows pour être informés par le noyau de l'activité du système, comme la création de processus et de threads, et le chargement d'images (exe / DLL).
Ces callbacks du noyau sont définis depuis l'espace noyau, généralement par le pilote implémentant les callbacks, à l'aide d'un certain nombre d'API documentées (nt!PsSetCreateProcessNotifyRoutine, nt!PsSetCreateThreadNotifyRoutine, etc.). Ces API ajoutent des routines de callback fournies par le pilote à des tableaux non documentés de routines dans l'espace noyau :
PspCreateProcessNotifyRoutine pour la création de processusPspCreateThreadNotifyRoutine pour la création de threadsPspLoadImageNotifyRoutine pour le chargement d'imagesEDRSandBlast énumère les routines définies dans ces tableaux et supprime toute routine de callback liée à une liste prédéfinie de pilotes EDR (plus de 1000 pilotes de produits de sécurité pris en charge, voir la section sur la détection des pilotes EDR). L'énumération et la suppression sont possibles grâce à l'exploitation d'une primitive arbitraire de lecture/écriture en mémoire du noyau fournie par l'exploitation d'un pilote vulnérable (voir la section sur les pilotes vulnérables).
Les décalages des tableaux mentionnés ci-dessus sont récupérés à l'aide de plusieurs techniques, veuillez vous référer à la section sur les décalages.
Les produits EDR (et même EPP) enregistrent souvent des « callbacks d'objets » via l'API noyau nt!ObRegisterCallbacks. Ces callbacks permettent au produit de sécurité d'être notifié à chaque création de handle sur des types d'objets spécifiques (les callbacks d'objets liés aux processus, threads et bureaux sont désormais pris en charge par Windows). Une création de handle peut se produire lors de l'ouverture d'un objet (appel à OpenProcess, OpenThread, etc.) ainsi que lors de la duplication de handle (appel à DuplicateHandle, etc.).
En étant notifié par le noyau pour chacune de ces opérations, un produit de sécurité peut analyser la légitimité de la création du handle (par exemple, un processus inconnu tente d'ouvrir LSASS), et même la bloquer si une menace est détectée.
Lors de chaque enregistrement de callback utilisant ObRegisterCallbacks, un nouvel élément est ajouté à la liste doublement chaînée CallbackList présente dans l'objet _OBJECT_TYPE décrivant le type d'objet affecté par le callback (processus, thread ou bureau). Malheureusement, ces éléments sont décrits par une structure qui n'est ni documentée ni publiée dans les fichiers de symboles par Microsoft. Cependant, son étude à partir de différentes versions de ntoskrnl.exe semble indiquer que la structure n'a pas changé entre (au moins) les builds Windows 10 10240 et 22000 (de 2015 à 2022).
La structure mentionnée, représentant un enregistrement de callback d'objet, est la suivante :```C typedef struct OB_CALLBACK_ENTRY_t { LIST_ENTRY CallbackList; // linked element tied to _OBJECT_TYPE.CallbackList OB_OPERATION Operations; // bitfield : 1 for Creations, 2 for Duplications BOOL Enabled; // self-explanatory OB_CALLBACK* Entry; // points to the structure in which it is included POBJECT_TYPE ObjectType; // points to the object type affected by the callback POB_PRE_OPERATION_CALLBACK PreOperation; // callback function called before each handle operation POB_POST_OPERATION_CALLBACK PostOperation; // callback function called after each handle operation KSPIN_LOCK Lock; // lock object used for synchronization } OB_CALLBACK_ENTRY;
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;
Afin de désactiver les callbacks d'objets enregistrés par l'EDR, trois techniques sont implémentées dans
EDRSandblast ; cependant une seule est activée pour le moment.
Enabled de OB_CALLBACK_ENTRYC'est la technique activée par défaut dans EDRSandblast. Afin de détecter et désactiver
les callbacks d'objets liés à l'EDR, la liste CallbackList située dans les objets _OBJECT_TYPE
associés aux types Process et Thread est parcourue. Les deux _OBJECT_TYPEs sont
pointés par des symboles globaux publics dans le noyau, PsProcessType et PsThreadType.
Chaque élément de la liste est supposé correspondre à la structure OB_CALLBACK_ENTRY décrite ci-dessus
(hypothèse qui semble être vérifiée au moins dans toutes les builds de Windows 10 au moment de la rédaction).
Les fonctions définies dans les champs PreOperation et PostOperation sont localisées pour vérifier
si elles appartiennent à un pilote EDR, et si c'est le cas, les callbacks sont simplement désactivés en basculant le
drapeau Enabled.
Bien qu'il s'agisse d'une technique assez sûre, elle a l'inconvénient de reposer sur une structure non documentée ; pour réduire le risque de manipulation non sécurisée de cette structure, des vérifications de base sont effectuées pour valider que certains champs ont les valeurs attendues :
Enabled est soit TRUE soit FALSE (ne riez pas, un BOOL est un int, donc il pourrait valoir autre chose que 1 ou 0);Operations est OB_OPERATION_HANDLE_CREATE, OB_OPERATION_HANDLE_DUPLICATE ou les deux ;ObjectType pointe sur PsProcessType ou PsThreadType.CallbackList des threads et des processusUne autre stratégie qui ne repose pas sur une structure non documentée (et est donc théoriquement
plus robuste face aux changements du noyau NT) consiste à dissocier la totalité de la CallbackList
pour les processus et les threads. L'objet _OBJECT_TYPE est le suivant :```C
struct _OBJECT_TYPE {
LIST_ENTRY TypeList;
UNICODE_STRING Name;
[...]
_OBJECT_TYPE_INITIALIZER TypeInfo;
[...]
LIST_ENTRY CallbackList;
}
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.