BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive

What if a trusted security component could be repurposed into an attacker-controlled kernel primitive? What if a signed Microsoft remediation driver could be instructed to execute arbitrary file and registry operations from Ring 0 – without exploits, vulnerabilities, or memory corruption?

In this publication, we present the first full reverse engineering of the Windows Defender Boot-Time Removal driver ( BTR.sys ) and its proprietary transaction format. We dissect its encrypted configuration mechanism, integrity validation logic, and execution pipeline, and demonstrate how this legitimate remediation component can be transformed into a universal kernel operation engine. We introduce BTR_CLI , a research tool that constructs valid encrypted transactions and safely exercises the driver’s functionality to demonstrate its capabilities.

Furthermore, we demonstrate how BTR_CLI can be used as an EDR/AV bypass technique, disarming security solutions while using a trusted Windows built-in , Microsoft-signed driver, thus not relying on typical BYOVD techniques.

Our research reveals how trusted security infrastructure can unintentionally expose powerful primitives, what this means for defenders, and how similar patterns may exist in other signed remediation components. This work blends reverse engineering, kernel internals, and detection engineering into a practical case study of when defensive technology becomes offensive capability .

This research originated during an incident response investigation involving a compromised system, where certain endpoint telemetry appeared suspicious but was ultimately traced back to legitimate Windows Defender remediation activity. During analysis, a driver (internally identified as BTR.sys ) appeared on disk under System32\drivers with a randomized filename and a corresponding randomized service name ( HKLM\SYSTEM\CurrentControlSet\Services\mzqnjtaq ), accompanied by the following registry entries:

At first glance, several characteristics resembled attacker tradecraft:

These indicators strongly resembled malicious kernel loader behavior, particularly given prior research into exotic loading mechanisms such as loading kernel drivers directly from ADS paths – a technique often considered theoretical yet has proven practical.

The most unusual aspect was that the ADS stream contained an encrypted binary structure used as configuration input for the driver. Encountering a Microsoft-signed driver relying on an ADS-stored encrypted configuration immediately raised suspicion that it might be exploitable or abused by attackers. Our initial hypothesis was that the threat actor had leveraged this driver for post-exploitation activity. That hypothesis ultimately proved incorrect: the behavior was legitimate Defender remediation logic.

However, that discovery triggered a deeper analysis of BTR.sys and the surrounding remediation architecture. What began as a false-positive investigation quickly evolved into a full reverse-engineering effort that uncovered undocumented functionality, a custom protocol, and an unexpectedly powerful kernel execution model.

The driver does not expose a standard IOCTL interface. Instead, it reads a configuration blob pointed to by the Args value in its Service Registry Key.

The configuration blob is protected by both encryption and integrity checks to prevent tampering.

The RC4-decrypted payload (configuration blob) is a serialized list of actions. Through reverse engineering, we have mapped the structure entirely (notably, the PDB for BTR.sys is not provided by Microsoft).

The file starts with a fixed header that defines the session.

The table above can be represented as the following C structure:

It immediately follows the header.

Following the Global Payload is a list of Operation Items.

Item Header (16 Bytes) :

The table above can be represented as the following C structure:

Item Data (Variable) :

The structure of the data depends on the Action ID. For complex actions (3-6), it starts with a Flags field; for simple actions (1-2), it starts immediately with the path. It generally follows:

[Flags (Optional 4 bytes)] [String 1] [String 2] ... [Padding]

We have identified and implemented the following Action IDs in the BTR_CLI tool:

A unique trait of BTR.sys is its return value upon successful execution. It returns 0xC0000056 ( STATUS_DELETE_PENDING ) instead of STATUS_SUCCESS .

The driver creates a text log at \SystemRoot\Temp\BootClean.log .

To obtain a comprehensive overview of different BTR.sys driver versions, we searched public repositories such as VirusTotal and Winbindex (by locating MpEngine.dll , which embeds the BTR.sys driver). Using Winbindex, we identified exactly 12 different versions of 64-bit MpEngine.dll across all available Windows 10 and Windows 11 releases.

