Une chaîne d'exploitation qui exploite un mécanisme légitime de Windows

Le 11 août 2026, des chercheurs en sécurité ont révélé au DEF CON 34 une technique baptisée « Plug And Pwn : Weaponizing Windows PnP Auto-Install », démontrant comment le sous-système Plug and Play (PnP) de Windows — conçu pour installer automatiquement des pilotes lorsqu'un périphérique est connecté — peut être transformé en vecteur d'escalade de privilèges jusqu'au niveau SYSTEM, le plus élevé sur Windows.

Les chercheurs Alejandro Hernando (connu sous le pseudonyme 0xedh) et Borja Martínez (borjmz), tous deux chercheurs en sécurité et red teamers, ont présenté cette recherche lors de la conférence DEF CON 34, qui s'est tenue à Las Vegas. Il s'agit de leur deuxième passage au DEF CON, après leur talk « Kill Chain Reloaded » présenté à l'édition 33.

L'exploitation a été démontrée sur un Windows 11 entièrement à jour, ce qui en fait une finding particulièrement notable. Comme le souligne l'article de The Hacker News, le résultat ne doit toutefois pas être généralisé à des versions de Windows non testées.

Comment fonctionne le mécanisme PnP de Windows

Pour comprendre l'attaque, il faut d'abord comprendre comment Windows installe les pilotes. Selon la documentation officielle de Microsoft, lorsqu'un périphérique est connecté, Windows récupère ses hardware IDs et compatible IDs — des chaînes d'identification fournies par le fabricant — et les compare aux packages de pilotes disponibles dans le driver store, dans les emplacements spécifiés par la clé de registre DevicePath, ou via Windows Update.

Le système attribue un « rang » à chaque package correspondant : plus le rang est bas, meilleur est la correspondance. Windows installe ensuite le pilote avec le rang le plus faible. Ce processus, entièrement automatique, ne nécessite aucune intervention de l'utilisateur — c'est précisément cette automatisation que les chercheurs ont exploitée.

La chaîne d'exploitation physique : Sierra Wireless, Sony FeliCa et path traversal

La chaîne d'attaque physique repose sur l'émulation de périphériques USB spécifiques, en utilisant un outil développé par les chercheurs pour simuler des devices arbitraires. Voici les étapes détaillées :

  1. Émulation d'un device Sierra Wireless : Les chercheurs émulent un périphérique Sierra Wireless, ce qui pousse Windows à installer SwiService.exe, un service s'exécutant au niveau SYSTEM. Ce service expose une primitive SetDNS permettant de rediriger le DNS.

  2. Émulation d'un lecteur Sony FeliCa : Ensuite, les chercheurs émulent un lecteur de cartes Sony FeliCa. Le co-installer (programme d'installation complémentaire) de ce périphérique récupère des fichiers de configuration via HTTP en clair (non chiffré) et dérive les noms de fichiers locaux à partir des chemins d'URL.

  3. Path traversal vers System32 : Les chercheurs ont découvert une faille de path traversal (traversée de répertoire) dans ce co-installer, leur permettant de placer une DLL malveillante directement dans le dossier System32.

  4. Chargement de la DLL plantée : En reconnectant le device Sierra Wireless, Windows charge la DLL ainsi plantée — qui s'exécute avec les privilèges SYSTEM.

Cette chaîne illustre une utilisation abusive d'un chemin d'installation privilégié légitime, combiné à des faiblesses dans des packages logiciels signés par des tiers. Comme le note The Hacker News, les mécanismes d'exploitation spécifiques à Sierra, Sony et Intel restent des findings attribués aux chercheurs et doivent le rester tant que les fabricants concernés ne les confirment pas indépendamment.

La variante distante via RDP : un Intel RealSense fantôme

La variante distante de l'attaque est particulièrement intéressante : elle remplace le périphérique physique par du trafic USB synthétique transmis via le protocole RDP (Remote Desktop Protocol).

Les chercheurs ont développé un client Python qui forge une identité USB et présente un device Intel RealSense fantôme à la machine cible. Windows suit alors le chemin d'installation de périphérique redirigé et installe le logiciel RealSense.

