Microsoft Defender eigen driver misbruikt voor sabotage

Een nieuwe onderzoeksbevinding zet Windows-beveiliging opnieuw op scherp. Check Point Research beschrijft een techniek die de Microsoft Defender eigen driver inzet om tijdens het opstartproces arbitraire acties op kernel-niveau uit te voeren. Daarbij richt de werkwijze zich niet op het “breken” van een softwarefout, maar op het overschrijden van een architectuurgrens: een misbruiker met voldoende rechten kan functies van een legitiem Defender-component gebruiken voor sabotage.

Volgens het onderzoek is er tot nu toe geen bewijs gevonden voor misbruik in de praktijk. Dat neemt niet weg dat het concept dwingt tot een herbeoordeling van hardeningmaatregelen, vooral rondom adminrechten en het beperken van specifieke privilege-toewijzingen.

Wat is de Microsoft Defender eigen driver BTR.sys?

De kern van de techniek is de driver BTR.sys, ook wel aangeduid als de Boot Time Removal Tool. Dit is geen willekeurige third-party module, maar een vereiste Windows-component die Defender nodig heeft om na een reboot beveiligingsgerelateerde opschoning af te ronden.

De driver zit ingebed in Defender-bibliotheekbestanden. In het onderzoek wordt beschreven dat BTR.sys is opgeslagen in MpEngine.dll als een resource (BOOTTIMETOOL) en pas wordt ingezet wanneer Defender na een herstart malwareverwijdering moet afronden die geblokkeerd was terwijl Windows actief draaide.

Waarom dit niet past in het bekende “kwetsbaarheid”-verhaal

Het opvallende aan deze bevinding is dat er geen traditionele exploit van een bug wordt beschreven. Er is volgens Check Point geen softwarefout nodig en er wordt ook geen externe driver “ingeladen” vanaf buiten de machine.

Daardoor valt de aanpak lastig te plaatsen in de gebruikelijke categorieën zoals “weaponized vulnerable driver” waarbij aanvallers misbruik maken van bekende kwetsbare, door derden ondertekende drivers die je kunt blokkeren. Omdat de driver onderdeel is van het Defender-ecosysteem, kan je de driver volgens het onderzoek niet zomaar zonder gevolgen uitsluiten via WDAC of een reguliere blocklist, omdat dat Defender zelf zou verstoren.

Wat kan BTR.sys precies doen op kernel-niveau?

Wanneer de driver geladen is, kan hij een wachtrij met operaties uitvoeren uit Ring 0. Het onderzoek beschrijft dat die operaties worden geassocieerd met het System-proces (PID 4), waardoor de activiteit plausibel kan lijken binnen Windows-telemetrie.

Concreet noemt Check Point de volgende typen acties:

• Het verwijderen van bestanden en mappen die vergrendeld zijn
• Het verplaatsen van bestanden naar onbeperkte locaties, inclusief System32\drivers
• Het verwijderen van registry-sleutels en -waarden
• Het wegschrijven van nieuwe registry-waarden van uiteenlopende typen

Daarnaast is er een tweede triggermodus die de operaties plant voor de volgende herstart. Daarmee kan de aanvaller timing beïnvloeden: niet alleen wat er gebeurt, maar ook wanneer.

Het “golden window”: verwijderen voordat Defender zijn services start

In de uitleg van de onderzoekers wordt een specifiek tijdvenster aangehaald dat belangrijk is voor effect. Check Point noemt dit de “golden window”: de periode nadat het bestandssysteem beschrijfbaar wordt, maar voordat de Defender-onderdelen in user-mode daadwerkelijk zijn opgestart.

In die korte fase kan BTR.sys fysiek beveiligingsbestanden verwijderen voordat ze zichzelf kunnen vergrendelen. In een live demonstratie bij Black Hat werd bijvoorbeeld de volledige Defender-stack weggehaald op een up-to-date Windows 11 25H2-systeem, zelfs met Tamper Protection actief.

Hoe wordt de techniek technisch opgezet?

De onderzoekers beschrijven ook hoe een proof-of-concept tool (BTR_CLI) de embedded driver kan reconstrueren en uitvoeren.

Volgens het onderzoek vindt BTR_CLI MpEngine.dll onder Defender Definition Updates, en haalt de ingebedde BTR.sys-binaire data eruit. Vervolgens bouwt de tool een geldige, versleutelde transactie.

Belangrijk detail: elke configuratieblob die aan BTR.sys wordt doorgegeven, wordt RC4-versleuteld met een sleutel die hard-coded in de driver zou zijn opgeslagen. Het onderzoek stelt dat deze sleutel hetzelfde blijft in meerdere 64-bit builds die sinds Windows 7 zijn geleverd, en noemt daarbij achttien versies.

Service-installatie zonder standaard Service Control Manager

Voor het plaatsen en registreren van de driver beschrijft Check Point een methode die de traditionele Service Control Manager omzeilt. In plaats daarvan wordt de driver als service geïnstalleerd via directe registry-writes naar HKLM met instellingen zoals Type=1, Start=1 en Group="Boot Bus Extender".

