As reported by The Hacker News, Check Point Research has unveiled a sobering technique that turns Microsoft Defender's own legitimately signed boot-time remediation driver — BTR.sys — into a kernel-level weapon capable of deleting files, directories, and registry entries from Ring 0. Presented at Black Hat USA 2026 and DEF CON 34, the research demonstrates that no vulnerability exploitation or external driver is needed. The tooling is already inside every modern Windows machine.

Threat Alert: Presented at Black Hat USA 2026 and DEF CON 34, the research demonstrates that no vulnerability exploitation or external driver is needed.

Why This Is Different From Typical Driver Abuse

The security community has spent years combating BYOVD (Bring Your Own Vulnerable Driver) attacks, where threat actors load legacy or flawed signed drivers to gain kernel access. Microsoft responded with the Vulnerable Driver Blocklist and Windows Defender Application Control (WDAC). This technique renders those defenses irrelevant. BTR.sys is not a vulnerable third-party driver — it is a required component of Defender itself. Blocklisting it would break legitimate remediation functionality. There is no patch to issue because no bug is being exploited. The driver is working as designed; it is simply being given instructions it was never intended to receive from an unauthorized caller.

The hardcoded RC4 key has remained unchanged across 18 unique 64-bit builds shipped since Windows 7. That is a cryptographic design failure spanning over a decade of Windows releases.

The Detection Blind Spot

What makes this particularly dangerous for enterprise defenders is the telemetry gap. The proof-of-concept tool BTR_CLI installs the driver via direct HKLM registry writes, bypassing the Service Control Manager entirely. This means no Windows Event ID 7045 (Service Installed) event is generated — a primary signal that EDR platforms rely on for driver-load detection. When BTR.sys executes its queued operations, they appear in telemetry as originating from the System process (PID 4), blending seamlessly into legitimate kernel activity.

For ransomware operators, this is a blueprint for disabling endpoint security at boot — the moment when EDR agents are most fragile and most protective tools have not yet initialized. The ability to move files into System32\drivers or delete security software registry keys before the OS fully loads represents a significant evasion advantage.

Who Is Most At Risk

The Detection Blind Spot
Enterprise environments with large Windows fleets relying on Microsoft Defender as primary or sole EDR
Organizations that depend heavily on WDAC and the Vulnerable Driver Blocklist as primary kernel-protection controls
Ransomware-targeted sectors — healthcare, manufacturing, municipal government — where boot-time tampering could neutralize protection before encryption begins
Legacy-heavy estates still running Windows 7 or older builds where BTR.sys has shipped unchanged for years

Shield53 Recommendations

While no vendor patch exists for this technique, defenders are not powerless. The key is shifting detection from driver load events to behavioral indicators and integrity monitoring.

  • Monitor MpEngine.dll access patterns: Alert on any process reading the BOOTTIMETOOL resource from Defender's Definition Updates directory outside of legitimate Defender update workflows. This is the first step in BTR_CLI's chain.
  • Track direct HKLM\SYSTEM\CurrentControlSet\Services registry writes that set Type=1, Start=1, and Group="Boot Bus Extender" without corresponding Event ID 7045 entries. This SCM-bypass pattern is a high-fidelity indicator.
  • Deploy boot-time integrity monitoring: Use platforms that verify driver loads against expected baselines during early boot. Secure Boot with measured boot attestation can help detect anomalous driver loading sequences.
  • Hunt for BTR.sys loads outside Defender's own remediation workflow: If BTR.sys appears in loaded module telemetry without a preceding Defender remediation reboot event, treat it as suspicious.
  • Layer your EDR: Organizations relying solely on Microsoft Defender should consider a secondary endpoint tool with independent kernel telemetry. This technique specifically targets Defender's own component — a second agent with different architecture provides resilience.
  • Engage Microsoft Support for guidance on BTR.sys hardening. The hardcoded RC4 key is a design flaw that warrants a long-term fix, even if no CVE is assigned today.
The absence of observed in-the-wild abuse is a narrow window of opportunity. With proof-of-concept code now public, it is a matter of when — not if — threat actors incorporate this into playbooks. Defenders should treat this as an imminent detection-engineering priority, not a theoretical concern.