Microsoft Defender's own signed BTR.sys driver can be weaponized to delete third-party security software at boot, according to Check Point Research, turning a built-in cleanup component into a stealthy EDR killer that no driver blocklist can stop. The driver is embedded in Defender's MpEngine.dll and is designed to remove stubborn malware files before Windows fully loads. Check Point researcher Vinopal reverse-engineered its undocumented command format and showed that an attacker who already holds local administrator rights can direct it to delete arbitrary security binaries. There is no evidence of real-world abuse yet, and Microsoft has not shipped a patch.

What makes this different from a classic bring-your-own-vulnerable-driver attack is that nothing gets brought in. BTR.sys is first-party, Microsoft-signed, and present on virtually every Windows endpoint, which makes it a living-off-the-land driver. The standard defense against malicious drivers, Windows Defender Application Control paired with Microsoft's recommended driver blocklist, does not help here, because blocklisting Defender's own remediation driver would break legitimate malware cleanup. The abuse also runs early in the boot sequence, before third-party security services and their tamper protection initialize, which is precisely the window a ransomware operator wants to disable telemetry.

The catch, and the reason this is a serious hardening problem rather than a five-alarm emergency, is that the technique requires local administrator privileges with the ability to load drivers. Microsoft has historically treated the jump from administrator to kernel as outside its servicing boundary, classifying this class of issue as working as designed. The community pushback is that tamper resistance and credential isolation exist specifically to constrain a compromised admin session, so coercing an OS-signed driver into arbitrary deletion undermines the tier of defense enterprises were told to rely on.

Why can't Microsoft just blocklist the BTR driver?

Because it is a legitimate, actively used part of Defender. The recommended driver blocklist works by refusing to load known-bad or vulnerable drivers, but BTR.sys is neither malicious nor deprecated, it performs real remediation. Blocking it would disable Defender's ability to clean boot-persistent malware. That is the core tension the disclosure exposes: a valid code signature proves who authored a binary, not that an administrator cannot coerce it into destructive behavior.

How can defenders detect abuse of BTR.sys?

Treat administrator-to-kernel as a boundary you must monitor rather than one the OS enforces. Audit and strip the driver-load privilege from accounts that do not need it, and watch for the fingerprint of the technique: extraction of BTR.sys from MpEngine.dll, unexpected boot-cleanup staging files in Defender working directories or Windows temp paths, and anomalous driver-load or service-registration events in your endpoint telemetry.

Our read

This is a supervised-adversary-simulation question, not a patch-management one. If your defense model assumes tamper protection survives a compromised local admin, this technique invalidates that assumption on nearly every Windows host you run, and no update is coming to change it. The verifiable-by-design response is to test it: have a red team confirm whether your EDR can actually be silenced this way in your environment, then build detections for the staging behavior and reduce the population of accounts that can load drivers. Assuming the control holds because a vendor markets it as tamper-proof is exactly the kind of unverified claim we do not accept.

Reporting by The Hacker News; technique details per Check Point Research; servicing stance per Microsoft. Sources linked above.

Related: Microsoft's August 2026 Patch Tuesday and GhostSplice and malicious MCP servers.