Defender's Own Boot Driver Can Be Turned Into an EDR-Killing Primitive

At Black Hat USA 2026 and DEF CON 34, Check Point researcher Jiří Vinopal presented "BTR Reforged," the first full reverse engineering of BTR.sys — the Boot Time Removal Tool driver Microsoft Defender uses to clean up locked malware files and registry entries that it couldn't remove during a normal scan. The technique works against every Windows release from Windows 7 through Windows 11 25H2, exploits no software flaw, and imports no external driver — it simply repurposes a component that is already signed by Microsoft and already on the machine.

What BTR.sys normally does

BTR.sys is invoked by Defender's MpEngine.dll when a scan finds a threat it cannot delete immediately — typically because a file or registry key is locked by a running process. Defender queues the removal, and on the next reboot BTR.sys runs early enough in the boot sequence to delete or move the file, or write the registry change, before anything else can interfere with it.

How the abuse works

Vinopal reverse-engineered BTR.sys's proprietary transaction format and found it protected by a hard-coded 256-byte RC4 key that has stayed identical across 18 analyzed 64-bit builds spanning more than 15 years of Windows releases. With the key known, an attacker who already holds SeLoadDriverPrivilege — a privilege automatically available to qualifying administrator accounts — can craft their own encrypted transaction list, install BTR.sys as a service via direct registry edits that bypass the Service Control Manager, and queue arbitrary file deletions, file moves, or registry writes for the next boot.

The payoff is timing. BTR.sys is registered as a SERVICE_SYSTEM_START driver in the "Boot Bus Extender" load-order group, so it runs once the filesystem is writable but before most user-mode security agents initialize — Check Point measured roughly a 34-second gap before Defender's own MsMpEng.exe process starts. In that "golden window," the driver can delete or relocate EDR and antivirus binaries, or rewrite their service registry configuration, before those products have a chance to protect themselves.

Why there's no CVE or patch

Check Point reported the technique to MSRC on 21 February 2026. Microsoft's position is that this is an architectural trust boundary, not a vulnerability: the attacker already needs local administrator rights and SeLoadDriverPrivilege to load any kernel driver, and Windows has never treated an already-elevated attacker's ability to load signed code as a servicing bug. No CVE was assigned and no patch is planned.

That framing is defensible on Microsoft's terms, but it matters operationally: this isn't a traditional bring-your-own-vulnerable-driver (BYOVD) scenario where defenders can blocklist a known-bad third-party driver hash. BTR.sys is Defender's own signed binary, present on essentially every Windows endpoint, so any driver-hash or publisher-based allowlist will pass it by default.

What defenders should actually watch

Check Point found no evidence of real-world abuse at publication and published concrete detection guidance rather than just a warning. Sysmon-based signals to hunt for include:

• Event ID 15 — creation of a :changelist alternate data stream on a .sys file, the format BTR.sys's transaction queue uses
• Event ID 23 — the System process (PID 4) deleting known security-product binaries
• Event ID 6/12/13 — DriverLoad events or service-registry keys placing a driver in the "Boot Bus Extender" group outside the normal Service Control Manager path

The one concrete hardening control Check Point recommends is restricting who holds SeLoadDriverPrivilege in the first place, since every step of the attack chain depends on it.

Why it matters

This is another entry in a growing pattern: attackers don't need to smuggle in a vulnerable driver when the operating system already ships trusted components with enough privilege to do the job. For red teams and threat hunters, the practical lesson is the same either way — detection has to be behavioural (unusual driver-load timing, ADS creation, boot-time file deletion of security binaries) rather than identity-based (is this driver signed, is this driver on a blocklist), because the driver in question will always pass an identity check.