BTR Reforged: Weaponizing Microsoft Defender's Boot-Time Driver for Kernel-Level Defense Evasion

1. Background: What Is BTR.sys?

BTR.sys stands for Boot Time Removal Tool, a kernel-mode driver embedded within Microsoft Defender's MpEngine.dll as the BOOTTIMETOOL resource. It has shipped with every Windows installation since Windows 7 and is deployed when Defender needs to finish removing malware after a reboot — specifically, deleting files or registry entries that were locked while the system was running.

The driver communicates via a proprietary, undocumented transaction protocol. Every configuration blob passed to BTR.sys is RC4-encrypted with a 256-byte key hard-coded in the .rdata section of every BTR.sys build. Researcher Jiří Vinopal verified this key is identical across all 18 unique 64-bit versions of the driver shipped since Windows 7.

Because BTR.sys is a required Windows component, it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via WDAC without disrupting Defender's core remediation capability. This is the key architectural distinction from traditional BYOVD (Bring Your Own Vulnerable Driver) attacks: BTR Reforged uses a driver already present on every system, not a third-party driver that can be blocklisted.

2. Attack Chain Walkthrough

Step 1: Extract BTR.sys

An attacker with administrative access locates MpEngine.dll under Defender's Definition Updates directory (typically C:\ProgramData\Microsoft\Windows Defender\Definition Updates\{GUID}\mpengine.dll) and extracts the embedded BTR.sys binary using the BOOTTIMETOOL resource ID.

Step 2: Construct Encrypted Transaction

The attacker crafts a valid encrypted transaction blob specifying the files to delete, registry keys to modify, or files to move. The PoC tool BTR_CLI handles this automatically using the hard-coded RC4 key reverse-engineered from the driver.

Step 3: Install BTR.sys via Registry (Bypassing SCM)

Instead of using the Service Control Manager (SCM) — which would generate Windows Event ID 7045 — the attacker writes the driver service entry directly to HKLM\SYSTEM\CurrentControlSet\Services with:

Type = 1        (SERVICE_KERNEL_DRIVER)
Start = 1       (SERVICE_SYSTEM_START)
Group = "Boot Bus Extender"

This generates no Event ID 7045 and bypasses SCM auditing entirely. The driver is loaded at boot via the Boot Bus Extender group, which executes before the file system stack is fully initialized — well before Defender's user-mode services have started.

Step 4: Exploit the "Golden Window"

When loaded, BTR.sys executes its queued operations from Ring 0, attributed in telemetry to the System process (PID 4). The "golden window" is the interval after the file system becomes writable but before Defender's user-mode services (MsMpEng.exe) have started and locked themselves. This allows BTR.sys to physically remove security binaries such as:

• C:\Windows\System32\drivers\WdFilter.sys
• C:\ProgramData\Microsoft\Windows Defender\Platform\{version}\MsMpEng.exe
• Any other security product binaries at attacker-chosen paths

The live demonstration at Black Hat USA 2026 showed BTR_CLI deleting the entire Microsoft Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection active.

3. Why This Matters

The BTR Reforged technique represents a paradigm shift in defense evasion for several reasons:

It Cannot Be Blocklisted

Unlike traditional BYOVD attacks that rely on third-party signed drivers (which can be added to the Windows Vulnerable Driver Blocklist or WDAC policies), BTR.sys is a required Windows component. Blocking it would break Microsoft Defender's post-reboot remediation capability — a non-starter for any organization that uses Defender.

It Bypasses Existing Detection Mechanisms

Registering the driver via direct HKLM registry writes bypasses the Service Control Manager entirely, meaning no Event ID 7045 is generated. Most EDRs and SIEMs rely on 7045 as a primary signal for new driver installations. The technique also evades WDAC, which trusts Microsoft-signed kernel binaries by default.

Tamper Protection Is Ineffective

The live demonstration showed BTR_CLI deleting the Defender stack from a machine with Tamper Protection enabled. Because BTR.sys executes at Ring 0 during early boot — before Tamper Protection's user-mode components initialize — the protection mechanism is simply bypassed.

4. BTR Reforged vs. Traditional BYOVD

5. Detection Opportunities

Although BTR Reforged evades several traditional detection mechanisms, there are still observable artifacts that defenders can monitor.

Registry-Based Driver Installation

While Event ID 7045 is bypassed, the direct registry writes to HKLM\SYSTEM\CurrentControlSet\Services\ for a kernel driver can be detected:

Registry key: HKLM\SYSTEM\CurrentControlSet\Services\{name}\
Values:
  Type = 1          (SERVICE_KERNEL_DRIVER)
  Start = 1         (SERVICE_SYSTEM_START)
  Group = "Boot Bus Extender"
  ImagePath = path\to\btr.sys

Sysmon Event ID 13 (Registry Value Set)

Configure Sysmon to monitor for Type=1 registry writes under HKLM\SYSTEM\CurrentControlSet\Services\* where the ImagePath does not correspond to a legitimate Windows driver. While legitimate BTR.sys deployment by Defender itself follows a specific pattern, attacker deployment will write to a new service key with a predictable structure.

