SOMMAIRE
0 rings de privilèges windows
1 driver signature enforcement (dse)
2 le concept byovd
3 flux d'attaque
4 capacités post-exploitation
5 détection & mitigations
──[ 0. Rings de Privilèges Windows ]──
Windows découpe l'exécution en niveaux de privilèges appelés rings. Chaque ring
est isolé et ne peut atteindre les rings inférieurs qu'à travers des canaux bien
définis (APIs, syscalls, drivers, callbacks).
User Land (Ring 3) — où vivent les applis normales. Mémoire isolée
par processus. Le kernel peut tuer ce qu'il veut.
Kernel Land (Ring 0) — cœur de Windows, drivers, composants kernel
des EDR. Accès total : toute la mémoire, tout
le matériel.
Passer de Ring 3 à Ring 0 légitimement, ça veut dire charger un driver kernel
signé.
──[ 1. Driver Signature Enforcement (DSE) ]──
Windows applique DSE : seuls les drivers signés par Microsoft (ou par un vendor
avec un cert cross-signé) sont chargeables dans le kernel.
Le processus de signature Microsoft, c'est environ deux ans de galère.
Écrire son propre driver malveillant devient impraticable pour la plupart des
attaquants. Un zero-day kernel marche aussi mais ça coûte cher et c'est patché
vite.
──[ 2. Le Concept BYOVD ]──
BYOVD contourne DSE complètement. Plutôt que d'écrire un nouveau driver, tu
embarques un driver légitime, signé, d'un vendor connu — avec une vuln connue.
Légitime ✓ Microsoft l'a signé. DSE laisse passer.
Vulnérable ✓ Une CVE ou une faille logique permet à Ring 3 de
lire/écrire dans la mémoire kernel via le driver.
Cibles classiques : fabricants hardware (Intel, ASUS, Dell, Gigabyte…) dont les
vieux drivers exposent des IOCTLs read/write mémoire brute sans aucune
validation.
──[ 3. Flux d'Attaque ]──
Prérequis : admin local ou SYSTEM déjà acquis (sinon impossible de charger un
driver kernel).
Chargement via le Service Control Manager :
sc create PwnDrv binPath="C:\temp\vulnerable.sys" type=kernel
sc start PwnDrv
Ou en code avec NtLoadDriver(). Une fois chargé, le processus userland
malveillant parle au driver via des DeviceIoControl(), abuse de la vuln, et
récupère des primitives read/write kernel.
──[ 4. Capacités Post-Exploitation ]──
Avec du R/W kernel arbitraire, tu peux :
Direct Kernel Object Manipulation (DKOM)
Modifier des EPROCESS pour cacher des processus de la tasklist, les
délier de la liste kernel, ou upgrader leurs privilèges de token.
EDR Blinding
Trouver les tables de callbacks kernel (PsSetCreateProcessNotifyRoutine,
PsSetLoadImageNotifyRoutine, etc.) et écraser les pointeurs callback
de l'EDR avec des zéros. Plus aucune notif n'arrive à l'EDR.
Manipulation de tokens
Voler ou dupliquer des tokens SYSTEM pour escalader en userland.
──[ 5. Détection & Mitigations ]──
Réponse de Microsoft :
HVCI (Hypervisor-Protected Code Integrity) — vérification hardware
qui bloque le chargement de tout driver pas signé avec un cert EV
récent. La plupart des drivers BYOVD sont antérieurs aux exigences HVCI.
Microsoft Vulnerable Driver Blocklist — liste des drivers connus
comme vulnérables, distribuée via Windows Update et Defender. Elle
grossit.
LOLDrivers (loldrivers.io) — catalogue communautaire des drivers
connus comme exploités dans la nature.
Côté défense, alerter sur :
- Chargements de drivers absents de la blocklist approuvée
- Appels DeviceIoControl à des drivers sans client user-mode légitime
- Indices DKOM : processus dans tasklist sans entrée kernel correspondante
BYOVD mérite d'être compris en profondeur parce que c'est ce qui rend possible
la plupart des autres bypass EDR de cette série — patcher les kernel callbacks
demande du Ring 0, et BYOVD c'est généralement comme ça qu'on l'obtient.