Windows’ Plug-and-Play ist dafür gedacht, Geräte beim Einstecken automatisch einzurichten. Genau diese Komfortfunktion kann jedoch missbraucht werden: Laut Forschern lässt sich der normale Auto-Install-Pfad so ausnutzen, dass am Ende SYSTEM-Codeausführung entsteht – selbst wenn der Angreifer zunächst keine erhöhten Rechte hat.
Die Technik basiert auf einer Kombination aus emulierten USB-Geräten, dem Treiber-/Paket-Auswahlprozess von Windows und Schwächen in der Art, wie signierte, herstellerspezifische Installationskomponenten miteinander interagieren. Besonders kritisch: Die Forscher demonstrierten ihre Kette auf einem vollständig aktualisierten Windows 11 und betonen, dass man die Ergebnisse nicht pauschal auf jede Windows-Variante übertragen sollte.
Wie Windows Plug-and-Play normalerweise arbeitet
Damit ein Gerät korrekt eingebunden wird, erhält Windows beim Anstecken (physisch oder emuliert) Informationen über das Gerät. Dazu gehören unter anderem Hardware- und kompatible IDs. Windows verwendet diese Angaben, um ein passendes Treiberpaket zu finden und die entsprechenden Installationsschritte auszuführen.
Der entscheidende Punkt der Studie: Wenn ein Angreifer die Identität eines Geräts so beeinflussen kann, dass Windows in eine gewünschte Installationsspur läuft, wird der legitime Installationspfad zur Angriffsfläche. Was dabei genau passiert, hängt davon ab, welche Komponenten zu den erkannten IDs passen.
Lokaler Angriff: von emuliertem USB bis SYSTEM
Die Forscher, namentlich Alejandro Hernando und Borja Martinez, beschreiben den Ansatz in ihrer für die DEF CON 34 vorbereiteten Arbeit. Sie haben dafür Werkzeuge gebaut, um beliebige USB-Geräte zu emulieren und damit die Windows-Sequenz rund um die Auto-Installation gezielt anzustoßen.
Unter den erforderlichen Bedingungen könne ein unprivilegierter Nutzer den PnP-Installationspfad in eine Form von SYSTEM-Codeausführung umwandeln. Das klingt zunächst abstrakt, ist aber als konkrete Kette umgesetzt:
- Windows soll zunächst so getäuscht werden, dass es ein spezifisches Geräteprofil als Sierra Wireless-ähnlich behandelt und dadurch eine Komponente wie SwiService.exe installiert bzw. startet.
- Diese SYSTEM-nahe Komponente wird laut Darstellung genutzt, um DNS-Weiterleitung umzubauen.
- Anschließend wird eine zweite Emulation nachgelegt: Windows soll außerdem so wirken, als handele es sich um einen Sony FeliCa-Leser. Dessen Installationslogik soll dann Konfigurationsdateien über HTTP im Klartext beziehen.
- Ein weiterer Schritt ermöglicht es den Forschern, über eine Pfad-Traversal-Schwäche eine DLL in System32 abzulegen.
- Durch das erneute Ankoppeln des emulierten Sierra-Geräts wird die abgelegte DLL geladen, wodurch letztlich der Sprung auf SYSTEM-Ebene gelingt.
Wichtig: Die Forscher weisen darauf hin, dass ihre Nachweise auf einem aktuell gepatchten Windows 11-System liefen. Man sollte daraus daher nicht automatisch ableiten, dass jede Windows-Version in jedem Setup gleich verwundbar ist.
RDP-Variante: Auto-Install auch ohne physische Hardware
Nicht nur physisch angeschlossene Geräte spielen eine Rolle. In bestimmten Umgebungen kann die gleiche PnP-Reihe auch über Remote Desktop angestoßen werden, selbst wenn kein echtes USB-Gerät vorhanden ist.
Das funktioniert laut Bericht dann, wenn unterstützte Plug-and-Play-Funktionen oder USB-Umleitung auf niedriger Ebene in der RDP-Konfiguration aktiv sind. Microsoft stellt dabei klar, dass diese Weiterleitungen nicht standardmäßig zulässig sind.
Für die Remote-Variante setzen die Forscher auf einen Python-Client, der synthetischen USB-Verkehr über RDP bereitstellt. Dabei wird eine USB-Identität gefälscht und ein „phantomartiges“ Gerät vorgetäuscht, sodass Windows dem redirected Gerät folgt und die Installation in die gewünschte Richtung lenkt.
Warum auch hier SYSTEM-Ebene möglich wird
Nach Darstellung der Forscher kann das resultierende Software-Setup anschließend für weitere Missbräuche dienen. Im konkreten Beispiel nennen sie einen Search-Order-Hijack über CRYPTBASE.dll aus einem anwenderbeschreibbaren Installationsverzeichnis.
Dadurch kann der angemeldete Nutzer auf SYSTEM-Codeausführung kommen. Zusätzlich verweist die Studie darauf, dass Microsoft dokumentiert, Redirected-USB-Peripherie verwende denselben Treiberinstallationsmechanismus wie ein lokales, physisch angebundenes Gerät.
Voraussetzungen und Konfigurationen: nicht „Default“
Die Angriffsoberfläche hängt stark von der Umgebung ab. Es gibt zwei klare Ebenen von Voraussetzungen:
- Physische Kette: Der Angreifer muss in der Lage sein, dem Zielsystem ein emuliertes USB-Gerät zu „präsentieren“.
- Remote Kette: Auf dem RDP-Server bzw. in der Session müssen bestimmte Richtlinien/Features die Weiterleitung so unterstützen, dass Windows den PnP-Installationspfad entsprechend verwenden kann.
Microsoft betont, dass Remote Desktop Services unterstütztes Plug-and-Play und RemoteFX USB-Redirecting nicht standardmäßig erlaubt. Außerdem heißt es in der Dokumentation, dass für die Weiterleitung auf niedriger Ebene das Plug-and-Play-Redirecting zuerst aktiviert sein muss.
Mit anderen Worten: Wer die Funktion nicht benötigt, kann und sollte sie deaktiviert lassen. Genau so lässt sich die Wahrscheinlichkeit reduzieren, dass überhaupt die Voraussetzungen für die Remote-Schiene entstehen.
Geräteeinschränkungen als Schutzmaßnahme
Ein weiterer Schutzpunkt sind Installationsrestriktionen. Microsoft stellt dafür Mechanismen bereit, mit denen Administratoren Geräte gezielt zulassen oder blockieren können.
Dazu zählen Einschränkungen nach:
- Hardware- und kompatiblen IDs
- Device-Instance-ID
- Setup Class
Für Remote Desktop gilt: Solche Policies können sich auch auf weitergeleitete bzw. redirectete Geräte auswirken. Praktisch bedeutet das: Selbst wenn Windows durch Identitäts-Täuschung einem Installationspfad folgen will, kann eine restriktive Regel es verhindern oder zumindest die Auswahl passender Pakete stark eingrenzen.
Was die Forschung besonders macht
Die Studie zeigt weniger eine exotische „Zero-Click“-Lücke, sondern eher ein gefährliches Zusammenspiel: ein legitimer privilegierter Installationspfad plus Schwächen in signierten Drittpaket-Komponenten. Angreifer profitieren davon, dass Windows für die Installation zunächst vertrauenswürdige Schritte startet, die jedoch an mehreren Stellen missbrauchbar werden.
Die Forscher nennen dabei konkrete Herstellerbezüge (Sierra, Sony, Intel) in der Angriffskette. Sie stellen jedoch auch klar, dass diese vendor-spezifischen Exploit-Details als Forschungsergebnisse zu behandeln sind und nicht „automatisch“ als allgemein bestätigt gelten, solange nicht unabhängige Hinweise des jeweiligen Herstellers bzw. entsprechende eigene Tests die Details stützen.
Fazit: Angriffsweg ernst nehmen, Remote-Weiterleitung absichern
Die Meldung macht deutlich, warum USB Plug-and-Play übernimmt Windows 11 als Thema nicht nur theoretisch ist. Wenn die Umgebung die passenden Bedingungen erfüllt, kann der Auto-Install-Pfad in eine Kette münden, die am Ende auf SYSTEM führt.
Für Administratoren steht daher vor allem Folgendes im Vordergrund: Remote-USB-Weiterleitungen und Plug-and-Play-Redirects nur dann aktivieren, wenn sie wirklich gebraucht werden, und darüber hinaus konsequent Geräteeinschränkungen nach IDs/Instance/Schnittstellenklasse einsetzen. Wer diese Hebel sauber konfiguriert, reduziert die Angriffsfläche deutlich – sowohl lokal als auch über RDP.
Quelle: https://thehackernews.com/2026/08/researchers-turn-usb-auto-install-into.html
