BTR Reforged: Microsoft-Defender-Treiber BTR.sys als Kernel-Waffe missbraucht

Check Point Research hat am 20. August 2026 eine ungewöhnliche Post-Exploitation-Technik offengelegt: „BTR Reforged“ macht Microsoft Defenders eigenen, digital signierten Boot-Zeit-Treiber BTR.sys zu einem Werkzeug für Datei- und Registry-Manipulationen aus Ring 0. Ein klassischer Softwarefehler, Speicherfehler oder zusätzlich eingeschleuster Fremdtreiber ist dafür nicht nötig. Genau deshalb sollten Windows-Verantwortliche nicht auf einen gewöhnlichen CVE-Patch warten, sondern Erkennung und Rechtevergabe in den Mittelpunkt stellen.

Aktuelle Meldung und Einordnung

Jiří Vinopal, Threat Researcher und Reverse Engineer bei Check Point Research, präsentierte die Ergebnisse als Hauptbühnen-Vortrag auf der Black Hat USA 2026 und der DEF CON 34 in Las Vegas. Zeitgleich mit dem Forschungspaper erschien das quelloffene Proof-of-Concept-Werkzeug BTR_CLI unter MIT-Lizenz. Die Live-Demonstration zeigte, wie der gesamte Defender-Stack auf einem vollständig aktualisierten System mit Windows 11 25H2 entfernt wurde, obwohl der Manipulationsschutz aktiviert war.

Die Reichweite ist groß: Laut den Forschern ist die zugrunde liegende Komponente in allen Windows-Versionen von Windows 7 bis Windows 11 25H2 vorhanden. Check Point prüfte 18 unterschiedliche 64-Bit-Versionen. In sämtlichen Exemplaren blieb der 256 Byte lange RC4-Schlüssel unverändert, den der Treiber für sein proprietäres Transaktionsformat verwendet.

Die Einordnung ist dennoch wichtig: Für die Ausführung benötigt ein Angreifer bereits ein Administratorkonto mit SeLoadDriverPrivilege. BTR_CLI kann dieses Recht nur automatisch aktivieren, wenn das Konto es schon besitzt. Die Technik verschafft daher keinen Erstzugriff und macht einen Standardnutzer nicht von selbst zum Administrator. Sie erweitert vielmehr die Möglichkeiten nach einer erfolgreichen Kompromittierung und hilft einem bereits privilegierten Angreifer, Sicherheitskomponenten vor oder während des Systemstarts zu entfernen.

Warum BTR.sys zu Defender gehört

BTR.sys steht für „Boot Time Removal Tool“. Defender benötigt den Treiber, wenn eine Bereinigung erst nach einem Neustart abgeschlossen werden kann, etwa weil Malware-Dateien oder Registry-Einträge während des laufenden Betriebs gesperrt sind. Die Binärdatei liegt nicht dauerhaft als gewöhnlicher Treiber im Treiberverzeichnis. Sie ist als Ressource BOOTTIMETOOL in MpEngine.dll eingebettet, wird bei Bedarf bereitgestellt und nach der Verwendung wieder entfernt.

Dieses legitime Betriebsmodell macht die Forschung sicherheitspolitisch relevant: Der Treiber stammt von Microsoft, ist korrekt signiert und erfüllt eine erforderliche Defender-Funktion. Eine Aufnahme in Microsofts Vulnerable Driver Blocklist würde die normale Malware-Bereinigung beschädigen. Auch eine pauschale Sperre über Windows Defender Application Control (WDAC) würde nicht nur den Missbrauch, sondern zugleich Defender selbst treffen.

1. Legitime Herkunft: BTR.sys ist Bestandteil von Microsoft Defender und wird nicht von außen mitgebracht.
2. Gültige Signatur: Windows vertraut dem von Microsoft signierten Kernel-Treiber.
3. Erforderliche Funktion: Der Treiber entfernt beim Booten Objekte, die im laufenden Windows gesperrt waren.
4. Breite Verfügbarkeit: Betroffen ist die Treiberfamilie von Windows 7 bis Windows 11 25H2.
5. Kein klassischer Exploit: Die veröffentlichte Methode nutzt vorgesehene Operationen über ein rekonstruiertes Transaktionsformat.