L'exploitation se fait ensuite via un détournement de l'ordre de recherche de DLL (CRYPTBASE.dll) depuis un répertoire d'installation inscriptible par l'utilisateur, ce qui donne à l'utilisateur authentifié à faible privilège une exécution de code au niveau SYSTEM.

Microsoft confirme dans sa documentation que les périphériques USB redirigés de bas niveau utilisent le même processus d'installation de pilote qu'une machine Windows physique. Toutefois, l'entreprise précise que les services RDP n'autorisent pas par défaut la redirection Plug and Play ni la redirection USB RemoteFX. La redirection USB de bas niveau nécessite que la redirection Plug and Play soit activée au préalable.

Les conditions préalables et les précautions

Il est crucial de noter que cette attaque comporte des conditions préalables significatives :

  • Pour la chaîne physique : l'attaquant doit être en mesure de présenter un périphérique USB émulé à la machine cible. Cela implique un accès physique direct ou la capacité d'injecter un device USB malveillant.

  • Pour la variante distante : la redirection USB doit être explicitement activée dans la configuration RDP — ce qui n'est pas le cas par défaut. Les administrateurs qui n'ont pas besoin de cette fonctionnalité peuvent la laisser désactivée.

Les mesures de mitigation selon Microsoft

Microsoft propose plusieurs mécanismes de défense documentés dans son guide de gestion des installations de périphériques via les stratégies de groupe :

  • Restriction d'installation de périphériques : Les administrateurs peuvent autoriser ou bloquer des périphériques par hardware ID, compatible ID, device instance ID, ou setup class. Ces politiques peuvent également affecter les périphériques redirigés sur un serveur Remote Desktop.

  • Listes blanches/noires de devices : Il est possible de créer des listes d'autorisation ou de blocage précises, permettant par exemple d'autoriser uniquement un ensemble restreint de clés USB approuvées tout en bloquant tous les autres périphériques USB.

  • Désactivation de la redirection USB RDP : Pour les environnements qui n'en ont pas besoin, le simple fait de laisser la redirection USB désactivée (configuration par défaut) élimine le vecteur d'attaque distant.

Le contexte des chercheurs et leurs travaux antérieurs

Cette recherche s'inscrit dans une lignée de travaux des deux chercheurs. Alejandro Hernando, actif sur GitHub sous le pseudonyme 0xedh, s'est notamment fait connaître pour ses recherches sur un path traversal dans mstsc.exe (le client RDP de Windows), l'exploitation de firmware de caméras Hichip P2P, ou encore le contournement de protections sur des automates Schneider. Borja Martínez (borjmz) a collaboré avec lui sur plusieurs de ces projets, notamment le talk « Kill Chain Reloaded » présenté au DEF CON 33 en 2025.

Leur approche commune consiste à exploiter des mécanismes légitimes du système d'exploitation — ici l'auto-installation PnP — en combinaison avec des vulnérabilités dans des logiciels signés de tiers, plutôt que de cibler directement le noyau Windows.

Une leçon sur l'écosystème des pilotes signés

Ce qui rend cette recherche particulièrement préoccupante, c'est qu'elle ne repose pas sur une faille unique dans Windows, mais sur l'enchaînement de plusieurs faiblesses dans l'écosystème des pilotes signés :

  • Un service SYSTEM exposant une primitive de modification DNS (SetDNS)
  • Un co-installer récupérant des fichiers de configuration en HTTP non chiffré
  • Une faille de path traversal permettant d'écrire dans System32
  • Une vulnérabilité de DLL search-order hijacking dans un répertoire inscriptible par l'utilisateur

Chacune de ces faiblesses individuellement pourrait sembler mineure, mais leur combinaison produit une chaîne d'exploitation complète menant à SYSTEM. C'est un rappel que la sécurité de Windows ne dépend pas seulement du système d'exploitation lui-même, mais aussi de la qualité de sécurité des pilotes et logiciels que les fabricants publient et que Windows installe automatiquement — souvent sans aucune interaction de l'utilisateur.

La recherche sera présentée en détail au DEF CON 34, et les outils développés par les chercheurs devraient être publiés ultérieurement, permettant à la communauté de sécurité de reproduire et d'approfondir ces findings.