Defender's Own Boot Driver Can Kill Security Software

Check Point Research published a detailed technical disclosure Thursday showing that BTR.sys — the Boot Time Removal Tool driver bundled with Microsoft Defender and legitimately signed by Microsoft — can be repurposed to delete arbitrary files and manipulate registry entries at the kernel level, before the operating system has finished loading. Every Windows version from 7 through 11 25H2 is in scope. No software flaw is exploited; no external driver is introduced. The driver is already there, already signed, already trusted.

It is the kind of finding that tends to age well, in the wrong direction.

What BTR.sys actually does

BTR.sys exists for a reason. At boot time, when the OS is still coming up and most user-space processes haven’t started, it gives Defender a mechanism to remove stubborn malware that locks or re-registers itself during normal operation — rootkits and persistent implants that would otherwise outlast any user-mode cleanup attempt. The driver runs with kernel privileges, it runs before most security software has had a chance to initialize, and it carries a Microsoft certificate. That combination makes it effective at its intended job.

It also makes it effective at unintended ones. Check Point’s research demonstrates that these same capabilities — kernel-level file deletion, registry manipulation, pre-boot execution — can be turned against the security stack itself. An attacker who reaches that point in the OS startup sequence, with sufficient privilege to queue work for the driver, can use Microsoft’s own tooling to remove endpoint protection, tamper with security logs, or strip the environment before any defender-side visibility is possible.

No CVE accompanies the research. That’s accurate: there’s no code flaw here to patch. BTR.sys is doing exactly what it was designed to do.

The pattern it fits

Living-off-the-land techniques have been the dominant theme in endpoint evasion for several years precisely because the alternative — importing a malicious driver from outside the machine — triggers signature detection, code-signing checks, Driver Signature Enforcement, and Secure Boot measurements. Windows’ trust hierarchy is robust against foreign code. It is less robust against a trusted component being handed a different task list.

This disclosure sits alongside a body of similar findings. In the ransomware space, Akira was observed disabling EDR by forcing a Safe Mode reboot, removing the security product from normal execution context without touching the product’s files directly. Microsoft itself acknowledged this class of threat when it removed WMIC from Windows 11 to close a long-running abuse path — a defensive move that took years longer than most defenders would have liked. Separately, a pair of Defender engine vulnerabilities under the ShieldBreak label (August 15, August 12) showed that the protection surface around Defender is actively targeted — not just as software to evade, but as a vehicle to exploit.

BTR.sys is different from those because the path to abuse requires no vulnerability at all. It’s operational, not exploitable in the conventional sense. That’s what makes it a harder defensive problem.

What defenders can do now

Microsoft has not announced any mitigation or behavioral change to BTR.sys in response to this disclosure. Check Point’s publication follows a responsible disclosure process, so the research will be worth reading in full once available.

In the interim, a few things are worth thinking through:

• Boot integrity and ELAM. Early Launch Anti-Malware (ELAM) policies and Measured Boot with TPM attestation create a recorded baseline of what runs at boot, which is precisely when BTR.sys operates. If that logging is not already centralized and monitored, it should be.
• Privilege access. Queuing work for a boot-time driver requires elevated access. Credential hygiene and robust privileged-access controls don’t block the technique, but they raise the bar for reaching the point where it’s usable.
• Behavioral detections. Endpoint telemetry that tracks unexpected BTR.sys activations — outside of Defender’s own remediation workflow — may surface misuse. This is vendor-specific; check with your EDR provider on coverage.

The deeper mitigation is one that Windows’ architecture makes genuinely difficult: distinguishing legitimate BTR.sys invocations from weaponized ones, when the driver itself can’t tell the difference between what it was told to delete and what it ought to delete. That’s a problem the signed-driver trust model wasn’t built to solve.

The longer view

The security software stack — the very thing organizations rely on to detect intrusions — has become a target worth studying carefully. That’s true not just because attacking it is strategically valuable, but because in many cases it presents a larger attack surface than the underlying OS, with kernel access that the OS itself now guards more carefully. The last few months of Microsoft-adjacent research have made this pattern hard to ignore.

BTR.sys is a well-designed boot-time remediation tool. It is also, as of Thursday, one more entry in a growing list of legitimate Windows components whose capabilities work just as well on behalf of an attacker. The list keeps getting longer. The response time keeps being slow.

---

Check Point Research’s full technical write-up is available via The Hacker News.