Technischer Ablauf von BTR Reforged

Vinopal rekonstruierte das undokumentierte Befehls- und Verschlüsselungsformat. Konfigurationsdaten für den Treiber werden mit RC4 und einem fest in der .rdata-Sektion gespeicherten 256-Byte-Schlüssel verschlüsselt. Das Proof of Concept findet zunächst MpEngine.dll unter den Defender-Definitionsupdates, extrahiert daraus die Ressource BTR.sys und erzeugt anschließend eine formal gültige, verschlüsselte Transaktion.

Zur Installation schreibt BTR_CLI den Dienst direkt unter HKLM in die Registry. Verwendet werden unter anderem Type=1, Start=1 und Group="Boot Bus Extender". Der Service Control Manager wird dabei vollständig umgangen. Dadurch fehlt der übliche Windows-Ereigniseintrag mit Event ID 7045 für einen neu installierten Dienst. Für die Überwachung ist gerade diese Lücke zwischen vorhandenen Registry-Artefakten und ausbleibender Standardprotokollierung wertvoll.

Ring 0 und das „Golden Window“

Nach dem Laden arbeitet BTR.sys im Kernel-Modus. Die Aktionen erscheinen in der Telemetrie unter dem System-Prozess mit PID 4. Der Treiber kann gesperrte Dateien und Verzeichnisse löschen, Dateien in frei gewählte Pfade verschieben, Registry-Schlüssel und -Werte entfernen sowie neue Registry-Werte beliebigen Typs schreiben. Als mögliches Ziel nennen die Forscher ausdrücklich auch System32\drivers.

Besonders relevant ist ein zweiter Ausführungsmodus, der Aktionen für den nächsten Neustart vormerkt. Vinopal bezeichnet das Intervall nach dem Beschreibbarwerden des Dateisystems, aber vor dem Start der Defender-Dienste im Benutzermodus, als „Golden Window“. In diesem Zeitfenster kann der Treiber Sicherheitsdateien wie WdFilter.sys und MsMpEng.exe physisch entfernen, bevor diese sich selbst sperren.

1. Gesperrte Dateien und vollständige Verzeichnisse lassen sich aus dem Kernel-Modus löschen.
2. Dateien können in beliebige Zielpfade verschoben werden, einschließlich System32\drivers.
3. Registry-Schlüssel und einzelne Registry-Werte können entfernt werden.
4. Neue Registry-Werte beliebiger Datentypen können angelegt werden.
5. Operationen können live oder für den nächsten Systemstart eingeplant werden.

Die Black-Hat-Demonstration belegt die praktische Wirkung unter Laborbedingungen: Auf einer vollständig aktualisierten Windows-11-25H2-Maschine entfernte BTR_CLI den kompletten Defender-Stack trotz aktiviertem Tamper Protection. Das bedeutet nicht, dass Tamper Protection wertlos ist. Es zeigt vielmehr, dass Schutzlogik im Benutzermodus gegen eine bereits autorisierte Kernel-Komponente im frühen Boot-Zeitfenster an eine architektonische Grenze stößt.

Warum kein klassischer Patch bereitsteht

Microsofts Security Response Center bewertete die verantwortungsvoll gemeldeten Ergebnisse laut Check Point so, dass sie nicht die Kriterien für eine sofortige Wartung erfüllen. Begründet wird dies mit den bereits notwendigen Administratorrechten und dem erforderlichen SeLoadDriverPrivilege. Vinopals GitHub-Repository beschreibt den Stand mit „No patch is planned“. Microsoft hat diese Formulierung nach Angaben von The Hacker News bislang nicht öffentlich bestätigt.

Damit unterscheidet sich BTR Reforged deutlich von „Bring Your Own Vulnerable Driver“: Dort bringen Angreifer einen bekannten verwundbaren Drittanbietertreiber mit, der nach Bekanntwerden blockiert werden kann. Hier ist kein importierter Treiber und keine traditionelle Schwachstelle nötig. Der Angreifer verwendet eine erlaubte, signierte Windows-Komponente und spricht sie in einem gültigen Format an. Blocklist und WDAC sind daher keine ausreichende Antwort, ohne die Defender-Funktion selbst zu beeinträchtigen.

