Defender's Boot Driver Becomes a Kernel Weapon

At Black Hat USA 2026 and DEF CON 34, Check Point Research unveiled a technique that turns a core Windows component — Microsoft Defender's own boot-time remediation driver — into a tool for arbitrary kernel-level file and registry operations. The attack works on systems from Windows 7 through Windows 11 25H2, and it requires no vulnerability, no third-party driver, and no external code.

Jiří Vinopal, a threat researcher and reverse engineer at Check Point Research, presented the findings as a main-stage briefing in Las Vegas and published a research paper alongside a proof-of-concept tool, BTR_CLI, on August 20, 2026. Check Point Research said it found no evidence the technique has been used in real-world attacks.

"During our analysis across all collected samples and telemetry sources, we did not observe evidence of real-world abuse of BTR.sys in the manner demonstrated in this research. This suggests the technique is currently unknown or unused by threat actors, making proactive detection engineering feasible before weaponization appears in the wild,"

— Check Point Research, in the research paper

The Driver That Must Not Be Blocked

The weaponized driver, BTR.sys (Boot Time Removal Tool), is a required Windows component. That means it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control (WDAC) without disrupting Defender itself. Attackers who already have administrator privileges can load this driver to perform operations that would normally require kernel-level access.

BTR.sys is embedded in Defender's MpEngine.dll as the BOOTTIMETOOL resource and is deployed when Defender must finish removing malware after a reboot, deleting files or registry entries that were locked while Windows was running. This design makes the driver available on every Windows installation from version 7 onward.

Reverse-Engineering an Undocumented Protocol

Vinopal reverse-engineered the driver's proprietary, undocumented transaction protocol and found that every configuration blob passed to BTR.sys is RC4-encrypted with a 256-byte key hard-coded in the .rdata section of every BTR.sys build shipped since Windows 7. He verified the key remained unchanged across 18 unique 64-bit versions.

The proof-of-concept tool, BTR_CLI, locates MpEngine.dll under Defender's Definition Updates and extracts the embedded BTR.sys binary. The tool then constructs a valid encrypted transaction and installs the driver as a service via direct HKLM registry writes using Type=1, Start=1, and Group="Boot Bus Extender". This method bypasses the Service Control Manager entirely and generates no Windows Event ID 7045 (Service Installed) entry.

Executing During the Golden Window

When loaded, BTR.sys executes the queued operations from Ring 0, attributed in telemetry to the System process (PID 4). It can delete locked files and directories, move files to unconstrained paths including System32\drivers, delete registry keys and values, and write new registry values of any type. A second trigger mode schedules those operations for the next reboot.

The driver then executes during what Vinopal calls the "golden window," the interval after the filesystem becomes writable but before Defender's user-mode services have started. This allows BTR.sys to physically remove security binaries such as WdFilter.sys and MsMpEng.exe before they can lock themselves.

A live demonstration at Black Hat showed BTR_CLI deleting the entire Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection active. Exploitation requires an administrator account with SeLoadDriverPrivilege, which BTR_CLI auto-enables for accounts that already hold it.

Not a Vulnerability, But an Architect

Unlike attacks that rely on the bring your own vulnerable driver technique, which depend on known-vulnerable third-party signed drivers that can be added to blocklists, the BTR Reforged technique uses a driver built into every Windows installation from Windows 7 onward. This makes it impossible to block without breaking Defender's own functionality.

"The issue is not a vulnerability in the traditional sense, but rather an architectural trust boundary that can be crossed if an attacker already has administrative privileges. Following responsible disclosure, MSRC confirmed that these findings do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges (SeLoadDriverPrivilege)," Check Point Research said in the paper.

Vinopal's GitHub repository for BTR_CLI adds that "No patch is planned," a characterization Microsoft has not confirmed publicly.

A Five-Year-Old Precedent

This is not the first time BTR.sys has drawn scrutiny. In February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a privilege escalation vulnerability that allowed a local non-administrator to overwrite arbitrary files by placing a hard link at the driver's log path. Microsoft patched CVE-2021-24092 on February 9, 2021.

"We assume that this vulnerability remained undiscovered until now because the driver is normally not present on the hard drive but rather dropped and activated when needed (with a random name) and then purged away," Kasif Dekel said in the SentinelLabs disclosure.

The use of a built-in Windows driver as a kernel offensive primitive, rather than a third-party vulnerable one, was previously demonstrated in the context of FIN7's AvNeutralizer, which weaponized the Windows ProcLaunchMon.sys driver alongside the Process Explorer driver to tamper with endpoint security software.

A Suspicious Incident Led to Discovery

Check Point Research said the investigation that produced these findings had an unusual origin. "This research originated during an incident response investigation involving a compromised system, where certain endpoint telemetry appeared suspicious but was ultimately traced back to legitimate Windows Defender remediation activity," Check Point Research said in the paper.

The researchers also identified specific indicators of potential BTR.sys abuse that defenders can monitor. These include:

• Sysmon Event ID 15 (FileCreateStreamHash) where the target filename ends in .sys:changelist, capturing the encrypted configuration Alternate Data Stream written to the driver file
• RegistryEvent (Sysmon Event ID 12 or 13) creating a service key whose Args value contains :changelist and whose Group is "Boot Bus Extender," especially when unaccompanied by a Windows Event ID 7045 (Service Installed) entry
• Sysmon Event IDs 11 (FileCreate) and 23 (FileDelete) logging the rapid creation and deletion of \SystemRoot\Temp\BootClean.log by the System process (PID 4), a log path hardcoded in the driver that fires regardless of the caller
• Sysmon Event ID 6 (DriverLoad) immediately followed by Sysmon Event ID 23 (FileDelete) attributed to the System process (PID 4), the kernel-mode execution fingerprint of a live BTR.sys trigger

Check Point Research also recommends restricting the assignment of SeLoadDriverPrivilege as the primary hardening control.

BTR_CLI is available at github.com/Dump-GUY/BTR_CLI under the MIT license, with prebuilt x64 and x86 binaries attached to the repository's releases.

Why It Matters for Windows Security

This research shows that Microsoft's own security tooling can be turned against itself, not through a flaw but through the very privileges that administrators hold. For organizations, the implications are significant: if attackers gain administrative access, they can now remove the endpoint protection that might otherwise catch them, and the attack leaves no standard service-installation event for defenders to see.

While the technique requires pre-existing admin rights, the fact that it uses a trusted Microsoft driver means that security products may find it difficult to detect or block without breaking their own integration with Defender. The researchers suggest that proactive detection based on the identified Sysmon events could mitigate the risk before real-world weaponization occurs, but this depends on defenders implementing those controls now, rather than waiting for a patch that may never come.