Windows Kernel : Exploitation de Drivers Vulnerables

L'exploitation des drivers vulnérables Windows kernel représente l'une des menaces les plus sérieuses pour les organisations en 2026. Contrairement aux vulnérabilités applicatives classiques, une exploitation kernel réussie donne à l'attaquant un accès Ring 0 — le niveau de privilèges maximal sur le système, au-dessus même des administrateurs locaux et des antivirus. Les groupes APT comme Lazarus (Corée du Nord), BlackByte ransomware et Scattered Spider ont industrialisé la technique BYOVD (Bring Your Own Vulnerable Driver) pour contourner les protections EDR modernes. La base de données LOLDrivers.io recense actuellement plus de 1 000 drivers signés par des éditeurs légitimes mais contenant des primitives d'exploitation connues. Ce guide s'adresse aux équipes de sécurité défensive et aux Red Teams qui souhaitent comprendre les mécanismes d'exploitation pour mieux les détecter et les contrer. Les techniques présentées sont documentées à des fins de compréhension défensive, avec une couverture Blue Team équivalente aux sections offensives. L'exploitation sans autorisation constitue une infraction pénale grave au sens des articles 323-1 et suivants du Code pénal français.

Architecture Kernel Windows : Ring 0, Ring 3 et IOCTL

L'architecture processeur x86-64 définit quatre niveaux de privilèges appelés rings. En pratique, Windows utilise uniquement Ring 0 (kernel mode) et Ring 3 (user mode). Le Ring 0 est le niveau de confiance maximal : le kernel Windows, les drivers et les composants hyperviseur s'exécutent à ce niveau avec un accès direct à la mémoire physique, aux registres processeur et au matériel. Le Ring 3 est le niveau des applications utilisateur — accès restreint, chaque violation de mémoire génère une exception traitée par le kernel.

La Driver Signing Enforcement (DSE) est le mécanisme qui oblige les drivers kernel à être signés par Microsoft ou par un éditeur dont le certificat est chaîné à la Microsoft WHQL Root. Depuis Windows 10 1607 (Secure Boot activé), il est impossible de charger un driver non signé en production — c'est précisément pourquoi BYOVD est si efficace : l'attaquant utilise un driver légitimement signé mais vulnérable.

PatchGuard (Kernel Patch Protection, KPP) détecte et corrige les modifications non autorisées de structures kernel critiques (SSDT, IDT, GDT). Toute modification directe du SSDT (System Service Descriptor Table) par un rootkit déclenche un BSoD avec code 0x109 (CRITICAL_STRUCTURE_CORRUPTION). Les techniques modernes contournent PatchGuard non pas en patchant le SSDT mais en utilisant des hooks à d'autres niveaux (callback registration, minifilter drivers).

Le mécanisme IOCTL (I/O Control Code) est l'interface entre le user mode et les drivers kernel. Une application Ring 3 envoie un code IOCTL via DeviceIoControl() à un driver via son handle de device. Le driver reçoit l'IOCTL dans sa routine IRP_MJ_DEVICE_CONTROL et traite la requête. Si le driver ne valide pas correctement les paramètres d'entrée (taille du buffer, adresses pointées, valeurs), une vulnérabilité IOCTL peut permettre à un attaquant Ring 3 d'écrire arbitrairement en mémoire kernel.

BYOVD : anatomie d'une attaque avec driver signé vulnérable

La technique BYOVD (Bring Your Own Vulnerable Driver) suit un pattern bien établi. L'attaquant identifie un driver signé par un éditeur légitime (fabricant de matériel, éditeur de logiciels de sécurité) mais contenant une primitive d'exploitation — typiquement une primitive d'écriture arbitraire en kernel space. Le driver est embarqué dans le malware et chargé via CreateService() et StartService(). Une fois en Ring 0, le driver est utilisé pour désactiver les protections EDR, modifier des tokens de processus (élévation de privilèges) ou patcher directement les structures de protection kernel.