Für die Risikobewertung in Unternehmen folgt daraus zweierlei. Erstens ist die Technik kein Grund für Alarmmeldungen über einen unmittelbar bevorstehenden Massenangriff ohne Zugangsdaten. Zweitens ist sie ein ernstes Werkzeug für die Phase nach einer Kontoübernahme, insbesondere wenn privilegierte Konten unzureichend getrennt, überwacht oder gehärtet sind. Der Schwerpunkt muss auf Verteidigungstiefe, Identitätsschutz und belastbarer Host-Telemetrie liegen.

Detection Engineering mit Sysmon

Check Point fand bislang keine Hinweise auf einen realen Missbrauch in freier Wildbahn. Gerade diese Ausgangslage bietet Verteidigern Zeit, Suchabfragen und Alarmkorrelationen zu entwickeln, bevor Kriminelle die Technik möglicherweise operationalisieren. Ein einzelnes Ereignis kann legitime Defender-Bereinigung abbilden; aussagekräftig werden vor allem ungewöhnliche Kombinationen, Zeitnähe und Abweichungen vom normalen Host-Verhalten.

Ein praxistauglicher Erkennungsplan sollte die von Check Point genannten Indikatoren nicht isoliert, sondern als Sequenz behandeln:

1. Sysmon Event ID 15 auf Zielnamen filtern, die mit .sys:changelist enden.
2. Sysmon RegistryEvent 12 und 13 auf Args mit :changelist und die Gruppe Boot Bus Extender prüfen.
3. Für denselben Host feststellen, ob nach der Registry-Anlage ein Windows Event ID 7045 ausbleibt.
4. Das schnelle Auftauchen und Verschwinden von \SystemRoot\Temp\BootClean.log über Sysmon 11 und 23 erfassen.
5. Sysmon 6 für das Laden des Treibers zeitlich mit Sysmon 23 für eine nachfolgende Dateilöschung verknüpfen.
6. Bei Dateioperationen des System-Prozesses PID 4 besonders auf Defender-Dateien und System32\drivers achten.
7. Legitime Defender-Bereinigungen im eigenen Bestand baselinen, bevor die Regel organisationsweit blockierend eingesetzt wird.
8. Treffer zusammen mit Kontoanmeldungen, Privilegienänderungen, Neustarts und EDR-Ausfällen in einer Incident-Zeitleiste untersuchen.

Härtung und Reaktion für Admins

Die wichtigste Härtungsmaßnahme ist laut Check Point die restriktive Vergabe von SeLoadDriverPrivilege. Das Benutzerrecht „Laden und Entfernen von Gerätetreibern“ sollte nur Konten und Rollen zur Verfügung stehen, die es betrieblich tatsächlich benötigen. Ein pauschaler lokaler Administratorstatus und gemeinsam genutzte Wartungskonten vergrößern die Post-Exploitation-Fläche unnötig.

1. Rechte inventarisieren: Per Gruppenrichtlinie und lokaler Sicherheitsrichtlinie dokumentieren, welche Konten SeLoadDriverPrivilege erhalten.
2. Least Privilege umsetzen: Das Recht aus Standard-Adminrollen entfernen, sofern keine nachgewiesene betriebliche Notwendigkeit besteht.
3. Admin-Konten trennen: Persönliche Nutzung, Serverwartung und besonders privilegierte Aufgaben mit unterschiedlichen Konten durchführen.
4. Sysmon-Konfiguration erweitern: Alternate Data Streams, Treiberladen, Dateioperationen und Registry-Änderungen für die genannten Pfade und Werte erfassen.
5. SIEM-Korrelation bauen: Registry-Service-Key ohne nachfolgende Event ID 7045 mit :changelist und BootClean.log kombinieren.
6. Reboot-Telemetrie erhalten: Ereignisse über Neustarts hinweg zentral sammeln, damit das „Golden Window“ nicht im lokalen Log-Rollover verschwindet.
7. Defender-Zustand überwachen: Unerwartet fehlende Dateien, Dienste, Filtertreiber oder Tamper-Protection-Statusänderungen als Incident behandeln.
8. PoC nicht produktiv testen: BTR_CLI ist ein offensives Werkzeug; Validierungen gehören in isolierte, rücksetzbare Laborsysteme.

