Check Point Research hat eine Vorgehensweise offengelegt, die auf den ersten Blick unspektakulär wirkt: Ein Treiber, der eigentlich zum Aufräumen nach einem Neustart dient, soll sich für deutlich weitergehende Aktionen missbrauchen lassen. Konkret geht es um BTR.sys, ein Windows-Komponentenstück, das in Microsoft Defender integriert ist und im Boot-Prozess Remediation-Schritte ausführt. Die Studie zeigt, dass dabei auch Dateisystem- und Registry-Operationen auf Kernel-Ebene möglich sind.
Wichtig: Es wird keine klassische Schwachstelle beschrieben, die ohne Zugriff ausgenutzt werden könnte. Stattdessen steht ein Architektur- und Vertrauenskonzept im Fokus. Nach Ansicht der Forschenden lässt sich die Technik unter bestimmten Voraussetzungen durch Angreifer mit ausreichenden Rechten anstoßen. Eine nachweisbare Nutzung in realen Angriffen konnte Check Point bislang nicht belegen.
Was ist BTR.sys und warum ist der Treiber besonders
BTR.sys Sicherheitssoftware ist ein Thema, weil BTR.sys als legitimer Windows-Baustein ohnehin Teil der Defender-Funktionalität ist. Der Treiber wird laut Bericht nicht als fremdes Artefakt von außen „importiert“, sondern bei Bedarf innerhalb des Defender-Umfelds verwendet. Dadurch kann die Komponente nicht einfach durch gängige Treiber-Blocklisten neutralisiert werden, ohne Defender selbst zu gefährden.
Der Treiber ist ein erforderlicher Bestandteil und wurde von Check Point als Boot Time Removal Tool beschrieben. Er kommt zum Einsatz, wenn Defender nach einem Neustart noch Malware-Bestandteile entfernen muss, etwa Dateien oder Registry-Einträge, die zuvor im laufenden Windows-Betrieb gesperrt waren. Damit ist BTR.sys funktional genau dort aktiv, wo Sicherheitssoftware besonders empfindlich sein kann: in einer Phase, in der grundlegende Services noch nicht vollständig gestartet sind.
Welche Eingriffe sind möglich: von Dateien bis Registry
Die Forschenden beschreiben, dass BTR.sys beliebige Kernel-Operationen anstoßen kann. Dazu gehören insbesondere:
- Löschen von gesperrten Dateien und Verzeichnissen
- Verschieben von Dateien in Pfade, die nicht eingeschränkt sein müssen (inklusive System32 oolsartige Bereiche für Treiberpfade, wie berichtet)
- Entfernen von Registry-Schlüsseln und -Werten
- Schreiben neuer Registry-Werte in beliebigem Typ
Diese Aktionen werden durch eine Art Transaktionsprotokoll gesteuert. Check Point hat dafür Mechanismen rückerschlossen, die in einem proprietären, nicht dokumentierten Format vorliegen. Der wesentliche Punkt: Damit lassen sich konkrete Operationen zuverlässig „konfigurieren“, ohne dass dafür eine außerhalb der Maschine signierte oder eingebrachte Treiberkomponente erforderlich ist.
Wie BTR.sys konfiguriert wird: verschlüsselte Konfigurationsblobs
Ein Kernbefund der Analyse betrifft die Konfiguration, die an BTR.sys übergeben wird. Check Point gibt an, dass jeder Konfigurationsblock, der in den Treiber gelangt, RC4-verschlüsselt ist. Der Schlüssel sei als fest in der .rdata-Sektion verankert, und zwar in jeder ausgelieferten BTR.sys-Variante seit Windows 7.
Die Forschenden berichten außerdem, dass der Schlüssel über 18 unterschiedliche 64-Bit-Versionen hinweg unverändert geblieben ist. Das ist sicherheitstechnisch relevant, weil Angreifer so die benötigten Inhalte im Proof-of-Concept konsistent erstellen können.
Der Proof-of-Concept: BTR_CLI extrahiert und plant Boot-Operationen
Um das Vorgehen praktisch zu demonstrieren, stellte Check Point Research ein Proof-of-Concept-Tool bereit, BTR_CLI. Der Ansatz ist dabei nicht „Magie“, sondern folgt einem klaren Ablauf.
Laut Beschreibung findet das Tool zunächst die Defender-Datei MpEngine.dll in den Definition Updates, extrahiert daraus die im Ressourcenbereich eingebettete BTR.sys-Binärdatei und baut anschließend eine gültige verschlüsselte Transaktion für den Treiber.
Danach wird die Komponente als Service installiert. Der berichtete Weg nutzt direkte Registry-Schreibzugriffe auf HKLM mit bestimmten Parametern (Type=1, Start=1 und Group="Boot Bus Extender"). Bemerkenswert ist, dass dabei der Service Control Manager nicht in der üblichen Form genutzt wird. Dadurch sollen bestimmte typische Windows-Ereignisprotokolleinträge unterbleiben (im Bericht wird als Vergleich die Abwesenheit eines Service-Installed-Events erwähnt).
„Golden Window“: warum die Timing-Phase entscheidend ist
Der größte operative Hebel entsteht nach dem Laden des Treibers. Vinopal beschreibt eine Zeitspanne, die er als „golden window“ bezeichnet: Das ist der Zeitraum nach dem Moment, in dem das Dateisystem wieder beschreibbar ist, aber bevor Defenders benutzerseitige Dienste vollständig gestartet sind.
Gerade in dieser Phase kann der Treiber physisch Sicherheitskomponenten entfernen, bevor diese ihre Locks setzen oder sich gegen Veränderungen schützen können. Check Point führt als Beispiel an, dass BTR_CLI im Live-Demonstrationskontext die vollständige Defender-Kette auf einem vollständig gepatchten Windows 11 25H2 System entfernen konnte, selbst wenn Tamper Protection aktiv war.
Welche Voraussetzungen braucht ein Angreifer
Damit die Technik funktioniert, wird mindestens ein Administratorkonto benötigt, das außerdem über die Berechtigung SeLoadDriverPrivilege verfügt. Das Tool soll diese Berechtigung für Konten automatisch aktivieren, wenn sie bereits vorhanden ist.
Check Point stellt das außerdem in den Kontext anderer Angriffe, die das „Bring Your Own Vulnerable Driver“-Prinzip nutzen. Dort müssen Angreifer häufig bekannte, verwundbare Drittanbieter-Treiber einsetzen, die nicht selten gezielt blockierbar sind. Im hier betrachteten Ansatz dagegen steckt der Treiber in jeder Windows-Installation ab Windows 7 ohnehin bereits im System.
MSRC habe nach verantwortungsvoller Offenlegung laut Bericht keine unmittelbare Servicing-Empfehlung getroffen, weil die Technik an vorausgesetzte Administratorrechte gebunden ist. Das bedeutet: Es geht weniger um eine klassische Patch-Schwachstelle, sondern eher um die Möglichkeit, eine Vertrauensgrenze mit bestehenden Rechten zu überschreiten.
Gibt es Hinweise auf echte Ausnutzung?
Check Point sagt ausdrücklich, dass in den von ihnen ausgewerteten Telemetrie- und Musterdaten keine Belege für eine echte missbräuchliche Verwendung im Sinne der Demonstration gefunden wurden. Das wird als positiver Sicherheitsaspekt gewertet: Wenn die Technik noch nicht in freier Wildbahn angekommen ist, lassen sich Detektion und Härtung eher proaktiv planen.
Gleichzeitig betonen die Forschenden, dass die Veröffentlichung als Threat-Engineering Grundlage dienen kann. Das Ziel ist, dass Sicherheitsteams die beschriebenen Spuren früh erkennen können, bevor Angriffe tatsächlich häufiger auftreten.
Welche Indikatoren (Sysmon/Windows Events) helfen bei der Erkennung
Um potenziellen Missbrauch zu identifizieren, nennt Check Point mehrere Indikatoren, die in der Praxis in Kombination besonders aussagekräftig sein können. Dazu zählen etwa konkrete Sysmon-Events sowie Windows-Event-Patterns. Besonders relevant sind Situationen, in denen ein Verhalten auftritt, das zu BTR.sys passt, aber nicht durch die üblichen Service-Install-Spuren nachvollziehbar dokumentiert ist.
Genannt werden unter anderem:
- Sysmon Event ID 15 (FileCreateStreamHash), wenn der Zielname auf .sys:changelist endet – dabei geht es laut Bericht um den verschlüsselten Konfigurations-Alternate-Data-Stream
- RegistryEvent (Sysmon Event ID 12 oder 13), bei dem ein Service-Key erstellt wird; die Args-Angabe enthält :changelist und Group lautet "Boot Bus Extender". Zusätzlich wird die Abwesenheit eines üblichen Service-Installed-Events als auffällig beschrieben.
- Sysmon Event ID 11 (FileCreate) und Sysmon Event ID 23 (FileDelete), die eine schnelle Erstellung und Entfernung einer Logdatei unter SystemRoot Temp BootClean.log durch den Systemprozess (PID 4) abbilden
- Sysmon Event ID 6 (DriverLoad) direkt gefolgt von Sysmon Event ID 23 (FileDelete), ebenfalls dem Systemprozess (PID 4) zugeordnet – als Fingerprint für eine Live-Ausführung
Für Monitoring-Setups heißt das: Ein einzelnes Signal ist möglicherweise nicht genug. Erst die Kombination aus Registry-Mustern, eventuellen Service-Install-Auslassungen und dem BootClean-Log-Verhalten liefert laut Check Point den stärkeren Verdacht.
Härtung: SeLoadDriverPrivilege gezielt begrenzen
Als primäre Gegenmaßnahme empfiehlt Check Point, die Zuweisung von SeLoadDriverPrivilege restriktiv zu handhaben. Der Gedanke dahinter ist einfach: Wenn die Berechtigung nicht breit vergeben wird, sinkt die Angriffsfläche erheblich, auch wenn der Treiber selbst „von Windows eingebaut“ ist.
Das ist dabei nicht nur ein organisatorischer Schritt. Es wirkt direkt auf die technische Machbarkeit. Wenn Administratorrechte zwar existieren, aber die Treiberlade-Berechtigung nicht verfügbar ist, kann der beschriebene Ablauf nicht wie im Proof-of-Concept ausgeführt werden.
Einordnung in die Entwicklung: bereits frühere Arbeiten zum Treiber
Interessant ist zudem, dass BTR.sys bereits vor Jahren von Forschenden analysiert wurde. Check Point erwähnt einen früheren Befund: In Februar 2021 wurde im Kontext des Treibers eine Privilege-Eskalation beschrieben, die es erlaubte, über einen Hardlink an einer Logpfadstelle beliebige Dateien zu überschreiben. Microsoft habe diese Schwachstelle am 9. Februar 2021 gepatcht.
Die neue Studie verortet das aktuelle Risiko jedoch anders. Statt einer nach außen ausnutzbaren Lücke liegt der Schwerpunkt auf einem Übergang in der Systemarchitektur: Mit vorhandenen Administratorrechten kann die Vertrauensgrenze überschritten werden.
Fazit: BTR.sys Sicherheitssoftware ist ein neuer Fokus für Defender-Schutz
Die Veröffentlichung von Check Point macht deutlich, dass auch legitime, signierte Systemkomponenten Teil eines Angriffspfads werden können, wenn Angreifer bereits über die passenden Privilegien verfügen. BTR.sys Sicherheitssoftware betrifft dabei besonders, weil der Treiber aus dem Defender-Kontext heraus agiert und in einem frühen Boot-Fenster Sicherheitsbausteine entfernen kann, bevor sie sich wirksam schützen.
Für Organisationen heißt das konkret: Detektion anhand der beschriebenen Sysmon- und Registry-Indikatoren aktivieren, prüfen, ob SeLoadDriverPrivilege unnötig verteilt ist, und bei Monitoring-Setups auf Muster achten, die zu „Boot Bus Extender“-Installationsspuren passen. Damit schaffen Sie eine solide Grundlage, um potenzielle Missbräuche früh zu erkennen, bevor die Technik breiter übernommen wird.
Quelle: https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