Door die aanpak zou er volgens het onderzoek geen Windows Event ID 7045 worden gegenereerd, wat het ontdekken van deze stap lastiger kan maken met alleen die standaardmelding.

Benodigde rechten: de aanval start niet vanaf “niets”

Om BTR.sys effectief te kunnen misbruiken, is een administrator-account vereist met SeLoadDriverPrivilege. De proof-of-concept-tool zou dat privilege automatisch inschakelen voor accounts die het al bezitten.

Dat onderscheidt deze techniek van aanvallen die leunen op een keten van misbruik via al bekende vulnerable third-party drivers. Check Point positioneert het daarom eerder als een trust boundary die kan worden overbrugd zodra een aanvaller al adminrechten heeft.

Zijn er al aanvallen gezien?

Check Point geeft aan geen aanwijzingen te hebben gevonden dat deze werkwijze al in echte aanvallen is gebruikt. De onderzoekers stellen dat de techniek waarschijnlijk nog onbekend of ongebruikt is door threat actors, waardoor voorafgaande detectie engineering mogelijk is.

Dat is positief, maar het betekent ook dat verdedigers nu nog in de gelegenheid zijn om signalen te zoeken en maatregelen te nemen voordat het concept breder wordt overgenomen.

Detectie: welke signalen kunnen op BTR.sys-abuse wijzen?

Om BTR.sys-misbruik te signaleren, noemt Check Point specifieke Sysmon- en Windows-event condities. De lijst is gericht op het vinden van een combinatie van:

• het snel maken en verwijderen van verdachte bestanden
• registry- of service-achtige sporen die passen bij Group “Boot Bus Extender”
• driverload en directe opruiming door het System-proces

Voorbeelden die in het onderzoek terugkomen:

• Sysmon Event ID 15 (FileCreateStreamHash) waarbij de bestandsnaam eindigt op .sys:changelist
• Sysmon Event ID 12 of 13 (RegistryEvent) bij het aanmaken van een service key waarbij de Args waarde :changelistand bevat en Group "Boot Bus Extender"
• Sysmon Event IDs 11 en 23 voor snelle creatie en verwijdering van een logpad zoals \SystemRoot\Temp\BootClean.log door System
• Sysmon Event ID 6 (DriverLoad) direct gevolgd door Sysmon Event ID 23 (FileDelete), ook toegeschreven aan System (PID 4)

Daarnaast raadt het onderzoek aan om extra te letten op dergelijke service-registraties die niet worden vergezeld door Windows Event ID 7045.

Hardening: beperk SeLoadDriverPrivilege

Als primaire hardeningmaatregel adviseert Check Point om het toekennen van SeLoadDriverPrivilege te beperken. Dat komt overeen met het idee dat deze techniek vooral “haalbaar” is zodra een aanvaller al administratorrechten en het relevante privilege heeft.

Concreet betekent dit voor veel organisaties: controleer wie op adminniveau werkt, welke accounts dat privilege daadwerkelijk hebben en of die toegang nodig is voor hun rol. Minimaliseer privileges en voorkom dat brede administratorrechten ongecontroleerd worden toegekend.

Wat betekent dit voor jouw security-positie?

Deze bevinding laat zien hoe verdediging kan worden ondermijnd wanneer een legitiem onderdeel van het securitylandschap als uitvoeringsmechanisme wordt ingezet. Het probleem zit niet in een “standaard kwetsbaarheid” die je met één patch-lineaire regel oplost, maar in de combinatie van architectuur, vertrouwen en rechten.

Daarom is het verstandig om je aanpak te verbreden naar:

• rechtenbeheer (met name privilege-toewijzing)
• detectie op gedrag: driverload, snelle file/registry-acties en timing rond boot
• telemetrie-correlatie (bijv. Sysmon-events combineren met het ontbreken van specifieke service-install events)

Als je ook interesse hebt in hoe threat actors beveiligingslagen bij opstarten kunnen beïnvloeden, past dit onderwerp inhoudelijk bij eerdere analyses over misbruik rond signed components en kernel-impact. Bijvoorbeeld:

• Isolated-vm kwetsbaarheid: ontsnapping en RCE-risico
• Zombie Card-aanval: zo werkt contactloze fraude

(Deze links zijn bedoeld als achtergrond op het bredere thema van misbruik en detectie; voor BTR.sys zijn de hierboven genoemde Sysmon- en eventcondities de kern.)

Samenvatting

Check Point Research beschrijft hoe de Microsoft Defender eigen driver BTR.sys kan worden ingezet om bij boot-time beveiligingssoftware te verwijderen via arbitraire kernel-level file en registry operations. De techniek vereist geen externe kwetsbare driver en hangt niet af van een klassieke softwarefout, maar van adminrechten met SeLoadDriverPrivilege.

Hoewel er geen bewijs is van real-world misbruik, liggen de belangrijkste lessen al klaar: beperk privilege-toekenning, bouw detectie op gedrag en corrigeer je monitoring met aandacht voor specifieke Sysmon/Windows-eventpatronen rond het opstartproces.

Bron: https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html