Liste de blocage des pilotes vulnérables : stopper le BYOVD

Charger un pilote noyau exige des droits d'administrateur et une signature valide. Les attaquants qui ont déjà des droits d'administrateur veulent le noyau, car de là ils peuvent tuer les processus de l'EDR, retirer la protection LSA de LSASS ou désactiver la protection contre les falsifications. Ils ne peuvent pas signer un pilote malveillant : ils apportent donc un pilote légitimement signé présentant une vulnérabilité connue, le chargent et l'exploitent. C'est le bring your own vulnerable driver (BYOVD), et c'est ainsi que fonctionnent la plupart des outils « EDR killer » utilisés par les affiliés de ransomware.

La liste de blocage des pilotes vulnérables de Microsoft est une stratégie App Control qui refuse de charger les pilotes connus comme vulnérables ou malveillants. Microsoft la maintient avec les fabricants de matériel et la livre dans Windows. Ce guide va plus loin que la mention qui en est faite dans le guide pilier App Control : comment confirmer qu'elle est active, comment la maintenir à jour et comment gérer les lacunes.

Ce qu'est la liste de blocage, et ce qu'elle n'est pas

Ce n'est pas une liste d'autorisation complète des pilotes. Un pilote vulnérable que Microsoft n'a pas encore ajouté se chargera. C'est pourquoi la liste de blocage est un socle à combiner avec de la détection et, sur les systèmes à forte valeur, avec une stratégie App Control complète.

Étape 1 : vérifier l'état actuel

Sur une machine donnée, Sécurité Windows l'affiche sous Sécurité de l'appareil > Détails de l'isolation du noyau > Liste de blocage des pilotes vulnérables Microsoft. Lorsque l'intégrité de la mémoire, Smart App Control ou le mode S est actif, le bouton est activé et grisé, car ces fonctionnalités appliquent toujours la liste de blocage.

Le paramètre derrière ce bouton est une valeur de registre :

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" -Name VulnerableDriverBlocklistEnable

1 signifie activé. Vérifiez aussi si l'intégrité de la mémoire est en cours d'exécution, puisqu'elle garantit l'application :

(Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard `
  -ClassName Win32_DeviceGuard).SecurityServicesRunning   # 2 = intégrité de la mémoire (HVCI)

Sur un parc, collectez les deux valeurs avec votre outil de gestion, une extension de l'inventaire matériel de Configuration Manager ou un script de correction Intune en mode détection seule. Commencez par Windows Server : les serveurs mis à niveau sur place et les VM sans sécurité basée sur la virtualisation sont les lacunes habituelles.

Étape 2 : l'activer là où elle est désactivée

La correction la plus simple consiste à activer l'intégrité de la mémoire (HVCI), qui apporte la liste de blocage avec elle et bloque une classe plus large d'attaques contre le noyau. Là où HVCI n'est pas encore possible (pilotes incompatibles, matériel ancien), activez la liste de blocage seule :

Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config" `
  -Name VulnerableDriverBlocklistEnable -Value 1 -Type DWord

Déployez cette valeur avec un élément de registre des préférences de stratégie de groupe ou une correction Intune, puis redémarrez : la stratégie de pilotes est évaluée au démarrage. Sur les versions où ce commutateur n'existe pas, déployez plutôt la liste de blocage comme stratégie App Control (étape suivante).

Étape 3 : rester à jour entre les versions de Windows

La copie livrée avec Windows est en retard sur la liste publiée par Microsoft. Microsoft propose la dernière liste de blocage en téléchargement (lien depuis la page « Microsoft recommended driver block rules » de la documentation App Control), aux formats XML et binaire, en variantes audit et application.

Deux façons de l'utiliser :

1. Seule : la méthode documentée par Microsoft consiste à renommer le binaire d'audit ou d'application en SiPolicy.p7b, à le copier dans %windir%\System32\CodeIntegrity et à exécuter l'outil d'actualisation des stratégies App Control (ou à redémarrer). Testez d'abord la version d'audit sur un anneau pilote. Ce nom de fichier correspond à l'emplacement de stratégie unique : il remplace donc toute stratégie au format unique déjà présente sur l'appareil. Lorsque l'appareil prend en charge plusieurs stratégies, Microsoft recommande plutôt de déployer la liste de blocage à côté de vos stratégies existantes, par exemple en convertissant le XML publié (ici DriverBlockRules.xml) en .cip et en l'appliquant avec CiTool sur Windows 11 22H2 et versions ultérieures :

   PowerShell

   Copy-Item .\DriverBlockRules.xml .\DriverBlock.xml
   Set-CIPolicyIdInfo -FilePath .\DriverBlock.xml -ResetPolicyID   # format à stratégies multiples, nouvel ID
   ConvertFrom-CIPolicy -XmlFilePath .\DriverBlock.xml -BinaryFilePath .\DriverBlock.cip
   CiTool.exe --update-policy .\DriverBlock.cip
   CiTool.exe --list-policies

   Les pilotes déjà en cours d'exécution ne sont bloqués qu'après un redémarrage.

2. Fusionnée dans votre stratégie de base App Control : si vous appliquez déjà App Control, fusionnez le XML publié dans votre base. Le XML publié contient des règles « tout autoriser » pour pouvoir fonctionner seul ; supprimez-les avant de fusionner dans une stratégie de liste d'autorisation, sinon vous ouvrirez entièrement votre liste d'autorisation.

   PowerShell

   Merge-CIPolicy -PolicyPaths .\Base.xml, .\DriverBlockRules.xml -OutputFilePath .\Base-merged.xml

Quelle que soit l'option choisie, inscrivez une tâche récurrente dans votre calendrier de changements : vérifier la version publiée chaque trimestre et après toute divulgation BYOVD majeure.

Étape 4 : ajouter la règle ASR et la détection

La liste de blocage empêche un pilote de se charger. Deux couches supplémentaires aident :

• La règle ASR « Block abuse of exploited vulnerable signed drivers » (GUID 56a863a9-875e-4185-98a7-b882c64b5ce5) empêche les applications d'écrire sur le disque des pilotes vulnérables connus. Passez-la en blocage ; elle fait partie de l'ensemble de protection standard décrit dans le guide des règles ASR.
• La détection des chargements de pilotes. L'événement Sysmon 6 (pilote chargé) enregistre le hash et la signature de chaque pilote. Comparez les nouveaux hashs à votre inventaire de référence et à des listes communautaires comme LOLDrivers. L'événement 7045 du journal Système (un service a été installé) détecte la création de service qui précède généralement le chargement d'un pilote.

Les pilotes utilisés dans de vraies attaques BYOVD sont souvent d'anciens utilitaires légitimement signés : outils d'overclocking, outils de mise à jour de micrologiciel des fabricants et composants anti-triche. Le même fichier signé peut être anodin sur un PC de jeu et constituer un signal d'alarme sur un serveur de fichiers.

Une façon rapide d'examiner les chargements de pilotes sur un hôte équipé de Sysmon :

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=6} -MaxEvents 500 |
  ForEach-Object { $x = [xml]$_.ToXml(); [pscustomobject]@{
    Time      = $_.TimeCreated
    Driver    = ($x.Event.EventData.Data | Where-Object Name -eq 'ImageLoaded').'#text'
    Signature = ($x.Event.EventData.Data | Where-Object Name -eq 'Signature').'#text'
    Hashes    = ($x.Event.EventData.Data | Where-Object Name -eq 'Hashes').'#text' } } |
  Sort-Object Driver -Unique

Tout pilote chargé depuis un profil utilisateur, C:\ProgramData, C:\Windows\Temp ou un autre emplacement accessible en écriture est suspect, quelle que soit sa signature.

Étape 5 : aller plus loin sur les serveurs

