Microsoft Defender Built‑in Driver Abuse Enables Deletion of Security Software at Boot

Immediate Threat Vector

Microsoft Defender built‑in driver abuse is a newly disclosed technique that weaponizes the signed BTR.sys driver to delete security binaries before they become active. Researchers demonstrated a proof‑of‑concept tool, BTR_CLI, that extracts the driver from MpEngine.dll, crafts a valid RC4‑encrypted transaction, and installs the driver via direct registry writes. Within seconds of reboot, a fully patched Windows 11 25H2 system can lose its entire Defender stack—even with Tamper Protection enabled—provided the attacker holds an account with SeLoadDriverPrivilege.

Abuse Technique Overview

The attack subverts two traditional hardening pillars: (1) vulnerable‑driver blocklists that prevent loading of known malicious signed drivers, and (2) Windows Defender Application Control (WDAC) policies that enforce code‑signing constraints. BTR.sys is a native component shipped with every Windows installation since Windows 7, so it cannot be added to a blocklist without breaking Defender itself. The driver is installed as a service by writing directly to HKLM\SYSTEM\CurrentControlSet\Services with Type=1, Start=1, and Group="Boot Bus Extender". This bypasses the Service Control Manager and leaves no Event ID 7045 trace.

The “Golden Window” Exploitation Model

The technique exploits a narrow interval—coined the golden window—when the file system becomes writable after the kernel mounts but before user‑mode Defender services start. During this period, BTR.sys runs in Ring 0 under the System process (PID 4) and can delete locked files such as WdFilter.sys and MsMpEng.exe. A secondary trigger can schedule the same operations for the next reboot, ensuring persistence of the sabotage.

Why Blocklists Alone Are Insufficient

A common belief is that signing and blocklisting of third‑party drivers provide near‑complete defense against kernel‑level abuse. The Microsoft Defender built‑in driver abuse case disproves this assumption: any driver that Microsoft ships and trusts implicitly becomes a potential attack surface. Because the driver is required for legitimate remediation, defenders cannot simply remove it without sacrificing functionality. This forces a strategic shift—from relying on external driver vetting to scrutinizing built‑in privileged components.

Concrete Mitigation Steps

1. Restrict SeLoadDriverPrivilege – Limit this privilege to a minimal set of service accounts. Use Group Policy (Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment) to remove the privilege from standard administrators.
2. Deploy Sysmon Event Monitoring – Apply the signatures published by Check Point Research:
   • Event ID 15 with a .sys:changelist ADS,
   • Registry events creating a service key with Group="Boot Bus Extender" without a corresponding Event ID 7045,
   • Rapid creation/deletion of \SystemRoot\Temp\BootClean.log by PID 4,
   • Immediate DriverLoad followed by FileDelete events.
3. Enforce Kernel‑Mode Code Signing (KMCS) Policies – While KMCS cannot block BTR.sys, it can prevent unauthorized drivers from loading alongside it, reducing the attacker’s ability to chain additional payloads.
4. Audit Administrative Accounts – Verify that any account with admin rights also possesses SeLoadDriverPrivilege. Remove the privilege where unnecessary.
5. Deploy Behavioral EDR Solutions – Tools that monitor low‑level kernel activity (e.g., behavior‑based EDR) can flag the unusual driver load pattern even if the driver itself is trusted.

Operational Impact on Enterprises

Enterprises that enforce strict tamper‑protection policies may assume Defender cannot be disabled without physical access. Microsoft Defender built‑in driver abuse demonstrates that an insider or compromised admin account can silently erase the protection layer before any security service starts, leaving the endpoint exposed to ransomware, credential‑stealing malware, or nation‑state tools that rely on early‑boot persistence. The risk is amplified in environments with shared admin credentials or where privileged access management (PAM) is not enforced.

Regulatory and Compliance Considerations

Frameworks such as NIST SP 800‑53 (CM‑7, AC‑16) and ISO 27001 require organizations to protect the integrity of security controls. If a built‑in driver can be repurposed to dismantle those controls, auditors may view reliance on default Windows components as a control weakness. Companies subject to CISA directives on supply‑chain risk should treat this as a supply‑chain integrity issue, even though the code originates from Microsoft.

What to Watch Next

• Microsoft’s Response – Check Point Research notes that MSRC does not plan an immediate patch, classifying the issue as “requires admin privileges.” Watch for future firmware or policy updates that introduce runtime checks on BTR.sys usage. See the official Microsoft Security Response Center advisory for updates: https://msrc.microsoft.com.
• Threat Actor Adoption – Although no real‑world abuse has been observed, the technique is low‑effort for any actor that already possesses admin rights. Expect early‑adopter groups to integrate Microsoft Defender built‑in driver abuse into post‑exploitation toolkits.
• Community‑Driven Detection – Open‑source Sysmon configurations and YARA rules for the BootClean.log pattern are emerging. Organizations should integrate these into their SIEM pipelines.
• Supply‑Chain Hardening – Follow guidance from the Microsoft Security Response Center and the Cybersecurity and Infrastructure Security Agency on validating driver integrity at deployment time.

Broader Implications for Trust Models

The Microsoft Defender built‑in driver abuse forces a reevaluation of the implicit trust placed in OS‑provided components. Security architectures that treat the operating system as a trusted base must now consider internal attack surfaces as equally critical as external ones. This aligns with the emerging “Zero‑Trust Kernel” paradigm, where every kernel operation—regardless of its origin—must be verified, logged, and constrained.

Read Next: Industrial Protocol OT Risk – Emerging Family Exposes Critical Vulnerabilities

---

Source: Check Point Research brief presented at Black Hat USA 2026 and DEF CON 34; original reporting at The Hacker News (https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html).