BTR.sys — the Boot Time Removal Tool — is a signed Windows driver embedded inside Microsoft Defender's MpEngine.dll. It exists for a sensible reason: some malware cannot be deleted while Windows is running, so Defender needs something that can remove locked files and registry entries early in the boot sequence, before the things holding them are up.
Jiří Vinopal of Check Point Research took it apart and presented the results at Black Hat USA 2026 and DEF CON 34.
The golden window
The driver's whole purpose is to act in a narrow gap: after the filesystem becomes writable, but before Defender's own user-mode services launch. Vinopal calls it the golden window.
In that gap, nothing has locked itself yet — including Defender. So a driver designed to delete stubborn malware files can be pointed at WdFilter.sys and MsMpEng.exe instead, and they come off the disk before they ever get the chance to defend themselves.
The tool is not being tricked into doing something foreign. It is doing exactly its job, on a different list of files.
The key that has not changed since Windows 7
BTR.sys takes its instructions through a proprietary transaction protocol, and the configuration data is RC4-encrypted.
Vinopal found the 256-byte key is hardcoded, and has been the same in every build since Windows 7. That is roughly 15 years of one static key protecting the instruction channel of a signed kernel driver that deletes files.
His proof of concept, BTR_CLI, extracts the driver from MpEngine.dll, builds correctly encrypted transactions, and installs it as a service by writing directly to the registry — going around the Service Control Manager entirely.
What it can do once loaded
- Delete locked files and directories
- Move files into unrestricted paths, including System32\drivers
- Delete registry keys and values
- Write new registry values of any type
The second bullet is the one that turns this from an anti-EDR trick into something broader. A signed component that will place a file of your choosing into the driver directory is a general-purpose primitive, not just a way to remove antivirus.
Why Microsoft is not patching it
The attack requires an administrator account holding SeLoadDriverPrivilege. Microsoft's position, through MSRC, is that findings resting on pre-existing administrative privilege do not meet the bar for immediate servicing. The research repository states no patch is planned, though Microsoft has not publicly confirmed that phrasing.
That is a defensible line and it is worth understanding rather than dismissing. Once an attacker is administrator with driver-loading rights, a great many things become possible, and Microsoft cannot treat every one of them as a vulnerability without redefining what an administrator is.
The counter-argument is equally real. This is the third time this month we have written about Microsoft's own signed tooling being the instrument: WMIC removed after a decade because criminals used it more than administrators, ShieldBreak going round the Defender patch to reach SYSTEM, and now a Defender driver that will delete Defender. "You already needed admin" explains why it is not a vulnerability. It does not make the box any less removable.
Nobody has used it
Check Point states plainly that across all collected samples and telemetry it saw no evidence of real-world abuse.
Worth holding, and worth not relaxing about — the technique is now documented, presented at two conferences, with a working tool published.
What to do
- Restrict SeLoadDriverPrivilege. This is the primary control and most estates hand it out more widely than they realise.
- Alert on the artefacts Check Point published. Sysmon FileCreateStreamHash events with filenames ending .sys:changelist, and registry events containing :changelist with a Boot Bus Extender group value.
- Watch for services created by direct registry write rather than through the Service Control Manager. That bypass is unusual enough to be worth an alert on its own.
- Treat the loss of Defender at boot as an event. If MsMpEng is not running after a restart, something removed it, and the absence of alerts is the alert.
- Do not rely on a single endpoint agent to notice its own deletion. By construction it will not be there to file the report.
What is not established
- Whether Microsoft will change position. No patch is planned per the research; Microsoft has not stated this publicly.
- Whether the technique is in use. No evidence found as of the August disclosure.
- Which other signed components share the pattern. Nobody has published an equivalent audit.