La liste de blocage répond à la question « ce pilote est-il connu comme dangereux ? ». Sur les serveurs, vous pouvez poser la question plus exigeante « ce pilote est-il attendu ici ? ». Le matériel serveur change rarement, l'ensemble des pilotes est donc restreint et stable, ce qui rend réaliste une liste d'autorisation des pilotes :

1. Construisez une stratégie App Control à partir d'un serveur de référence pour chaque modèle matériel, avec les pilotes noyau au niveau éditeur (New-CIPolicy -Level Publisher -Fallback Hash -ScanPath C:\Windows\System32\drivers).
2. Fusionnez-y les règles de blocage de pilotes recommandées, sans leurs règles « tout autoriser ».
3. Faites-la tourner en mode audit sur un cycle de correctifs complet, y compris les mises à jour de micrologiciel et de pilotes de stockage, puis passez en application.

Si c'est trop pour l'instant, tenez au moins un inventaire des pilotes par modèle de serveur et alertez sur tout pilote dont le hash n'a jamais été vu dans votre parc. Le guide du managed installer explique comment garder une telle stratégie maintenable lorsqu'elle s'étend au-delà des pilotes.

Ce qui casse

Très peu de choses, ce qui explique pourquoi ce contrôle devrait être universel. Les rares cas :

• Anciens utilitaires matériels : outils de fabricants livrant une version vulnérable d'un pilote (contrôle des ventilateurs, éclairage RGB, outils de flashage du BIOS). La solution est la version mise à jour de l'éditeur, qui normalement ne figure pas sur la liste.
• Anciens anti-triche ou DRM sur les appareils personnels.
• Pilotes industriels ou de laboratoire spécialisés jamais mis à jour.

Lorsqu'un pilote est bloqué, l'appareil continue de démarrer, mais le composant ne démarre pas. Vérifiez avant d'appliquer sur des serveurs au matériel inhabituel, et résistez à la tentation de désactiver la liste de blocage pour un outil ; remplacez ou isolez l'outil.

Vérifier

1. Stratégie active : CiTool.exe --list-policies liste les stratégies actives, dont la stratégie de blocage des pilotes, avec leur version ; comparez la version avec celle que vous vouliez déployer.
2. Activation au démarrage : dans Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational, l'événement 3099 enregistre chaque stratégie activée au démarrage, avec son nom et sa version.
3. Blocages : les événements 3077 (application) et 3076 (audit) du même journal montrent un pilote qui a été, ou aurait été, bloqué. L'événement 3089 suit avec les détails de signature.
4. Tester sans risque : ne téléchargez pas de pilotes vulnérables sur des systèmes de production pour tester. Utilisez une VM de laboratoire isolée, ou appuyez-vous sur les vérifications de stratégie et d'événements ci-dessus.

Transférez les événements CodeIntegrity vers votre SIEM. Un pilote bloqué sur un serveur n'est presque jamais un accident ; traitez un événement 3077 concernant un pilote BYOVD connu comme le signal d'une intrusion en cours et lancez la réponse à incident.

Liste de contrôle

• VulnerableDriverBlocklistEnable = 1, ou intégrité de la mémoire active, sur chaque poste et serveur
• Serveurs et VM sans sécurité basée sur la virtualisation vérifiés explicitement
• Dernière liste de blocage publiée déployée, testée d'abord en audit sur un anneau pilote
• Règles « tout autoriser » supprimées avant de fusionner la liste de blocage dans une liste d'autorisation App Control
• Règle ASR sur les pilotes signés vulnérables en mode blocage
• Événement Sysmon 6 et événement Système 7045 collectés et examinés
• Événement CodeIntegrity 3077 sur des pilotes assorti d'une alerte de gravité élevée
• Tâche trimestrielle de vérification d'une version plus récente de la liste de blocage

La liste de blocage est un petit changement à l'effet démesuré sur la façon dont les attaquants désactivent vos défenses. Elle donne le meilleur d'elle-même avec l'intégrité de la mémoire et une stratégie complète issue du domaine Contrôle des applications, le managed installer gardant cette stratégie maintenable.