Security researchers at Check Point have detailed how a legitimate, Microsoft-signed driver buried inside Windows Defender could be repurposed by an attacker with administrative rights to carry out privileged file and registry operations from the Windows kernel, potentially clearing the way to disable antivirus and endpoint detection tools entirely.

Crucially, this is not a memory-corruption bug or a conventional vulnerability with a CVE waiting for a patch. Instead, it is a demonstration of how a trusted remediation component can be turned into what researchers call a living-off-the-land driver simply by reverse-engineering and reproducing its undocumented internal protocol.

Meet BTR.sys

The driver at the center of the research is BTR.sys, short for Boot-Time Removal, a component embedded within Defender’s core scanning engine, MpEngine.dll. Microsoft designed it to handle a specific, mundane job: finishing remediation tasks that could not complete while Windows was running, such as deleting a malicious file that the operating system currently has locked.

During normal operation, the driver behaves in ways that would raise eyebrows in an incident response investigation if its origin were not already known. It can appear under a randomly generated filename and service name, store its encrypted configuration in an Alternate Data Stream named :changelist, execute a queued set of operations, and then clean up after itself, all standard behavior for Defender’s legitimate remediation architecture, but behavior that closely resembles techniques attackers use to hide kernel-level tooling.

Reverse-Engineering a Trusted Protocol

According to Check Point’s analysis, BTR.sys communicates using a proprietary transaction format protected by an RC4-encrypted configuration blob with built-in integrity checks. That configuration can instruct the driver to delete files and directories, move files, delete registry keys and values, and write new registry data, all executed with the full privileges of a kernel-mode driver, effectively Ring 0.

To prove the concept was practical rather than theoretical, the research team built a tool called BTR_CLI, capable of constructing transactions the driver would accept as valid and staging it for execution. In effect, anyone able to reproduce the transaction format could direct a fully legitimate, Microsoft-signed driver to perform privileged operations on their behalf.

The “Golden Window” Problem

The most significant detail in the research is timing. BTR.sys is classified as a system-start driver rather than a boot-start driver because it needs filesystem access that is not available at the earliest stages of boot. It gets assigned to the early “Boot Bus Extender” load-order group, which means it can begin operating after the filesystem becomes available, but crucially, before many user-mode security products have fully initialized their protection stack.

Check Point’s researchers refer to this gap as a golden window: a brief but real interval during which a weaponized use of BTR.sys could potentially remove security binaries or alter the service registry settings of antivirus and EDR products before those tools are able to defend themselves. Because the interference happens so early in the boot sequence, it sidesteps the runtime protections most security software relies on to detect tampering.

Why This Differs From a Typical BYOVD Attack

Attackers have long used a technique known as Bring Your Own Vulnerable Driver, or BYOVD, which involves loading a legitimate but flawed third-party driver to gain kernel access and then exploiting a bug in it. Security tools have adapted by blocklisting known-vulnerable drivers and treating unfamiliar or unsigned drivers with suspicion.

This technique sidesteps that entire defense model. BTR.sys is not a third-party driver with a known vulnerability, it is a built-in Microsoft component with a fully valid signature. Any security control that treats a valid Microsoft signature as an automatic trust signal, which is a common and often reasonable assumption, would have no obvious reason to flag its activity as suspicious.

Current Risk and Recommended Response

Check Point stated it found no evidence that this technique has been used in real-world attacks so far. However, the public release of detailed methodology means that changes quickly, and defenders should treat proactive detection as a priority rather than an afterthought.

• Monitor for BTR.sys or similarly named system-start drivers loading outside of expected Defender remediation windows.
• Establish baseline behavior for legitimate Defender remediation activity so anomalous transaction patterns stand out.
• Do not rely solely on code-signing status when evaluating driver trustworthiness, since this research shows a validly signed component can still be abused.
• Review endpoint security product startup ordering and consider whether early-boot protections can be hardened to reduce exposure during the golden window.
• Track vendor guidance from Microsoft and Check Point closely, as detection signatures and potential mitigations are likely to evolve quickly following this disclosure.

The research is a pointed reminder that trust boundaries built around code signing and vendor legitimacy are necessary but not sufficient. When a security product’s own remediation tooling can be redirected against it, defenders need behavioral detection that looks past who signed a driver and focuses on what it is actually doing.