Extracting the embedded BTR.sys from these 12 MpEngine.dll versions resulted in 5 unique driver builds (based on distinct SHA-256 hashes).

Combining these 5 builds with distinct BTR.sys samples (unique SHA-256 hashes) identified on VirusTotal at the time of analysis, and after de-duplication against the Winbindex dataset, we obtained a total of 18 unique 64-bit Microsoft-signed versions (distinct Authentihashes) of the BTR.sys driver. Analysis confirmed that all versions the same hard-coded 256-byte RC4 key used to decrypt the transaction structure (configuration blob).

Furthermore, the transaction structure format is consistent across all analyzed versions and supports all identified Action IDs. This consistency makes the BTR_CLI tool (provided in the section) a universal, reliable, and reusable component across all tested Windows OS builds → from Windows 7 Build 7601, through Windows 8.1 and Windows 10 22H2, up to the latest Windows 11 25H2 at the time of writing ( July 2026 ).

The BTR_CLI tool serves as a fully functional Proof-of-Concept (PoC) demonstrating the offensive utility of the Microsoft Boot Time Removal driver ( BTR.sys ). The source code implements a complete exploitation chain that mimics the native behavior of MpEngine.dll while extending its capabilities for research and red-teaming purposes.

The tool performs the following sequence of operations:

The source code of BTR_CLI , with its ready-to-run executables (both x64 and x86 , each self-contained with the embedded BTR.sys fallback), is available here , MIT licensed.

The BTR_CLI tool underwent robust testing across a comprehensive range of Windows operating systems, spanning from Windows 7 Build 7601 (released in 2011), through Windows 8.1 and Windows 10 22H2, up to the latest fully updated Windows 11 25H2 ( as of July 2026 ). Testing confirmed the tool’s ability to successfully execute all supported BTR.sys capabilities (Action IDs) across every version. Notably, while the tool includes an embedded fallback driver, this redundancy was never required during testing; the target-specific BTR.sys was successfully extracted from the local MpEngine.dll in every instance. This capability allows the tool to operate without introducing external binaries, effectively avoiding BYOVD-like scenarios. These findings highlight a remarkable consistency in the internal BTR.sys codebase – retaining the same hard-coded RC4 key and configuration structure for over 15 years.

The operational premise of BTR.sys suggests a capability to execute during the earliest stages of the operating system boot process. However, empirical testing confirms a hard architectural constraint: BTR.sys cannot function as a SERVICE_BOOT_START ( Start=0 ) driver.

While standard EDR kernel minifilters utilize Start=0 to register callbacks immediately upon kernel initialization, BTR.sys was designed by Microsoft to perform file I/O operations (reading the ADS configuration and creating logs) directly within its DriverEntry routine. During Phase 0 of the boot process, the Windows Object Manager has not yet established the SystemRoot symbolic link (used by BTR.sys ), and the storage stack is not fully initialized. Consequently, forcing BTR.sys to Start=0 results in immediate failure.

Therefore, the driver must be configured as SERVICE_SYSTEM_START ( Start=1 ) . To maximize its offensive utility, it is assigned to the “ Boot Bus Extender ” load order group. This configuration places it at one of the earliest practical execution slots available in Phase 1 , immediately following the initialization of the filesystem ( Ntfs.sys ) and the transition from the OS Loader to the Kernel I/O Manager. Notably, this configuration mirrors the exact mechanism MpEngine.dll employs to stage the driver during a legitimate Windows Defender remediation event.

The Windows Kernel enforces a strict temporal hierarchy by scanning the ServiceGroupOrder registry key in two distinct passes. First, the OS Loader loads all Start=0 (Boot) drivers during Phase 0 . Once Phase 0 concludes, the Kernel I/O Manager scans the list again to load Start=1 (System) drivers during Phase 1 . It is within this specific phase that the “Boot Bus Extender” group provides a strategic advantage. While Start=0 security filters (e.g., WdFilter ) are already active, BTR.sys executes at the very beginning of Phase 1 , effectively preempting other critical security drivers (e.g., UCPD , WdNisDrv ) that reside in lower-priority groups like “ FSFilter Activity Monitor ” (see the default Windows 11 25H2 ServiceGroupOrder ):

