TL;DR - Check Point Research published BTR Reforged on 20 August: BTR.sys, the signed Boot Time Removal Tool driver inside Microsoft Defender, can be invoked by any local admin holding
SeLoadDriverPrivilegeto delete arbitrary files and registry values at the next boot, before defences load. No flaw is exploited, there is no CVE, MSRC will not service it, and the driver cannot be blocklisted without breaking Defender. A live demo deleted the entire Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection active. What you need to do: deploy the four Sysmon conditions, restrictSeLoadDriverPrivilegeto a documented minimum, and hunt the last 30 days for the stealth install.
By The Numbers
| Number | Context |
|---|---|
| 17 years | BTR.sys has shipped inside Windows since Windows 7 released in 2009 |
| 18 | unique 64-bit driver builds Check Point verified all carry the same hardcoded RC4 key |
| 0 | software flaws exploited, CVEs assigned, or patches on the way |
| 1 | registry service entry written straight to HKLM, generating no Event ID 7045 |
| 4 | Sysmon conditions Check Point published so you can detect it |
| 0 | evidence of real-world abuse observed so far, per Check Point telemetry |
Friday morning, Adelaide, coffee poured, and the r/netsec threads were all pointing at one thing: BTR Reforged, the Check Point Research paper presented at Black Hat USA 2026 and DEF CON 34, with a working proof-of-concept called BTR_CLI. The subject: BTR.sys, a Microsoft-signed kernel driver inside Defender. I read it twice. Once for the shock, once with the registry editor open.
What BTR.sys is, and why this is not a CVE
Defender needs a way to remove malware that has locked itself into the running Windows session. Normal APIs cannot touch files that are in use, so Defender embeds a small kernel driver inside MpEngine.dll as a resource named BOOTTIMETOOL. When a scan finds something it cannot delete while the OS runs, it schedules the cleanup for the next boot, drops the driver to disk under a random filename, and lets it delete the locked files and registry keys from Ring 0 before purging it again. That design has been in place since Windows 7.
Researcher Jiří Vinopal reverse-engineered the driver's proprietary, undocumented transaction protocol. Every configuration blob passed to BTR.sys is RC4-encrypted with a 256-byte key hardcoded in the driver's .rdata section, and Vinopal verified the same key across 18 unique 64-bit builds going back to Windows 7. One key, 17 years.
As The Hacker News reporting puts it, BTR.sys is a required Windows component, so it cannot be added to the Vulnerable Driver Blocklist or blocked via WDAC without disrupting Defender itself. MSRC confirmed after responsible disclosure that the findings do not meet the criteria for immediate servicing, because the technique relies on pre-existing administrative privileges. The fix has to land in the privilege model and the audit log rather than in a patch.
How the technique actually works
The attack has three stages, and all of them require a local administrator who already holds SeLoadDriverPrivilege. The PoC auto-enables that privilege for accounts that already have it.
1. Forge and install. BTR_CLI locates MpEngine.dll under Defender's Definition Updates, extracts the embedded driver, and builds a valid encrypted transaction naming whatever files and registry keys the attacker chooses. It then registers the driver as a boot service by writing directly into HKLM\SYSTEM\CurrentControlSet\Services\: Type=1 (kernel driver), Start=1 (boot start), Group="Boot Bus Extender" (loads early, before Defender). The writes go straight to the hive rather than through the Service Control Manager, so no Event ID 7045 fires and standard service monitoring misses it. A second trigger mode schedules the operations for the next reboot.
2. Reboot into the golden window. Vinopal's term: the filesystem is writable, but Defender's user-mode services have not started yet. From Ring 0, attributed to the System process (PID 4), the driver deletes locked files and directories, moves files to unrestricted paths including System32\drivers, deletes registry keys and values, and writes new registry values of any type.
3. Execute. Point the queue at WdFilter.sys and MsMpEng.exe and the endpoint stack is deleted before it can lock itself. In the live Black Hat demo, BTR_CLI removed the entire Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection active. The same driver ships on every Windows version from 7 through 11 25H2, so the fleet to think about is all of it.
One honest caveat before you forward this to your board: this is a post-exploitation move, the last step of an intrusion. If your response is "so we're fine, they need admin first", check how many helpdesk and developer accounts sit in local Administrators. Then keep reading.
The four Sysmon conditions that catch it
No patch means detection is the whole game. Check Point published four conditions, all buildable in Sysmon, and this is the part worth screenshotting:
| Signal | Why it fires |
|---|---|
Event ID 15 (FileCreateStreamHash), target filename ending .sys:changelist | The encrypted configuration written as an alternate data stream on the driver file |
Event ID 12 or 13 (RegistryEvent), service key with :changelist in Args and Group "Boot Bus Extender", with no Event ID 7045 anywhere near it | The stealth service install |
Event IDs 11 and 23, rapid create then delete of \SystemRoot\Temp\BootClean.log by PID 4 | The log path is hardcoded in the driver and fires regardless of who called it |
| Event ID 6 (DriverLoad) immediately followed by Event ID 23 (FileDelete), both PID 4 | The kernel-mode fingerprint of a live trigger |
That third one is my favourite. The driver cannot help writing its own boot log, attacker or otherwise. It is a tell baked into the binary. A single event is noisy, since every legitimate boot-time service runs as PID 4. The pairs, on the same host, close together in time, are the candidates.
If your detection pipeline is thin and you want a starting point for what good endpoint monitoring looks like, Get The Free Guide →. No cost, no calls.
The ANZ IT-pro response playbook
What I would do this week, in order. None of it requires a new vendor.
Day 1: enable Sysmon across the Windows fleet
The single biggest fix. Without Sysmon you have no signal on either the trigger or the execution. The SwiftOnSecurity sysmon-config repository is the maintained baseline. Push it via Intune, GPO, or your current management tool, forward logs to your SIEM or Sentinel, and make sure the four conditions above are covered.
Day 2: tighten SeLoadDriverPrivilege
This is Check Point's own recommendation and it is the cheapest fix. In Group Policy, navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, find Load and unload device drivers, and replace the default list with a named allowlist of the service accounts that actually need it. Backup agents, some DLP products, and a handful of management agents do. Most do not. The policy reference is on Microsoft Learn.
Day 3: hunt the last 30 days
Run three queries against your SIEM or Defender XDR telemetry, and save the output as evidence.
Query 1: boot-group driver loads. Sysmon Event ID 6 where the service group is Boot Bus Extender, last 30 days. The driver drops with a random filename, so hunt on the group and the follow-on behaviour rather than a filename.
Query 2: service registrations with no matching 7045. Sysmon Event ID 12/13 for a service key whose Group is Boot Bus Extender, joined against Windows Event ID 7045 on the same host in the same window. Any registration that did not generate a 7045 is suspect.
Query 3: the PID 4 pair. Sysmon Event ID 6 followed by Event ID 23 on the same host inside a short window, plus any appearance of \SystemRoot\Temp\BootClean.log created and deleted by PID 4 outside known Defender remediation. One hit on a host that is not your Defender management server is a credential rotation and a host rebuild. Hits across multiple hosts is a full incident.
Day 4: watch the Boot Bus Extender write in change control
The trigger is a single registry write, and most change control watches Service Control Manager calls. Add a watch on new subkeys under HKLM\SYSTEM\CurrentControlSet\Services\ whose Group value is Boot Bus Extender. Legitimate use of that group is narrow, so the audit should fire infrequently.
If you cannot drop SeLoadDriverPrivilege
Some environments cannot tighten the privilege because backup agents, disk encryption, or legacy management tools hold it. Three compensating controls:
- Move to LAPS-managed local admin passwords. A compromised local-admin credential is the prerequisite. Microsoft LAPS rotates those passwords automatically, turning one static shared password into tightly rotated individual credentials.
- Adopt the recommended driver block rules in WDAC. BTR.sys is Microsoft-signed so WDAC will not stop it, but the Microsoft Recommended Driver Block Rules close off the third-party vulnerable drivers an attacker might chain alongside it.
- Tier your admin accounts. Every account pulled out of local Administrators is one fewer BTR Reforged candidate. This attack turns privilege hygiene into the control that matters.
These controls do not remove the technique. They raise its cost from "any compromised local-admin credential" to "compromised credential plus layered bypasses", and each layer is friction the attacker pays before reaching your EDR.
The second wave of driver-as-offensive-primitive
The Check Point paper sits on top of a pattern. SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092 in this same driver in February 2021, a privilege escalation via a hard link on the driver's log path, patched 9 February 2021. Dekel guessed the flaw hid for years because the driver is rarely present on disk, only dropped when needed. Second look in five years, second finding.
The other reference point is FIN7's AvNeutralizer, which weaponised the built-in Windows ProcLaunchMon driver to tamper with endpoint security software. Same gap both times: the blocklist model was built for third-party vulnerable drivers, and it cannot cover first-party weaponisable ones without breaking the functionality the driver exists to provide.
The origin story matters. The research started during an incident response where telemetry looked suspicious and turned out to be legitimate Defender remediation. The technique fell out of asking what else that driver could do. Check Point has "not observed evidence of real-world abuse of BTR.sys" yet, which is a gift: a rare window to build the detections before ransomware crews finish reading the paper. With BTR_CLI under an MIT licence on GitHub, the window is short.
FAQ: BTR.sys questions ANZ IT-pros actually ask
Does Tamper Protection stop BTR.sys? No. The Black Hat demo deleted the full Defender stack from a Windows 11 25H2 endpoint with Tamper Protection active, because the deletions run during boot, before Defender's user-mode services start.
Can I block BTR.sys with WDAC or the Vulnerable Driver Blocklist? No. BTR.sys is a required Windows component and cannot be blocked without disrupting Defender itself. The audit log and the privilege model are the right controls.
Why does Microsoft not patch this? MSRC's position, per Check Point: the findings do not meet the criteria for immediate servicing because the technique relies on pre-existing administrative privileges. The fix is endpoint configuration, not the driver.
Which Windows versions are affected? Windows 7 through Windows 11 25H2, per the research. Domain controllers and file servers are higher-value targets, so audit servers on the same events.
Is this the same as the August Patch Tuesday driver bug? No. CVE-2026-68820 was a patchable driver flaw and it is fixed. BTR.sys involves no flaw, so there is nothing to patch. I covered the difference in the August Patch Tuesday rundown.
Further Reading
- BTR Reforged: Weaponizing Defender's Remediation Driver as a Kernel Operation Primitive (Check Point Research, Aug 2026) - the original disclosure paper
- Microsoft Defender's Own Driver Can Be Weaponized to Delete Security Software at Boot (The Hacker News, 21 Aug 2026) - the cleanest public writeup, with the four Sysmon conditions
- BTR_CLI proof-of-concept tool (GitHub, MIT licence)
- Microsoft patches max severity code execution, privilege escalation flaws (BleepingComputer, 21 Aug 2026) - what Microsoft did patch the same week
- Microsoft Recommended Driver Block Rules (Microsoft Learn)
- ACSC Essential Eight (ACSC) - the ANZ baseline this hardening maps to
- Patch Tuesday August 2026: 398 fixes, one driver bug in use (SecureInSeconds) - the patchable driver bug, for contrast
- MFA fatigue: the 30-day playbook for ANZ SMB IT-pros (SecureInSeconds) - the credential-side pairing for the trigger write
If you run a Windows fleet with Defender, forward this to the person who owns the endpoint policy. The Sysmon rollout takes a day. The SeLoadDriverPrivilege review takes an afternoon. Both are cheaper than finding the trigger write in a forensic review. Join the Aussies and Kiwis who get one 5-minute security briefing every Friday. Get The Free Guide →
Mathew Clark Founder, SecureInSeconds Currently: counting which service accounts hold SeLoadDriverPrivilege and bracing for the list.