Le groupe Lazarus (APT38) a utilisé BYOVD dans l'opération Dreamjob (2022-2024) avec le driver Dell DBUtil_2_3.sys (CVE-2021-21551) — un driver de mise à jour Dell présent sur des millions de machines d'entreprise. Ce driver expose des IOCTLs non authentifiés permettant des lectures/écritures arbitraires en mémoire kernel. Lazarus l'utilisait pour désactiver les callbacks de notification des EDR enregistrés via PsSetCreateProcessNotifyRoutine.

BlackByte ransomware a adopté BYOVD en 2022 avec le driver RTCore64.sys de MSI Afterburner (CVE-2019-16098) — un driver overclock GPU signé par Micro-Star International. L'IOCTL vulnérable permet de lire et écrire n'importe quelle adresse mémoire physique depuis Ring 3. BlackByte l'utilisait pour localiser et terminer les processus EDR en modifiant directement leurs structures EPROCESS en mémoire kernel, sans passer par les APIs Windows surveillées.

La base de données LOLDrivers.io recense ces drivers vulnérables avec leur hash SHA256, leurs CVEs associées et leurs primitives d'exploitation. C'est la référence communautaire pour construire des blocklists défensives.

LOLDrivers.io : identifier et bloquer les drivers à risque sur votre parc

LOLDrivers.io est une initiative communautaire (créée par Andreas Happe et maintenue par la communauté de sécurité) qui documente les Living Off The Land Drivers — des drivers légitimement signés exploitables par des attaquants. La base de données est structurée par primitive d'exploitation : write-what-where, read-what-where, arbitrary memory map, kernel execute, etc.

Pour identifier les drivers LOLDrivers présents sur votre parc Windows, voici un script PowerShell qui croise les drivers chargés avec les hashes connus :

# PowerShell : identifier les drivers vulnérables chargés (cross-check LOLDrivers)
# Télécharger la liste des hashes LOLDrivers
$lolDriversUrl = "https://www.loldrivers.io/api/drivers.json"
$lolDrivers = Invoke-RestMethod -Uri $lolDriversUrl

# Extraire tous les hashes SHA256 vulnérables
$vulnerableHashes = $lolDrivers |
    Where-Object { $_.Category -eq "vulnerable" } |
    ForEach-Object { $_.KnownVulnerableSamples } |
    ForEach-Object { $_.SHA256 } |
    Where-Object { $_ -ne $null } |
    ForEach-Object { $_.ToUpper() }

# Lister tous les drivers chargés sur le système
$loadedDrivers = Get-SystemDriver | Where-Object { $_.State -eq "Running" }

# Cross-check
foreach ($driver in $loadedDrivers) {
    if ($driver.PathName -match "\.sys$") {
        try {
            $hash = (Get-FileHash -Path $driver.PathName -Algorithm SHA256).Hash
            if ($vulnerableHashes -contains $hash) {
                Write-Warning "DRIVER VULNERABLE DETECTE: $($driver.Name) | $($driver.PathName) | SHA256: $hash"
            }
        } catch {
            Write-Verbose "Impossible de lire: $($driver.PathName)"
        }
    }
}

# Variante offline : vérifier TOUS les fichiers .sys du système
Get-ChildItem -Path "C:\Windows\System32\drivers" -Filter "*.sys" -ErrorAction SilentlyContinue |
    ForEach-Object {
        $hash = (Get-FileHash $_.FullName -Algorithm SHA256).Hash
        if ($vulnerableHashes -contains $hash) {
            Write-Warning "VULNERABLE: $($_.Name) | $hash"
        }
    }

Ce script doit être exécuté régulièrement — idéalement via une tâche planifiée ou un outil EDM (Endpoint Detection Management). Les rapports Microsoft Security Blog publient régulièrement des mises à jour sur les nouveaux drivers BYOVD observés en campagnes actives.

IOCTL Exploitation : write-what-where primitive en détail

La primitive write-what-where est la plus courante dans les exploits de drivers kernel. Elle permet d'écrire une valeur arbitraire (WHAT) à une adresse mémoire arbitraire (WHERE) — y compris en kernel space. Un driver vulnérable qui accepte sans validation une adresse kernel fournie depuis Ring 3 est exploitable.

Voici un exemple simplifié d'IOCTL handler vulnérable en pseudo-code C :

/* Exemple : IOCTL handler vulnérable (write-what-where)
   Ce code illustre le pattern de vulnérabilité - NE PAS utiliser */

