BYOVD-Angriffe: Microsoft unter Druck, den Windows-Kernel besser zu schützen

Die Logik mancher dieser Lücken erschließt sich kaum. Ein Beispiel: Ransomware-Akteure bewaffneten kürzlich einen legitimen Treiber, dessen digitales Zertifikat bereits 2010 widerrufen worden war, und nutzten damit eine gravierende Schwachstelle in den Windows-Schutzmechanismen aus.

Der Kern des Problems liegt in der Funktionsweise von Treibern. Sie ermöglichen die Kommunikation zwischen Anwendungen, Geräten und Betriebssystem und erhalten unter Windows üblicherweise Zugriff auf Ring 0, die Kernel-Ebene. Damit das Betriebssystem ihnen vertraut, müssen sie mit digitalen Zertifikaten signiert sein. Windows lädt Treiber jedoch bereits während des Startvorgangs, in dem keine Netzwerkverbindungen erlaubt sind — Sperrlisten für Zertifikate (CRLs) können daher nicht geprüft werden. Ein solcher Abgleich beim Start würde laut Experten die Systemleistung beeinträchtigen und möglicherweise neue Risiken schaffen.

Peter Morgan, Vice President of Research bei Halcyon, verweist auf den Unterschied zu macOS: Apple habe vor Jahren alle aus dem Kernel verbannt und werde dieses Problem daher nie haben. Windows hingegen sei darauf ausgelegt worden, nahezu alles zu unterstützen, was jemals unter Windows lief — und habe damit unbeabsichtigt ein weiteres Wettrüsten zwischen Angreifern und Verteidigern ausgelöst.

Microsoft hat über die Jahre durchaus nachgebessert. Mit Windows Vista wurde Driver Signature Enforcement eingeführt, das eine Signatur durch eine vertrauenswürdige Zertifizierungsstelle verlangt; mit Windows 10 kam die Pflicht, neue Kernel-Treiber über das Hardware Dev Center zu signieren. Doch eine riesige Lücke bleibt: Aus Gründen der Abwärtskompatibilität dürfen Treiber, die mit Zertifikaten vor dem 29. Juli 2015 signiert und an eine unterstützte, gegensignierte Zertifizierungsstelle gebunden sind, weiterhin geladen werden — selbst mit abgelaufenen oder widerrufenen Zertifikaten.

Forscher von Huntress dokumentierten einen Angriff, bei dem Akteure einen Treiber der Forensik-Suite EnCase von Guardian Software missbrauchten. Dessen Zertifikat war 2010 abgelaufen und anschließend von Guardian widerrufen worden. Jakub Souček, Senior Malware Researcher bei ESET, hält das für unsinnig: Ein Widerruf sei ein klares Signal des Herstellers, dass der Treiber unter keinen Umständen mehr geladen werden sollte.

Gegen bekannte missbrauchte Treiber pflegt Microsoft eine Vulnerable Driver Blocklist, die seit dem Windows-11-Update von 2022 standardmäßig aktiv ist. Doch auch diese Maßnahme greift zu kurz: Die Liste wird nur ein- bis zweimal jährlich aktualisiert, sodass neue BYOVD-Angriffe monatelang durchrutschen können. Hinzu kommt, dass laut Souček bei neu missbrauchten Treibern weiterhin 80 bis 90 Prozent der Nutzung legitim sind — ein vollständiges Blockieren über alle Systeme hinweg ist deshalb heikel, etwa bei kritischen Altsystemen im Gesundheitswesen.

Anna Pham, Senior Hunt and Response Analyst bei Huntress, schlägt häufigere, cloudbasierte Echtzeit-Updates nach dem Vorbild der Defender-Definitionen vor. Dick O’Brien vom Symantec and Carbon Black Threat Hunter Team fordert eine gründlichere Prüfung vor dem Signieren, aktives Widerrufen verwundbarer Treiber sowie eine Richtlinie, die einen Treiber ausschließlich der ursprünglich vorgesehenen Anwendung vorbehält.

Microsoft erklärte gegenüber Dark Reading, man bewerte gemeldete Fälle, arbeite mit Veröffentlichungspartnern an korrigierten Versionen und blockiere verwundbare Versionen über die Blocklist, sobald sicherere Varianten verfügbar seien. Anlass war unter anderem die jüngste “Reynolds"-Ransomware-Kampagne, bei der das Symantec and Carbon Black Threat Hunter Team einen verwundbaren NSecKrnl-Treiber von NsecSoft entdeckte, der zusammen mit der Ransomware ausgeliefert wurde.

Als Alternativen nennen Forscher das Open-Source-Projekt LOLDrivers (Living Off the Land Drivers), das eine umfangreichere und häufiger aktualisierte Liste pflegt. EDR-Anbieter könnten zudem nicht nur bereits missbrauchte, sondern auch wahrscheinlich gefährdete Treiber sperren. Damit verlagert sich ein Großteil der Last jedoch auf die EDR-Hersteller und die Anwenderorganisationen, denen oft Fachwissen und Ressourcen fehlen. Souček warnt: Sobald ein Treiber geladen und ausgeführt werde, gebe es keine wirksame Verteidigung mehr.