Windows Defender ships a kernel driver called BTR.sys, for Boot Time Removal, whose job is to finish deleting malware that survives a normal cleanup. It runs before most of the security stack wakes up, and it takes its orders from an encrypted file sitting in a hidden data stream on disk. On August 20, Check Point researcher Jiri Vinopal published the full reverse engineering of that driver and released a working tool that instructs it to do whatever the operator wants instead.
The tool is called BTR_CLI. It is on GitHub under an MIT licence, with ready-to-run executables for 32-bit and 64-bit Windows.
IntelFusions covered the Black Hat talk this research came from on August 6, when Check Point's public write-up was a summary and left open how much access an attacker needed. The full paper answers that and considerably more.
Fifteen years, one unchanged key
The driver is embedded inside MpEngine.dll and dropped to disk with a randomly generated eight-letter filename only when Defender needs a reboot to finish a removal. It exposes no normal control interface. Instead it reads an encrypted configuration blob from an Alternate Data Stream attached to its own file, a hidden stream named :changelist that does not appear in a directory listing.
Vinopal mapped that format completely, then collected 18 unique Microsoft-signed 64-bit builds of the driver. Every one carried the same hardcoded 256-byte RC4 key, and the transaction format was identical across all of them. The tool was tested from Windows 7 build 7601, released in 2011, through Windows 10 22H2 and up to a fully updated Windows 11 25H2 as of July 2026. It worked everywhere.
Why this one is not BYOVD
Attackers who want kernel access often bring their own vulnerable signed driver and load it, a technique defenders track as BYOVD and increasingly block by blocklisting the driver. That is not what happens here. BTR_CLI extracts the target machine's own BTR.sys out of its local MpEngine.dll, so no foreign binary is introduced at all. Check Point notes the tool carries an embedded fallback copy, and that during testing it never once needed it.
There is also no exploit and no memory corruption involved. The driver is doing precisely what Microsoft designed it to do, for someone who worked out the key. The tool creates a service and loads the driver, which is an administrator-level action, so this is post-compromise tradecraft for switching protection off and persisting rather than a route in. By default it chains an anti-forensics step that deletes its own BootClean.log first, then removes the service key, the driver file and the data streams when it finishes.
The gap between the filesystem and the guards
Check Point calls the interesting part the Golden Window. The tool registers the driver in the load order group named Boot Bus Extender, which is where Defender itself stages it during a legitimate cleanup. That slot runs immediately after the NTFS filesystem comes up. Defender's own filesystem filter is already loaded by then, but other security drivers in lower priority groups are not, so the disk is writable while part of the protection stack has not started.
There is no patch, so watch the artifacts
Nothing here is a vulnerability in the ordinary sense, there is no CVE, and no fix is coming, because from Microsoft's point of view the driver works correctly. What defenders get instead is a documented artifact trail: a randomly named eight-letter .sys file in System32\drivers, a transient service whose Args value points at an Alternate Data Stream rather than a normal file, membership of the Boot Bus Extender group, and BootClean.log going missing. Vinopal also asks how many other signed remediation components carry similar undocumented power.
Read the original research for the full transaction format and the tool.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.