Bei einem korrelierten Treffer sollten Teams den Rechner nicht vorschnell als bloßes Defender-Problem einstufen. Zuerst sind volatile Daten, aktive Sitzungen, verdächtige Admin-Anmeldungen und die Abfolge vor dem Neustart zu sichern. Danach sollten kompromittierte Zugangsdaten gesperrt, der Host isoliert und die Integrität der Sicherheitskomponenten von einem vertrauenswürdigen Medium beziehungsweise durch Neuinstallation wiederhergestellt werden. Die Technik setzt eine vorangegangene Privilegierung voraus; deshalb muss die Untersuchung den ursprünglichen Zugriffsweg ausdrücklich mit abdecken.

Historischer Kontext und Abgrenzung

BTR.sys war bereits 2021 Gegenstand von Sicherheitsforschung. SentinelLabs-Forscher Kasif Dekel entdeckte damals CVE-2021-24092. Diese andere Schwachstelle ermöglichte eine lokale Privilegieneskalation über einen Hardlink am Log-Pfad; Microsoft schloss sie am 9. Februar 2021. BTR Reforged ist nicht die Rückkehr dieses Fehlers, sondern die Umnutzung regulärer Treiberfunktionen durch ein bereits privilegiertes Konto.

Auch das Motiv, legitime Windows-Treiber als Angriffsbaustein zu verwenden, ist nicht völlig neu. FIN7 setzte im Zusammenhang mit „AvNeutralizer“ unter anderem den eingebauten Treiber ProcLaunchMon.sys ein, um Endpoint-Schutz zu stören. Der aktuelle Fall verschiebt den Fokus jedoch auf einen notwendigen Bestandteil von Defender selbst und zeigt damit die Grenzen rein signatur- und blocklistenbasierter Treiberabwehr.

Für kleine und mittlere Unternehmen lautet die nüchterne Einordnung: Es gibt derzeit weder einen bekannten Einsatz in freier Wildbahn noch einen initialen Remote-Angriffsweg durch BTR Reforged. Gleichzeitig kann ein Angreifer mit ausreichenden Rechten einen Schutzmechanismus beseitigen, auf den viele Betriebe als letzte Barriere vertrauen. Gute Kontentrennung, eingeschränkte Treiberrechte und zentrale Sysmon-Korrelationen sind deshalb nicht optionales Feintuning, sondern Bestandteile einer belastbaren Verteidigung nach einer ersten Kompromittierung.

Passende Anleitungen auf S-EDV

1. Microsoft Defender BlueHammer CVE-2026-33825: Patchstand heute prüfen – Weiterführende Einordnung zu einem klassischen, patchbaren Defender-Sicherheitsproblem.
2. Ransomware-Gruppe 'The Gentlemen': Neue Nr. 1 weltweit mit EDR-Killer GentleKiller – Hintergrund zu real eingesetzten EDR-Killern und der Abwehr nach einer Kompromittierung.
3. Microsoft Defender: RoguePlanet-Lücke CVE-2026-50656 bleibt vorerst ungepatcht – Vergleich mit einer ungepatchten Defender-Schwachstelle, die anders als BTR Reforged einen Softwarefehler nutzt.

Quellen

1. The Hacker News: Microsoft Defender's Own Driver Can Be Weaponized to Delete Security Software at Boot, 21. August 2026.
2. Check Point Research: BTR Reforged – Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive, 20. August 2026.
3. GitHub: Dump-GUY/BTR_CLI – Proof-of-Concept und Begleitmaterial unter MIT-Lizenz.
4. SentinelLabs: CVE-2021-24092 – 12 Years in Hiding, historischer Kontext zum selben Treiber.