Élimination d'EDR

Exploitation de Pilotes Vulnérables pour l’Évasion EDR : une Plongée Technique dans les Attaques BYOVD

Danger (Avertissement)

Cet article est destiné à des fins éducatives et informatives uniquement, spécifiquement pour sensibiliser aux techniques utilisées dans les attaques Bring Your Own Vulnerable Driver (BYOVD) et comment elles peuvent être atténuées.

Les informations fournies ne doivent pas être utilisées pour s’engager dans des activités non autorisées, exploiter des vulnérabilités ou compromettre des systèmes. L’utilisation non autorisée de ces connaissances peut violer les lois et réglementations locales, nationales ou internationales. Je décline toute responsabilité pour toute mauvaise utilisation des informations présentées.

Les lecteurs sont fortement encouragés à utiliser ces connaissances de manière responsable et éthique, en adhérant aux lois applicables.

Le paysage de la cybersécurité continue de faire face à la sophistication croissante des attaques Bring Your Own Vulnerable Driver (BYOVD), une technique qui transforme des pilotes kernel légitimes mais défectueux en armes pour désactiver les solutions Endpoint Detection and Response (EDR). Cet article examine les mécaniques techniques de ces attaques, en se concentrant sur le processus de reverse engineering des pilotes pour identifier et exploiter les interfaces Input/Output Control (IOCTL) afin d’exécuter des opérations privilégiées telles que la terminaison de processus.

Fondamentaux de l’Exploitation au Niveau Noyau

Les attaques BYOVD exploitent la confiance inhérente placée dans les pilotes signés par les systèmes d’exploitation. Les attaquants tirent parti de pilotes avec une validation d’entrée inadéquate dans leurs gestionnaires IOCTL pour obtenir l’exécution de code en mode noyau. L’objectif final est souvent de terminer les processus EDR en utilisant des fonctions API natives comme ZwTerminateProcess, qui opère au niveau du noyau et contourne les hooks de sécurité en mode utilisateur.

La chaîne d’attaque commence par l’obtention de privilèges administratifs, typiquement via le vol d’identifiants ou des vulnérabilités d’escalade de privilèges. Une fois l’accès élevé sécurisé, l’attaquant déploie un pilote vulnérable, souvent obsolète mais toujours signé, sur le système cible. Les pilotes légitimes de fournisseurs de sécurité (par ex., outils anti-malware) sont des cibles fréquentes en raison de leurs permissions inhérentes d’interagir avec les processus système.

Trouver un pilote vulnérable

LOLDrivers

www.loldrivers.io

https://www.loldrivers.io/

Living Off The Land Drivers est une liste organisée de pilotes Windows utilisés par les adversaires pour contourner les contrôles de sécurité et mener des attaques, référencés avec des attributs d’importations, certificats et ainsi de suite. Nous pouvons donc simplement regarder les pilotes récemment signés par date de certificat et rechercher la fonction importée ZwTerminateProcess dans un pilote de la liste.

Et vous pouvez simplement télécharger le pilote depuis un lien de dépôt github :

Reverse Engineering de Pilotes pour l’Exploitation IOCTL

Nous devons d’abord identifier les codes IOCTL et les fonctions gestionnaires correspondantes qui permettent des opérations noyau non autorisées. Voici une approche structurée pour le reverse engineering d’un pilote à cette fin :

Acquisition du Pilote et Analyse Statique - Fait ✅ Les attaquants obtiennent d’abord le pilote cible (par ex., aswArPot.sys d’Avast ou RTCore64.sys de MSI Afterburner). Des outils comme IDA Pro ou Ghidra désassemblent le binaire du pilote pour révéler sa logique interne avec le flux de code et le pseudo code. L’accent principal est mis sur la routine de dispatch du pilote, qui gère les requêtes IRP_MJ_DEVICE_CONTROL—le mécanisme pour traiter les IOCTL.
Identification de la Fonction de Dispatch - Temps pour du reverse rapide 🤓 Dans les pilotes Windows, la routine DriverEntry initialise une structure DRIVER_OBJECT contenant des pointeurs de fonction pour gérer les opérations majeures. Le tableau MajorFunction à l’index IRP_MJ_DEVICE_CONTROL (typiquement 0x0E) pointe vers le gestionnaire IOCTL. Localiser cette fonction permet aux attaquants d’analyser comment les codes IOCTL sont traités.

Note (IDA Pro)

Pour analyser les pilotes kernel et les composants système de bas niveau, IDA Pro fournit des capacités critiques que la version gratuite d’IDA n’a pas, particulièrement lors du traitement du code Windows Driver Model (WDM), des gestionnaires IOCTL et des vecteurs d’exploitation en mode noyau. La version Pro inclut :

