Microsoft's Own Defender Driver Can Be Turned Against Itself to Wipe Security Software
Check Point Research has published a technique that turns Microsoft Defender's own boot-time driver into a kernel-level deletion tool capable of wiping security software from Windows machines. No third-party driver required. No software vulnerability exploited. Just Windows doing exactly what it was designed to do, pointed in the wrong direction.
The driver in question is BTR.sys, short for Boot Time Removal Tool. It ships as an embedded resource inside Defender's MpEngine.dll and exists for a mundane purpose: finishing malware removal jobs after a reboot, when certain files and registry entries are no longer locked by running processes. Legitimate, signed, and present on every Windows installation from Windows 7 through Windows 11 25H2.
That last point is the problem. Because BTR.sys is a required Defender component, Microsoft cannot add it to the Vulnerable Driver Blocklist or block it via Windows Defender Application Control without breaking Defender itself. It is, architecturally speaking, untouchable.
Check Point researcher Jiří Vinopal reverse-engineered the driver's undocumented transaction protocol and found that configuration blobs passed to BTR.sys are RC4-encrypted using a 256-byte key hard-coded in the .rdata section of every BTR.sys build released since Windows 7. He verified the key was unchanged across 18 distinct 64-bit versions. That is not a great look.
Vinopal presented the findings at Black Hat USA 2026 and DEF CON 34, accompanied by a proof-of-concept tool called BTR_CLI. The tool extracts BTR.sys from MpEngine.dll, constructs a valid encrypted transaction, and installs the driver as a service via direct registry writes rather than through the Service Control Manager. The practical consequence of that last detail: no Windows Event ID 7045 is generated. The installation is essentially invisible to standard logging.
Once loaded, BTR.sys runs at Ring 0, attributed in telemetry to the System process under PID 4. From there it can delete locked files and directories, move files into System32\drivers, and read, write, or delete registry entries. A second mode queues those operations for the next reboot.
The timing matters. Vinopal describes a "golden window" during boot when the filesystem is writable but Defender's user-mode services have not yet started. BTR.sys runs in that gap, which means it can physically remove files like WdFilter.sys and MsMpEng.exe before they have a chance to lock themselves. A live demo at Black Hat showed the entire Defender stack being deleted from a fully patched Windows 11 25H2 machine with Tamper Protection enabled.
Exploitation requires an administrator account with SeLoadDriverPrivilege. BTR_CLI auto-enables the privilege for accounts that already hold it. So this is not a route to privilege escalation. It is a route for someone who already has admin access to quietly remove endpoint security tools without triggering the usual alerts.
Microsoft's Security Response Center reviewed the disclosure and concluded the findings do not meet the bar for immediate patching, on the grounds that administrative privileges are a prerequisite. Vinopal's GitHub repository notes bluntly that no patch is planned, though Microsoft has not publicly confirmed that characterisation.
This is not the first time BTR.sys has attracted scrutiny. Back in February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a privilege escalation flaw in the same driver that let a non-administrator overwrite arbitrary files via a hard link at the driver's log path. Microsoft patched that one. The current technique is a different beast entirely: not a bug, but a deliberate misuse of legitimate functionality.
Check Point notes the research began during an incident response engagement, where suspicious telemetry turned out to be legitimate Defender remediation activity. That detail alone is worth sitting with for a moment. Security analysts are now in a position where kernel-level file deletion attributed to PID 4 might be either Windows cleaning up malware or an attacker using Windows to clean up their tracks.
The team found no evidence of real-world abuse so far, which at least gives defenders a window to get detection in place before someone else figures this out independently.
For detection, Check Point recommends watching for Sysmon Event ID 15 where the target filename ends in .sys:changelist, registry events creating a service key with a Group value of "Boot Bus Extender" and an Args value containing :changelist, especially without a corresponding Event ID 7045. Rapid creation and deletion of \SystemRoot\Temp\BootClean.log by PID 4 is another signal, as is a DriverLoad event immediately followed by a FileDelete attributed to the System process.
Restricting SeLoadDriverPrivilege is recommended as the primary hardening measure.
BTR_CLI is available on GitHub under the MIT licence with prebuilt x64 and x86 binaries.