Kernel Driver Load (Event ID 6 via DriverFrameworks-UserMode)

The Microsoft-Windows-DriverFrameworks-UserMode/Operational log (Event ID 6) records when a driver is loaded, including its ImagePath and service name. Monitor for BTR.sys being loaded outside of Defender's legitimate boot-time remediation context.

BTR.sys Binary Location

Legitimate BTR.sys is extracted by Defender to a temporary path with a random name during remediation. An attacker deploying BTR.sys will likely place it in a predictable location (e.g., %TEMP%, C:\Windows\Tasks, or a non-standard driver directory).

6. Indicators of Compromise

7. Detection Rule (Sigma)

The following Sigma rule detects registry-based driver installation that bypasses SCM — a key artifact of BTR Reforged deployment:

title: BTR Reforged - Registry-Based Driver Installation
id: btr-reforged-reg-svc
status: experimental
description: Detects direct registry writes for kernel driver
             installation bypassing Service Control Manager,
             a key technique used by BTR Reforged
author: CyberOSINT Threat Research
references:
  - https://research.checkpoint.com/btr-reforged
  - https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
date: 2026-08-23
tags:
  - attack.defense_evasion
  - attack.t1562.001
  - attack.t1068
logsource:
  category: registry_event
  product: windows
detection:
  selection:
    TargetObject|startswith: 'HKLM\SYSTEM\CurrentControlSet\Services\'
    Details|contains|all:
      - 'Type = 1'            # SERVICE_KERNEL_DRIVER
      - 'Start = 1'           # SERVICE_SYSTEM_START
      - 'Boot Bus Extender'   # Boot group
  filter_legitimate:
    Image|startswith:
      - 'C:\Windows\'
      - 'C:\ProgramData\Microsoft\Windows Defender\'
  condition: selection and not filter_legitimate
falsepositives:
  - Legitimate Defender boot-time remediation (limited window)
  - Third-party security products using same mechanism
level: high

8. Mitigation & Recommendations

Important: There is no patch for this technique because it does not exploit a vulnerability — it abuses a legitimate Windows capability. Microsoft's position, confirmed by MSRC, is that the technique requires existing administrative privileges (SeLoadDriverPrivilege).

Short-Term (Implement Now)

• Monitor registry-based driver installations using the Sigma rule above. This is the single most detectable step in the attack chain.
• Restrict SeLoadDriverPrivilege — by default, only administrators hold this privilege. Review and audit administrative accounts to minimize the attack surface.
• Enable Sysmon Event ID 13 (Registry Value Set) for HKLM\SYSTEM\CurrentControlSet\Services\* and forward to your SIEM.
• Monitor for unexpected reboots followed by missing security product services/files — a classic indicator of boot-time defense evasion.

Medium-Term

• Harden administrative account usage — implement Privileged Access Workstations (PAWs) for administrative activities.
• Review WDAC/AppLocker policies — while WDAC cannot block BTR.sys (Microsoft-signed), it can restrict the processes that are allowed to load kernel drivers.
• Evaluate EDR coverage — ensure your EDR solution monitors early boot-time driver loading via the Microsoft-Windows-DriverFrameworks-UserMode/Operational log.

Long-Term

• Microsoft ecosystem coordination — push for architectural changes that separate Defender's boot-time remediation from a general-purpose kernel driver capable of arbitrary file operations, or implement cryptographic attestation for authorized BTR.sys transactions.
• Community detection rule sharing — the technique is currently unused in the wild, making proactive detection engineering viable. Share detection rules via Sigma, YARA, and KQL.

9. Analyst Conclusion

BTR Reforged represents a generational shift in Windows defense evasion. It is the first publicly documented technique to weaponize a built-in Microsoft-signed kernel component that cannot be blocklisted, bypasses existing detection mechanisms (no Event ID 7045, no WDAC bypass needed), and defeats tamper protection.

The technique's public disclosure at Black Hat USA 2026 and DEF CON 34, combined with the release of BTR_CLI PoC, means that weaponization by threat actors is a matter of when, not if. The most likely initial adopters will be:

• Ransomware operators — disabling Defender before encrypting endpoints (analogous to the AvNeutralizer pattern used by FIN7)
• APT groups — establishing persistent kernel-level access by disabling security products at boot
• Red teams — adopting it as a standard defense evasion tool in their arsenal

The current window — where the technique is public but not yet weaponized — is a rare opportunity for defenders to implement detection before exploitation. The registry-based driver installation artifact is the most reliable detection signal and should be prioritized in SIEM and EDR rule deployments.

Bottom line: BTR Reforged is not a vulnerability you patch — it is an architectural reality you monitor for. The defenses that work are detection engineering (registry monitoring, driver load auditing) and privilege minimization (administrative account hygiene). There is no magic bullet, but there is a clear detection signal — and that is where defenders should focus their energy today.