typedef struct _WRITE_REQUEST {
    ULONG64 TargetAddress;  // Adresse kernel cible (non validée !)
    ULONG64 Value;          // Valeur à écrire (non validée !)
} WRITE_REQUEST;

NTSTATUS VulnerableDriverIoControl(
    PDEVICE_OBJECT DeviceObject,
    PIRP Irp)
{
    PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp);
    ULONG ioctl = stack->Parameters.DeviceIoControl.IoControlCode;

    if (ioctl == IOCTL_VULN_WRITE_KERNEL_MEM) {
        PWRITE_REQUEST req = (PWRITE_REQUEST)Irp->AssociatedIrp.SystemBuffer;

        // VULNERABILITE : aucune validation de TargetAddress !
        // Un attaquant Ring 3 peut écrire n'importe où en kernel space
        *(PULONG64)(req->TargetAddress) = req->Value;
        // Exemple d'exploitation : écrire 0 sur le champ Token.Privileges
        // de EPROCESS pour désactiver un EDR, ou modifier
        // un callback kernel enregistré par un AV
    }
    return STATUS_SUCCESS;
}

Un driver correctement écrit devrait valider que TargetAddress pointe vers une zone mémoire autorisée (mémoire utilisateur allouée par l'appelant) via ProbeForWrite() et encapsuler l'accès dans un bloc __try/__except. L'absence de ces deux protections est la signature d'un driver vulnérable.

En pratique, l'exploitation utilise cette primitive pour écrire dans la table des tokens de processus ou pour modifier les callbacks EDR. Pour aller plus loin sur le forensics des artefacts laissés par ces exploits, voir notre article sur le forensics Windows expert.

Kernel Pool Overflow : exploitation post-VBS sur Windows 11

Les Kernel Pool Overflows exploitent des débordements dans les allocations mémoire kernel (NonPagedPool, PagedPool) pour corrompre des structures adjacentes et obtenir une exécution de code Ring 0. Historiquement, l'exploitation des heap overflows kernel était facilitée par la prévisibilité du Pool Allocator de Windows NT. Windows 10 21H2 et Windows 11 ont introduit le Segment Heap dans le kernel, rendant l'exploitation significativement plus complexe.

CVE-2021-34527 (PrintNightmare) — bien que principalement connue comme vulnérabilité RCE du Print Spooler — illustre comment un bug dans le chargement de drivers d'imprimante (Ring 0) permet une élévation de privilèges vers SYSTEM. Le driver d'imprimante malveillant est chargé par le spouleur avec des privilèges SYSTEM, contournant ainsi DSE via le mécanisme légitime de chargement de drivers d'imprimante. Le patch (MS-KB5005010) a requis non seulement un correctif logiciel mais aussi une reconfiguration du Point and Print.

En 2024-2025, plusieurs CVEs kernel Windows critiques ont été exploitées in the wild. CVE-2024-21338 (Windows Kernel Elevation of Privilege, CVSS 7.8) dans le driver appid.sys permettait une élévation vers SYSTEM via un UAF (Use-After-Free). CVE-2024-30088 (CVSS 7.0) ciblait le kernel Windows via une race condition dans le gestionnaire de temps. CVE-2025-21333 (Windows Hyper-V NT Kernel Integration VSP Elevation) a été exploitée en 0-day début 2025 avant le patch janvier 2025 Patch Tuesday. La référence NIST NVD maintient l'historique complet de ces vulnérabilités.

L'introduction de VBS (Virtualization-Based Security) sur Windows 11 complique davantage l'exploitation : les structures kernel critiques sont protégées dans une partition hyperviseur séparée (VSM - Virtual Secure Mode), inaccessible même depuis Ring 0. Un exploit kernel sur VBS/HVCI activé doit d'abord contourner l'hyperviseur — une barrière significativement plus haute. Voir notre article sur Windows Server 2025 forensics pour les implications en investigation numérique.

ETW Bypass via Driver : aveugler les EDR au niveau kernel

ETW (Event Tracing for Windows) est le mécanisme central de télémétrie de Windows — utilisé par tous les EDR pour recevoir des événements kernel (création de processus, injection mémoire, chargement de DLL, activité réseau). Un driver Ring 0 peut désactiver sélectivement les providers ETW en modifiant les structures kernel associées, rendant les EDR «aveugles» aux actions subséquentes.

La technique consiste à localiser la structure _ETW_GUID_ENTRY associée au provider ETW ciblé (par exemple, Microsoft-Windows-Threat-Intelligence qui surveille l'injection mémoire) et à modifier son champ de flags pour désactiver les notifications. Une variante plus subtile cible les PPL (Protected Process Light) — un mécanisme qui protège les processus EDR contre la terminaison ou l'injection depuis des processus non-PPL. Un driver Ring 0 peut modifier le champ Protection de l'EPROCESS pour retirer la protection PPL d'un processus EDR, puis le terminer via les APIs Windows normales.

Ces techniques sont également utilisées en Red Team pour masquer les actions des implants C2 — une connexion entre l'exploitation kernel et les C2 frameworks comme Mythic, Havoc et Sliver. Les implants Havoc, par exemple, peuvent charger un driver BYOVD pour réaliser l'ETW bypass avant d'activer leur canal C2.

Défenses : HVCI, Memory Integrity et WDAC

HVCI (Hypervisor-Protected Code Integrity, aussi appelé Memory Integrity dans l'interface Windows) est la défense la plus efficace contre les attaques driver. HVCI utilise l'hyperviseur (Hyper-V) pour vérifier que tout code exécuté en Ring 0 est signé et non modifié — même un attaquant avec accès kernel complet ne peut pas injecter de code non signé sans être bloqué par l'hyperviseur. Sur Windows 11 avec Secure Boot et TPM 2.0, HVCI est activé par défaut depuis 2022.

Microsoft WDAC (Windows Defender Application Control, anciennement Device Guard) permet de définir des policies qui contrôlent quels drivers (et applications) peuvent s'exécuter. Microsoft publie une Recommended Driver Block Rules qui inclut tous les drivers LOLDrivers connus — c'est la protection proactive la plus simple à déployer :

# PowerShell : déployer la Driver Block List Microsoft recommandée
# Télécharger la policy XML Microsoft
$blockListUrl = "https://aka.ms/VulnerableDriverBlockList"
Invoke-WebRequest -Uri $blockListUrl -OutFile "C:\Windows\System32\CodeIntegrity\SIPolicy.p7b"

# Vérifier l'état de la policy
ConvertFrom-CIPolicy -XmlFilePath .\DriverBlockList.xml -BinaryFilePath .\SIPolicy.p7b

# Activer via GPO : Computer Configuration > Administrative Templates >
# System > Device Guard > Deploy Windows Defender Application Control

# Vérifier l'état HVCI/Memory Integrity
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
    Select-Object SecurityServicesRunning, VirtualizationBasedSecurityStatus

# Activer Memory Integrity via registre (nécessite redémarrage)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" `
    -Name "Enabled" -Value 1 -Type DWord

Déploiement WDAC : policies et block list de drivers vulnérables

Une policy WDAC complète combine une allowlist (drivers autorisés) avec une blocklist (drivers LOLDrivers). Voici un exemple de structure XML WDAC :

  10.0.0.0
  {GUID-UNIQUE-PAR-ORGANISATION}
  {GUID-UNIQUE-PAR-ORGANISATION}
  {2E07F7E4-194C-4D20-B696-C30036012AF3}
  
    
    Enabled:Audit Mode
    Enabled:Boot Menu Protection
    Required:WHQL
    Enabled:UMCI
    Disabled:Script Enforcement
  
  
    
    
    
  
  
  
    
      
        
          
          
        
      
    
  

Détection Blue Team : Sysmon, ETW et Sigma Rules

La détection des chargements de drivers suspects repose principalement sur Sysmon Event ID 6 (Driver loaded). Chaque chargement de driver génère un événement avec le nom du fichier, son hash SHA256, sa signature et son éditeur. Un driver non signé ou dont le hash correspond à la liste LOLDrivers est un indicateur de compromission haute confiance.

# PowerShell : surveiller les chargements de drivers en temps réel via Sysmon
# Prérequis : Sysmon installé avec configuration incluant EventID 6
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Sysmon/Operational'
    Id = 6  # Driver loaded
} -MaxEvents 100 | ForEach-Object {
    $xml = [xml]$_.ToXml()
    $data = $xml.Event.EventData.Data
    [PSCustomObject]@{
        TimeCreated = $_.TimeCreated
        ImageLoaded = ($data | Where-Object Name -eq "ImageLoaded")."#text"
        Hashes = ($data | Where-Object Name -eq "Hashes")."#text"
        Signed = ($data | Where-Object Name -eq "Signed")."#text"
        Signature = ($data | Where-Object Name -eq "Signature")."#text"
        SignatureStatus = ($data | Where-Object Name -eq "SignatureStatus")."#text"
    }
} | Where-Object { $_.Signed -eq "false" -or $_.SignatureStatus -ne "Valid" }

# KQL - Microsoft Sentinel : détecter BYOVD via Sysmon Event ID 6
Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 6
| extend EventData = parse_xml(EventData)
| extend
    ImageLoaded = tostring(EventData.DataItem.EventData.Data[5]["#text"]),
    Signed = tostring(EventData.DataItem.EventData.Data[7]["#text"]),
    SignatureStatus = tostring(EventData.DataItem.EventData.Data[9]["#text"])
| where Signed == "false" or SignatureStatus != "Valid"
| project TimeGenerated, Computer, ImageLoaded, Signed, SignatureStatus

La règle Sigma suivante détecte les drivers LOLDrivers connus par leurs hashes — à adapter avec les hashes actuels de LOLDrivers.io :

# Sigma Rule : BYOVD - Known Vulnerable Driver Loading
title: BYOVD - Loading of Known Vulnerable Kernel Driver
status: stable
description: Détecte le chargement d'un driver kernel connu comme vulnérable (LOLDrivers)
references:
  - https://www.loldrivers.io/
logsource:
  product: windows
  service: sysmon
  definition: 'Requires Sysmon Event ID 6 logging'
detection:
  selection:
    EventID: 6
    Hashes|contains:
      # RTCore64.sys (MSI Afterburner, CVE-2019-16098)
      - 'SHA256=01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87521A'
      # Dell DBUtil_2_3.sys (CVE-2021-21551)
      - 'SHA256=0296E2CE999E67C76352D577B53B41C7A372E7B9B7D6E7ACFC8B4C1A79F0B38C'
      # WinRing0x64.sys (ASUS, CVE-2020-14979)
      - 'SHA256=C7E75506C44E7E9B7E8B0E3EE6B8C5E3F86B06B7A1E3E3E9A4D6B8F44E7E9B7'
  condition: selection
falsepositives:
  - Legitimate use of MSI Afterburner or similar tools (verify context)
level: high
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1068
  - attack.t1543.003

Pour les enquêtes post-incident sur des systèmes potentiellement compromis via BYOVD, notre guide de forensics Windows expert détaille les artefacts à rechercher : clés de registre des services (HKLM\SYSTEM\CurrentControlSet\Services), journaux PnP, artifacts $MFT et fichiers .sys supprimés récupérables depuis $RECYCLE.BIN ou les Volume Shadow Copies.

CVEs réels : chronologie des exploitations in the wild (2021-2025)

L'exploitation des drivers vulnérables n'est pas théorique — voici une chronologie d'incidents documentés. CVE-2021-21551 (Dell DBUtil_2_3.sys, CVSS 8.8) : découvert par SentinelOne en 2021, ce driver Dell présent sur des centaines de millions de machines exposait 5 vulnérabilités distinctes dans ses IOCTLs, dont une write-what-where arbitraire. Lazarus et d'autres APT l'ont utilisé comme vecteur BYOVD pendant plus d'un an avant le patch.

CVE-2019-16098 (RTCore64.sys, MSI Afterburner) : repéré dès 2019, encore utilisé activement par BlackByte ransomware en 2022 pour désactiver les EDR SentinelOne, Carbon Black et Cylance avant le chiffrement. La longévité de ce driver dans les campagnes actives (5+ ans) illustre la lenteur de déploiement des blocklists.

CVE-2023-28252 (Windows Common Log File System Driver, CVSS 7.8) : exploitée en 0-day par le groupe Nokoyawa ransomware en avril 2023. Cette vulnérabilité dans clfs.sys (Common Log File System) permettait une élévation vers SYSTEM via un heap overflow en kernel mode — patchée dans le Patch Tuesday d'avril 2023. Pour comprendre comment intégrer ces CVEs dans une démarche de gestion des vulnérabilités plus large, voir notre article sur le pentest automatisé par IA générative.

Questions fréquentes

HVCI désactivé sur mon parc Windows 10 — quel est le risque réel ?

Sans HVCI, un attaquant ayant exécuté du code avec des droits administrateur locaux peut charger n'importe quel driver signé — y compris un driver BYOVD de LOLDrivers — et obtenir l'exécution Ring 0. Cela permet de désactiver les EDR, d'obtenir des credentials LSASS sans alerter Credential Guard et de modifier des tokens de processus. Le risque est concret : c'est précisément le chemin d'attaque de BlackByte et Lazarus en 2022-2024. HVCI doit être la priorité d'activation avant toute autre mesure de hardening avancée.

Comment distinguer un chargement BYOVD d'un chargement légitime de driver ?

Le contexte est déterminant. Un driver MSI Afterburner chargé sur une machine gaming personnelle est probablement légitime. Le même driver chargé depuis un répertoire %TEMP% ou C:\ProgramData\ inhabituels, par un processus non-interactif (service, tâche planifiée), sur une machine sans GPU MSI — c'est un indicateur de BYOVD. La corrélation avec Sysmon Event ID 11 (fichier créé) quelques secondes avant l'Event ID 6 (driver chargé) renforce la détection.

Les EDR commerciaux suffisent-ils à bloquer les attaques BYOVD ?

Non — c'est précisément le problème. Le BYOVD est conçu pour désactiver les EDR. Un driver Ring 0 peut modifier les structures de callback kernel et aveugler l'EDR avant même qu'il détecte le chargement. HVCI et WDAC sont les seules défenses architecturalement solides car elles opèrent à un niveau de confiance supérieur (hyperviseur) inaccessible aux drivers Ring 0. Les EDR peuvent détecter les premières étapes (création du fichier driver, appel à CreateService), mais pas l'exploitation une fois le driver en Ring 0.

Quel est le lien entre BYOVD et l'escalade de privilèges AWS ?

Le vecteur est différent mais la logique est similaire : dans les deux cas, l'attaquant exploite une confiance excessive accordée à une entité légitime (driver signé / rôle IAM) pour obtenir des permissions qui dépassent son niveau d'accès légitime. Notre article sur les escalades de privilèges AWS couvre les techniques analogues en environnement cloud — les Red Teams modernes testent les deux surfaces dans un engagement hybride on-prem/cloud.

WDAC est-il compatible avec les outils de sécurité tiers (EDR, DLP) ?

Oui, avec une configuration appropriée. Les éditeurs de sécurité fournissent des certificats de signature reconnus par WDAC. La difficulté est opérationnelle : déployer WDAC en mode Enforced sur un parc hétérogène sans casser des applications légitimes nécessite une phase d'audit en mode Audit de plusieurs semaines. Microsoft recommande de démarrer avec la politique AllowMicrosoft (seuls les binaires Microsoft signés autorisés) et d'ajouter progressivement des exceptions pour les éditeurs tiers de confiance.

Conclusion

L'exploitation des drivers vulnérables Windows kernel est passée du statut de technique de niche APT à celui d'outil standard dans l'arsenal des groupes ransomware en 2022-2025. BYOVD a rendu obsolètes des années d'investissement EDR chez les organisations qui n'ont pas activé HVCI et déployé les blocklists WDAC. La réponse défensive est claire : HVCI en priorité absolue sur tout parc Windows 10/11 éligible, suivi du déploiement de la Microsoft Recommended Driver Block Rules via WDAC, et surveillance Sysmon Event ID 6 avec correlation LOLDrivers dans le SIEM. Ces trois mesures, combinées, réduisent drastiquement la surface d'attaque BYOVD sans nécessiter de budget EDR supplémentaire.