Die Sicherheitsforschung offenbart ein fundamentales Problem der Windows-Treiberarchitektur: Viele Kernel-Treiber, insbesondere solche für spezialisierte Hardware wie Smart-Amplifier-Controller oder Gaming-Maus-Filter, erstellen ihre kritischen Geräte-Objekte erst dann, wenn die entsprechende Hardware erkannt wird. Dies sollte eigentlich ein Schutz sein – doch neue Forschung zeigt, dass dieser Schutz von einem Angreifer mit administrativen Privilegien umgangen werden kann.
Das zentrale Problem liegt in der Plug-and-Play-Architektur (PnP) von Windows. Wenn ein Treiber geladen wird, führt Windows nicht sofort alle Initialisierungsroutinen aus. Stattdessen warten viele Treiber auf den Aufruf der AddDevice-Routine durch den PnP-Manager – diese wird normalerweise erst ausgelöst, wenn Windows die entsprechende Hardware erkennt. Ohne diese Routine werden kritische Datenstrukturen nicht initialisiert und verwundbare Code-Pfade bleiben unerreichbar.
Doch hier beginnt die Problematik: Forscher haben herausgefunden, dass sich Software-Geräte mit gefälschten Hardware-IDs erstellen lassen, die Windows täuschen, die AddDevice-Routine auszuführen. Dies geschieht mit Standard-Tools wie devcon.exe und pnputil.exe – beides legitime Windows-Verwaltungsprogramme. Der Angreifer nutzt die INF-Datei des Treibers, extrahiert die Hardware-ID und erstellt einen virtuellen Geräteknoten mit dieser ID. Windows erkennt dies als echte Hardware und initialisiert den Treiber vollständig.
In Tests führte dieser Ansatz zu fast doppelt so vielen neu erstellten Geräte-Objekten im Vergleich zu einfachen Laden-ohne-Hardware-Szenarien. Das bedeutet: Treiber-Schwachstellen, die theoretisch an Hardware gebunden sind, werden praktisch exploitbar.
Eine zweite Methode ist noch direkter: Angreifer können Windows zwingen, einen verwundbaren Treiber als Standard-Treiber für bestehende Hardware zu installieren. Indem sie Registry-Strukturen direkt manipulieren und die Treiber-Service-Namen an Geräte-Instanzen binden, umgehen sie vollständig die INF-File- und digitale Signatur-Überprüfungen des PnP-Managers. Der Treiber wird aktiviert, als ob eine legitime Installation stattgefunden hätte.
Für BYOVD-Angriffe ist dies fatal: Ein Angreifer mit Admin-Rechten (beispielsweise nach Phishing oder einer anderen initialen Kompromittierung) kann nun beliebige vulnerable Kernel-Treiber laden und initialisieren, unabhängig davon, welche Hardware vorhanden ist. Er kann dann speicher-Lese/Schreib-Zugriffe, beliebige Code-Ausführung oder Ressourcen-Manipulation nutzen, um EDR-Agents, Windows Defender oder andere Sicherheitskomponenten zu deaktivieren.
Das Forschungspapier demonstriert dies mit praktischen Beispielen: Gaming-Maus-Filter-Treiber laufen auf Festplatten, Audio-Treiber auf völlig falscher Hardware. Breakpoint-Analysen zeigen, dass die dispatch-Routinen vollständig erreichbar und ausführbar sind.
Die Implikationen sind gravierend. Windows-Administratoren können nicht mehr davon ausgehen, dass fehlende Hardware einen Treiber “automatisch sicher” macht. Deutsche Unternehmen und Behörden müssen davon ausgehen, dass jeder installierte Treiber mit bekannten Schwachstellen ein potenzielles BYOVD-Vektor ist – unabhängig davon, ob die entsprechende Hardware im System vorhanden ist. Das BSI empfiehlt in solchen Fällen regelmäßige Updates, aber auch proaktives Deinstallieren unnötiger Treiber. Zudem sollten Organisationen erwägen, Administratoren-Konten stärker zu isolieren und zu überwachen, da diese Angriffsmethode erhöhte Privilegien voraussetzt.
Mit fortschreitender AI-gestützter Schwachstellenforschung und dem Auslaufen des Cross-Signing-Vertrauens für ältere Treiber könnte das BYOVD-Risiko zunächst sinken – doch genau das könnte Angreifer dazu bewegen, verstärkt auf Hardware-gebundene Schwachstellen zu fokussieren, von denen sie jetzt wissen, dass sie auch ohne Hardware exploitbar sind.