## 1 Introduction Cet article fournit une analyse technique de la manière dont de nombreux pilotes Windows en mode noyau peuvent être interrogés depuis le mode utilisateur sans le matériel pour lequel ils ont été développés. Ce travail a été motivé par la recherche de vulnérabilités axées sur les pilotes et la nécessité d'évaluer l'exploitabilité des découvertes individuelles, qui affectent fréquemment le code dont l'accessibilité est limitée par le matériel. La méthodologie présentée ici devrait aider quiconque à déterminer si une vulnérabilité particulière d'un pilote Windows en mode noyau reste accessible - et donc potentiellement exploitable - même en l'absence du matériel pour lequel le pilote a été développé. Le lecteur est censé avoir des connaissances de base sur les pilotes Windows, en particulier concernant les objets de périphérique. Le reste de cet article est rédigé en supposant que le lecteur est déjà familiarisé avec les concepts décrits dans l'article d'introduction : [Anatomy of Access: Windows Device Objects from a Security Perspective](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Tout comme l'article d'introduction, cette ressource ne se concentre pas sur une classe de bug spécifique, mais plutôt sur la surface d'attaque et, dans une certaine mesure, sur l'architecture Plug and Play de Windows. Tous les tests démontrés ici ont été effectués sur **Windows 11 23H2** (winver 10.0.22631.3007). >Pour plus de recherches sur les menaces et d'avis de vulnérabilité, veuillez vous abonner aux [**blogs Atos Cyber Shield**](https://atos.net/en/lp/cybershield#subscription-form). ## 2 La valeur offensive des pilotes en mode noyau En plus du potentiel évident d'escalade de privilèges locaux, les pilotes vulnérables sont souvent exploités dans les attaques BYOVD - une technique post-exploitation utilisée par les attaquants pour perturber les défenses du système telles que les composants EDR. Deux critères principaux déterminent si une vulnérabilité de pilote est un bon candidat pour les attaques BYOVD : 1. L'exploitation permet une perturbation significative d'un composant de sécurité autrement résistant à la falsification. Les exemples incluent les vulnérabilités au niveau du noyau accordant un accès arbitraire en lecture/écriture de mémoire, une exécution de code arbitraire ou une utilisation abusive de ressources arbitraires (par exemple, écraser des fichiers, fermer des handles ou terminer des processus). 2. Son exploitabilité est indépendante de conditions système rares, telles que la présence de matériel spécifique. Bien que les attaques de type BYOVD soient bien documentées depuis des années, avec de nombreux rapports publics et articles de recherche sur le sujet (par exemple [https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf), [https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/](https://blackpointcyber.com/blog/qilin-ransomware-and-the-hidden-dangers-of-byovd/), [https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants](https://www.sophos.com/en-us/blog/itll-be-back-attackers-still-abusing-terminator-tool-and-variants)), aucun d'entre eux n'examine spécifiquement le rôle du verrouillage matériel dans l'accessibilité des vulnérabilités de pilotes. ## 3 Création et maintenance des objets de périphérique - modèles courants L'analyse fournie dans cette ressource est structurée autour des objets de périphérique, car ils constituent le vecteur d'attaque le plus viable. Cependant, les techniques démontrées ici ont un impact pratique sur l'accessibilité du code du pilote depuis l'espace utilisateur en général, pas seulement via IRP. Les obstacles les plus courants dans l'attaque d'un pilote via son objet de périphérique sont : 1. L'objet de périphérique n'est pas créé. 2. L'état interne du pilote ne permet pas d'exercer le comportement vulnérable malgré l'accessibilité de l'objet de périphérique. Ces deux scénarios sont très courants lorsqu'il s'agit d'un pilote de périphérique déployé sur un système sans le matériel physique correspondant. Dans le reste de l'article, je fais souvent référence aux [piles d'appareils et aux nœuds d'appareils](https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/device-nodes-and-device-stacks). J'ai couvert les piles d'appareils assez largement dans mon [article d'introduction](https://atos.net/en/lp/cybershield/anatomy-of-access-windows-device-objects-from-a-security-perspective). Bien qu'un nœud d'appareil et une pile d'appareils ne soient pas la même chose, les termes sont souvent utilisés de manière interchangeable, car chaque nœud d'appareil possède exactement une pile d'appareils. ### 3.1 Création inconditionnelle au chargement du pilote De nombreux pilotes, en particulier les pilotes non PnP, créent leurs objets de périphérique soit directement depuis leur fonction `DriverEntry`, soit depuis une autre fonction qui est appelée dans la chaîne d'appels directe provenant de `DriverEntry`. Le [**pilote de démonstration Multidev_WDM**](https://github.com/Atos-TRC/Atos-TRC-public-samples-and-code/windows-kernel-mode/kernel/multidev_WDM/) illustre ce modèle. Nous pouvons voir la création de l'objet de périphérique appelée immédiatement dans `DriverEntry` :  Création du CDO appelée directement depuis `DriverEntry` Le pilote supprime également l'objet de périphérique en appelant `IoDeleteDevice`, mais cela ne se produit que lorsque `DriverUnload` est appelé (lorsque le pilote est déchargé) :  Nettoyage du CDO depuis `DriverUnload` Les pilotes construits de cette manière peuvent être interrogés après un déploiement simple consistant en deux étapes : 1. Créer l'entrée de service du pilote : sc.exe create SampleDrv type= kernel start= demand binPath= System32\drivers\SampleDrv.sys * Démarrer le service (le pilote sera chargé) : sc.exe start SampleDrv Si nous regardons un pilote choisi au hasard sur [https://loldrivers.io/](https://loldrivers.io/), nous verrons que sa commande de déploiement correspond à ce modèle :  LOL drivers - déploiement de zam64.sys Mais la plupart des pilotes de périphériques n'entrent pas dans cette catégorie, comme nous le verrons dans les sections suivantes de cet article. ### 3.2 Création et maintenance conditionnelles des périphériques Souvent, les routines d'initialisation des pilotes effectuent des vérifications supplémentaires. Par exemple, les composants en mode noyau des logiciels de sécurité (**EDR**, antivirus, surveillance, authentification améliorée, etc.) ont tendance à vérifier les clés et entrées de registre spécifiques au produit, qui sont créées et initialisées lors du déploiement normal du produit. Les véritables pilotes de périphériques (créés pour piloter du matériel physique) ont tendance à ne créer leurs objets de périphérique qu'en présence de ce matériel. Sans cela, ils soit : * n'essaient pas de créer d'objets de périphérique du tout, * ils suppriment tout objet de périphérique peu de temps après sa création, en appelant `IoDeleteDevice`. Concentrons-nous sur la manière dont cette logique est implémentée et évaluons si et comment elle peut être contournée, en particulier du point de vue BYOVD - en opérant uniquement depuis l'espace utilisateur (sans accès physique/hyperviseur). Soit dit en passant, le deuxième scénario, dans lequel un objet de périphérique est d'abord créé puis supprimé peu de temps après, crée une situation qui pourrait être considérée comme une condition de concurrence (race condition), car il existe une courte fenêtre de temps pendant laquelle l'objet de périphérique existe. ### 3.3 Les rappels spécifiques à PnP comme emplacement principal de la logique d'initialisation des pilotes PnP Dans les pilotes compatibles PnP (qui constituent la majorité des pilotes de périphériques