Routines DriverEntry : Visualiser la logique d’initialisation des pilotes.
Gestionnaires IRP : Décompiler les fonctions de dispatch IRP_MJ_DEVICE_CONTROL.
Analyse IOCTL : Mapper automatiquement les codes de contrôle vers la logique des gestionnaires.

Récupération des Codes IOCTL Les codes IOCTL sont des valeurs 32 bits structurées comme CTL_CODE(DeviceType, Function, Method, Access). En examinant les références croisées au gestionnaire IOCTL, les analystes identifient les codes qui déclenchent des actions privilégiées. Par exemple, un pilote pourrait utiliser un code personnalisé comme 0x9988C094 pour invoquer ZwTerminateProcess.
Analyse de la Logique du Gestionnaire La fonction gestionnaire valide typiquement les paramètres, tels que les tailles de buffer d’entrée/sortie et les handles de processus, avant d’effectuer des opérations. Les vulnérabilités surviennent lorsque ces vérifications sont insuffisantes. Par exemple, un pilote pourrait accepter un handle de processus depuis le mode utilisateur sans vérifier les privilèges de l’appelant, permettant la terminaison arbitraire de processus.
Création de l’Exploit Avec le code IOCTL et les paramètres requis identifiés, les attaquants écrivent un programme en mode utilisateur pour ouvrir un handle vers l’objet périphérique du pilote et envoyer une requête IOCTL élaborée. Cette requête inclut l’ID du processus cible et déclenche le gestionnaire du pilote pour appeler ZwTerminateProcess avec des privilèges noyau.

Exemple pratique

Depuis IDA Pro, nous avons chargé le pilote RTCore64.sys et navigué vers la fonction DriverEntry, qui révèle le nom du périphérique que le pilote va créer.

L’onglet Imports montre diverses fonctions en mode noyau disponibles pour le pilote :

Puisque notre objectif est de trouver un moyen de terminer les processus EDR, nous recherchons spécifiquement la fonction ZwTerminateProcess. Chargeons une autre vue pour rechercher cette API :

Pour découvrir où cette fonction est appelée dans le pilote, appuyez sur x pour afficher les références croisées :

Cela nous amène à la vue graphique de la fonction contenant l’appel ZwTerminateProcess. Appuyez sur F5 pour décompiler ce bloc :

Après avoir renommé les variables pour plus de clarté, nous pouvons voir que la fonction accepte un paramètre handle de processus et le passe directement à ZwTerminateProcess :

Maintenant nous devons tracer en arrière pour trouver ce qui appelle cette fonction. En haut de la fenêtre du décompilateur, localisez le nom de la fonction et utilisez à nouveau les références croisées pour trouver ses appelants :

Cela nous a menés à une fonction de dispatch contenant une instruction switch qui gère différents codes IOCTL. Nous pouvons maintenant identifier quel code IOCTL déclenche notre fonction de terminaison de processus :

À partir de cette analyse, nous avons identifié avec succès le code IOCTL qui, lorsqu’envoyé au périphérique RTCore64, invoquera ZwTerminateProcess sur une liste de processus. 🤪

Maintenant kayakobémons ce processus EDR/AV :

Stratégies Défensives et Atténuations

Contrer les attaques BYOVD exige une approche multifacette :

Hypervisor-Protected Code Integrity (HVCI) : Activer HVCI restreint l’exécution de code en mode noyau aux pilotes validés par les politiques d’intégrité du code de Microsoft, bloquant efficacement les pilotes non autorisés.
Surveillance et Filtrage IOCTL : Les outils de sécurité peuvent intercepter et inspecter les requêtes IOCTL, signalant les anomalies telles que les tentatives de terminaison de processus depuis des processus non-système.
Allowlisting de Pilotes : Les organisations doivent maintenir un inventaire strict des pilotes autorisés et bloquer tous les autres via Group Policy ou les plateformes de protection des points de terminaison.
Épinglage de Certificat : Implémenter des listes de confiance de certificats personnalisées empêche le chargement de pilotes signés avec des certificats révoqués ou non autorisés.
Détection de Menaces en Mode Noyau : Les solutions EDR avancées surveillent maintenant les comportements suspects des pilotes, tels que les appels directs à ZwTerminateProcess ou les modifications de processus protégés.

Conclusion

Les attaques BYOVD représentent un changement de paradigme en cybersécurité offensive, exploitant la ligne floue entre les opérations légitimes et malveillantes en mode noyau. Les défenseurs doivent adopter des mesures proactives, incluant une vérification rigoureuse des pilotes, une surveillance du noyau et des politiques de sécurité appliquées par le matériel. Alors que les attaquants continuent d’innover, la capacité de la communauté cybersécurité à anticiper et neutraliser ces menaces déterminera la résilience des environnements d’entreprise modernes.