Une équipe de recherche a mis en lumière un scénario inquiétant : sur un Windows 11 entièrement à jour, il serait possible d’obtenir une prise en main SYSTEM en détournant le chemin d’installation qui suit l’apparition d’un périphérique USB via Plug-and-Play. Le point clé n’est pas un « hack » direct du système, mais l’exploitation d’une logique d’installation considérée comme légitime—associée à des maillons spécifiques dans des composants tiers.
Concrètement, les chercheurs expliquent comment un utilisateur sans privilèges pourrait, sous certaines conditions, amener Windows à lancer des composants d’installation avec des droits élevés. Ils présentent également une variante déclenchable à distance via Remote Desktop, lorsque la redirection USB et le Plug-and-Play sont configurés de manière compatible.
Pourquoi Plug-and-Play peut devenir un chemin d’élévation
Windows s’appuie sur un mécanisme Plug-and-Play pour gérer l’arrivée d’un périphérique. Lorsqu’un appareil “se présente”, Windows récupère des informations matérielles comme les identifiants matériels et les compatibles IDs, puis cherche un package de pilote correspondant. Cette étape de sélection est documentée : à partir des identifiants du périphérique, Windows trouve un pilote compatible et lance le processus d’installation associé.
Dans l’approche décrite, le “périphérique” n’est pas forcément un matériel physique réel. Les chercheurs construisent des périphériques émulés qui exposent les identifiants attendus, afin de guider Windows vers un flux d’installation précis. Leur objectif : transformer un chemin d’installation normalement contraint en un exécutable menant au niveau SYSTEM.
La chaîne locale : USB émulé et services SYSTEM
Dans la démonstration locale, les chercheurs débutent par l’émulation d’un dispositif associé à une marque de référence (dans leurs termes, une cible “Sierra Wireless”). Windows, en découvrant ce périphérique émulé, déclenche l’installation liée à ce scénario et installe notamment un composant SwiService.exe présenté comme un service au niveau SYSTEM, avec une primitive permettant d’agir sur le paramétrage DNS.
À partir de là, la chaîne se poursuit avec une manipulation DNS afin de rediriger un flux nécessaire à la suite. L’attaque enchaîne ensuite sur une autre émulation, cette fois orientée vers une capacité “lecteur” (leur exemple mentionne un lecteur de type FeliCa). L’installation correspondante récupère ensuite des fichiers de configuration via une communication en texte clair en HTTP, et génère des noms locaux à partir du chemin présent dans les URL.
Le dernier maillon critique repose sur une faille de parcours de chemin (path traversal). Selon les chercheurs, cette faiblesse permettrait de déposer une DLL dans le dossier System32. Quand le périphérique émulé “Sierra” est reconnecté, Windows chargerait alors la DLL placée, ce qui donnerait finalement une exécution en SYSTEM.
Limite importante : ne pas généraliser à tout Windows
Les chercheurs précisent que leur démonstration a été réalisée sur un Windows 11 entièrement à jour. Ils recommandent donc de ne pas étendre automatiquement le résultat à une plage plus large de versions non vérifiées. Dit autrement : le scénario est réel, mais son applicabilité dépend fortement de l’environnement testé.
Variante à distance : déclenchement via Remote Desktop
La même logique de détournement du flux Plug-and-Play peut, dans certains cas, être reproduite à distance. L’idée est de remplacer le périphérique physique par des trames USB synthétiques transportées sur une session RDP, à condition que la configuration supporte Plug-and-Play ou une redirection USB de bas niveau.
Les chercheurs expliquent qu’une variante remplace la présence d’un matériel par la création d’une identité USB forgée, présentée à Windows afin qu’il “croie” voir un appareil cible (dans leur exemple, un périphérique de type Intel RealSense). Ainsi, Windows suit le chemin d’installation redirigé, comme s’il s’agissait d’une machine disposant du matériel.
Dans cette partie, le résultat s’appuie sur une hijack de l’ordre de recherche (search-order hijack) impliquant un fichier nommé CRYPTBASE.dll. L’attaque viserait un répertoire modifiable par l’utilisateur pour provoquer le chargement du composant malveillant, ce qui aboutit là encore à une exécution de code avec SYSTEM pour l’utilisateur authentifié en privilèges faibles.
Conditions et configuration : ce n’est pas une exposition par défaut
Un point rassurant, mais à nuancer : les chercheurs soulignent que la voie à distance n’est pas un comportement activé par défaut. Microsoft indique notamment que Remote Desktop Services ne permet pas la combinaison Plug-and-Play et redirection USB (par RemoteFX USB redirection) par défaut dans ses configurations supportées.
Pour que la redirection USB de bas niveau fonctionne, la documentation mentionnée par les chercheurs indique qu’il faut activer d’abord une redirection Plug-and-Play avant que le forwarding USB de bas niveau puisse opérer. Autrement dit, un administrateur qui n’a pas besoin de la fonctionnalité peut la laisser désactivée pour réduire l’exposition.
Les politiques de l’installation des périphériques jouent aussi un rôle. Microsoft fournit des mécanismes de restrictions qui peuvent autoriser ou bloquer des appareils via des éléments comme les IDs matériels, les device-instance IDs et les setup classes. En contexte Remote Desktop, ces politiques peuvent également influencer les périphériques redirigés.
Pré-conditions : il faut pouvoir “présenter” le périphérique émulé
Au-delà de la configuration logicielle, la chaîne locale comporte une contrainte de base : l’attaquant doit être en mesure de présenter un périphérique USB émulé à la machine cible. Sans cette étape—c’est-à-dire sans moyen de faire apparaître l’appareil tel que attendu par Windows—le mécanisme d’installation ne se met pas en place selon la logique décrite.
En revanche, le cœur du message des chercheurs reste le même : il s’agit d’une abuse d’un chemin d’installation privilégié existant, combiné à des faiblesses liées à des packages signés de tiers. Cette combinaison transforme un processus censé être sûr en une surface exploitable.
Ce que les chercheurs attribuent et comment interpréter les résultats
Les chercheurs indiquent que les détails exploitent des mécaniques spécifiques à des vendeurs cités (dans leur exposé : des aspects liés à des “Sierra”, “Sony” et “Intel”). Ils recommandent de conserver l’attribution telle qu’ils l’ont présentée, à moins que du contenu équivalent soit confirmé indépendamment par d’autres travaux portant sur les mêmes composantes fournisseurs.
Ce point est important pour comprendre la portée : le scénario ne repose pas uniquement sur Windows en soi, mais sur l’assemblage d’un flux d’installation légitime et de maillons “vendor-specific” qui peuvent exister dans certains environnements.
Comment se protéger contre ce type de chaîne d’installation
Sans prétendre à des remèdes universels (puisque l’applicabilité dépend des configurations), l’approche de défense suit des principes concrets :
- Désactiver les fonctions de redirection USB dans Remote Desktop si elles ne sont pas nécessaires.
- Contrôler les politiques d’installation des périphériques : autoriser uniquement des IDs et classes attendus.
- Limiter la surface Plug-and-Play côté machines sensibles, en réduisant les opportunités d’introduire des périphériques (physiques ou émulés).
- Surveiller les installations et comportements inhabituels autour des pilotes et composants d’accompagnement, notamment lorsqu’ils déclenchent des services.
Enfin, gardez à l’esprit que la démonstration mentionne une machine Windows 11 entièrement à jour : la mise à jour régulière reste une base, mais ne garantit pas à elle seule l’absence de scénarios basés sur des chaînes logiques et des composants tiers.
Conclusion
Cette recherche met en évidence une mécanique où Plug-and-Play, conçu pour simplifier l’ajout de matériel, peut être détourné pour conduire à une prise en main SYSTEM sur Windows 11. La chaîne décrite combine l’émulation d’identités USB, un enchaînement d’installations guidées par les correspondances de pilotes, et des failles spécifiques exploitées via des packages de tiers.
Le volet à distance n’est pas une exposition par défaut : il dépend d’une configuration supportant Plug-and-Play et la redirection USB sur RDP. C’est précisément pour cela que les contrôles d’administration (politiques de périphériques, désactivation des redirections inutiles) et la surveillance des installations restent des leviers essentiels pour réduire le risque.
Source: https://thehackernews.com/2026/08/researchers-turn-usb-auto-install-into.html
