Windows Defender's Own Driver Weaponized Against It

When the guard dog eats its own leash

A researcher took the one component you would least expect to betray you — a driver built specifically to help Windows Defender clean up malware — and turned it into a weapon against Defender itself.

The technique, called BTR Reforged, was disclosed by Check Point Research analyst Irgi Binopal at Black Hat USA 2026 and DEF CON 34. It does not rely on a third-party vulnerable driver, a zero-day in the kernel, or any flaw in the operating system’s code. It exploits a legitimate, Microsoft-signed driver that has shipped on every Windows machine for years.

That distinction is what makes this work dangerous — and hard to block.

How the trick works

BTR.sys is a boot-time removal tool. When Defender encounters a malicious file or a rogue registry entry it cannot delete while running, it hands the job off to BTR.sys. The driver loads during the next reboot, before the operating system’s file system reaches full operation, and surgically removes the targeted items.

Binopal and his team analyzed how BTR.sys processes its deletion commands and found that the interface does not validate intent — only syntax. Feed it the right instructions and it will delete or move any file or directory, and modify any registry key or value, with Ring 0 (kernel) privileges.

The exploit hinges on timing. During a reboot, there is a window where the file system is available but Defender’s core services have not yet started. In that gap, the attacker triggers BTR.sys to delete Defender’s own heart — WdFilter.sys and MsMpEng.exe — before the product can react.

Check Point demonstrated the attack on a fully patched Windows 11 25H2 system with Tamper Protection enabled. Tamper Protection is designed specifically to prevent anyone, including administrators, from disabling Defender or altering its configuration. It failed.

Why this is different from BYOVD

Security teams who follow kernel-level attacks will recognize the general shape of this problem. The Bring Your Own Vulnerable Driver (BYOVD) technique has been around for years: an attacker ships a signed but flawed driver from a legitimate vendor and uses it to gain kernel access, then disables the endpoint agent.

BTR Reforged is a BYOVD attack in everything but name. The difference is that BTR.sys is not flawed, not outdated, not from a third party — and it is actively helping Defender do its job at the moment it is being used against it.

You cannot add it to a blocklist. You cannot flag it as suspicious in an application control policy. It is, by every metric, a good driver doing a good thing. That is also exactly why it is hard to defend against.

What this means for enterprises

Microsoft responded by classifying the issue as not requiring an emergency update, citing the fact that the attack requires pre-existing administrator privileges and the SeLoadDriverPrivilege right. The company’s posture is consistent: this is a technique enabled by existing admin access, not a remote exploitation path.

That is technically accurate but strategically narrowing. The real risk is not a worm that spreads on its own. It is a threat actor who has already compromised an admin account — through phishing, credential theft, or lateral movement — and now has a new, deniable way to erase the traces of its presence and blind the endpoint sensor watching it.

BTR Reforged turns Defender’s cleanup tool into a cleanup-of-Defender tool. The attacker reboots the machine, the protection vanishes, and nothing in the normal logs necessarily screams exploitation.

The practical takeaway for security teams is not panic — it is discipline.

What to do now

The most direct lever is access control. SeLoadDriverPrivilege should not be granted to standard admin accounts. It is a high-value right that should be reserved for dedicated driver-install workflows and protected by just-in-time elevation.

Detection should focus on anomalous behavior patterns rather than trying to block BTR.sys itself. Three signals are worth watching:

First, unexpected registration of a BTR-related driver service. The driver is legitimate, but its service should only appear under Defender-managed conditions.

Second, creation of files matching the .sys:changelist naming pattern that BTR.sys uses to track what it intends to remove.

Third, file deletion activity originating from the system process (PID 4) immediately after a driver load. That combination — a driver load followed by kernel-level file removal from the init process — is not normal Defender behavior and should trigger an alert.

Finally, organizations should audit which accounts hold SeLoadDriverPrivilege and strip it wherever possible. The privilege is powerful, and in the wrong hands it is a back door that does not even need to look like one.

The broader lesson

The most interesting part of BTR Reforged is not the exploit itself. It is the pattern it reveals.

As endpoint protection grows more sophisticated, it pulls more privileged operations into its own stack. It needs kernel drivers. It needs boot-time access. It needs the ability to touch files before the OS fully boots. Every new capability is a new surface — and every capability the defender requires is a capability an attacker can potentially redirect.

The defense is not getting weaker. It is just becoming more complex, and complexity is where evasion lives.

Check Point has found no evidence that BTR Reforged is being used in the wild. That may change. The proof of concept is public, the prerequisites are realistic for any adversary with admin access, and the technique leaves no vulnerable driver to trace back to a vendor.

What makes this moment worth paying attention to is not that Windows is broken. It is that the tools built to keep it safe are now part of the attack toolkit — and they will always be harder to detect than anything an attacker brings from the outside.