This architectural positioning creates a “ Golden Window ” – a specific timeframe where the filesystem is writable, but high-level security services and user-mode protection agents have not yet started.

Boot-time logging via Process Monitor provided definitive proof of this execution timeline. The events captured during a reboot cycle on a fully updated Windows 11 25H2 environment revealed the following sequence. Note that while Procmon’s boot logging may introduce slight latency, the relative order of execution is architecturally deterministic and remains consistent.

Phase 0: Kernel Initialization (Start=0 Boot) The kernel initializes the filesystem and early-launch security drivers.

Phase 1: The “Golden Window” (Start=1 System) The kernel transitions to System Start. BTR.sys (renamed mlrmqchs.sys for testing) executes immediately due to its “ Boot Bus Extender ” group.

Phase 2: User Mode Initialization (Start=2 Automatic / Start=3 Manual) The Service Control Manager ( SCM ) begins starting services. This occurs significantly later.

Conclusion: The BTR.sys driver, when manually staged to execute at the boot, effectively bypasses the active protection stack by operating in the interval where the kernel is active but the security suite’s intelligence is dormant. Furthermore, tests demonstrated a successful Tamper Protection bypass at runtime.

The following demonstration video presents a complete “ Kill Chain ” scenario on a fully updated Windows 11 25H2 machine with all security features enabled. The Proof-of-Concept utilizes BTR_CLI ( BTR.sys ) to systematically dismantle the Windows Defender security stack from Ring 0, rendering the system defenseless against a known malicious sample.

The demonstration follows these specific stages:

Because BTR.sys is a legitimate Microsoft-signed component, signature-based blocking is ineffective. Furthermore, a well-crafted weaponization tool (like BTR_CLI ) intentionally mimics the operational footprint of the legitimate Windows Defender remediation process.

Based on telemetry analysis using Sysmon (System Monitor), robust detection must rely on behavioral context , Alternate Data Stream (ADS) monitoring , and kernel-execution attribution .

During our analysis across all collected samples and telemetry sources, we did not observe evidence of real-world abuse of BTR.sys in the manner demonstrated in this research. This suggests the technique is currently unknown or unused by threat actors, making proactive detection engineering feasible before weaponization appears in the wild.

This research shows that the BTR.sys driver, originally designed as a defensive remediation component, exposes a powerful and fully functional kernel-mode execution primitive when its internal protocol is understood. By reversing its encrypted transaction format, integrity validation scheme, and execution logic, we demonstrated that a trusted, signed Microsoft driver can be instructed to perform arbitrary file and registry operations from Ring 0 without exploiting any vulnerability.

The creation of the BTR_CLI tool was a key milestone in validating our findings. The tool automates payload construction, encryption, integrity calculation, driver extraction, execution, and cleanup. This allowed us to reliably reproduce kernel-level operations across all tested Windows 7-11 versions and across every analyzed BTR.sys build. Its successful operation confirmed that:

This effectively repurposes a specialized defensive component into a versatile, signed kernel-mode primitive capable of arbitrary file and registry manipulation.

More broadly, this work highlights an important defensive lesson: trusted security infrastructure can unintentionally expose attacker-usable primitives when its internal mechanisms are undocumented but reachable. The issue is not a vulnerability in the traditional sense, but rather an architectural trust boundary that can be crossed if an attacker already has administrative privileges.

Following responsible disclosure, MSRC confirmed that these findings do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges ( SeLoadDriverPrivilege ). This classification establishes BTR.sys as a potent “ Living-off-the-Land ” driver ( LOLDriver ). Crucially, unlike third-party drivers often neutralized by the Microsoft Vulnerable Driver Blocklist or tracked by the LOLDrivers project , BTR.sys is an essential, built-in Windows component. It remains fully allowed and operational, enabling advanced evasion without the risks or constraints associated with traditional BYOVD techniques.

As defenders increasingly rely on signed binaries as indicators of trust, research like this demonstrates why behavioral context, execution lineage, and intent analysis must complement signature-based trust models.