**Research by: Jiří Vinopal** **(**@vinopaljiri **)**

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 `System32drivers` with a randomized filename and a corresponding randomized service name ( `HKLMSYSTEMCurrentControlSetServicesmzqnjtaq`), accompanied by the following registry entries:

At first glance, several characteristics resembled attacker tradecraft:

`:changelist) attached to the driver file`

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.

`BTR.sys` `MpEngine.dll. It is dropped to disk (with a randomized filename matching` `[a-z]{8}.sys, e.g.,` `mzqnjtaq.sys) only when a remediation action requires a reboot (e.g., deleting a locked file).`

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.

`HKLMSYSTEMCurrentControlSetServices{Random}Args` `C:Windowssystem32driversBTR.sys:changelist) containing RC4-encrypted binary data.`

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

`.rdatasection of the driver (this key appears to be consistent across various` `BTR.sysdriver versions).` `~CRC32` `0xEDB88320) and initialization (` `0xFFFFFFFF). However, it deviates from the standard implementation by` `~CRC32in the tables in the next section below).` `0xFFFFFFFF) for every individual structure (Global Header, Global Payload, Item Header, and Item Data). This design isolates the validation of each component, effectively`

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:

“`
struct GLOBAL_HEADER { uint32_t Magic; // 0xFEE1DEAD uint32_t Version; // 2 uint32_t PayloadOffset; // 0x10 (relative offset to Global Payload) uint32_t GlobalCRC; // ~CRC32(Header) uint32_t TransID_Low; // ~CRC32(Payload) uint32_t TransID_High; // Size(Payload) };
“`

It immediately follows the header.

`??C:ProgramData…mzqnjtaq.dat). The driver creates this file and writes a` `[Flags]) with the`

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:

“`
struct ITEM_HEADER { uint32_t DataSize; // Size of Item Data uint32_t Action; // Action ID uint32_t HeaderCRC; // ~CRC32(Header) uint32_t DataCRC; // ~CRC32(Data) };
“`

**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]`

`[Flags]field, the driver utilizes this reserved space to generate the feedback report. It shifts the string data by 4 bytes into this padding area to create room at the beginning of the buffer for the`

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

`[Path]` `[Path]` `[Flags] [Source Path] [Dest Path]` `Dest Pathis empty, this acts as a` `Dest Pathis valid, this allows` `[Flags] [Key Path]` `[Flags] [Key Path + “\” + Value Name]` `\) to split the Key from the Value. Standard paths fail; specific formatting is required.` `[Flags] [Type] [Size] [Key Path + “\” + Value Name] [Data]`

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 `SystemRootTempBootClean.log`.

`BTR_CLItool automatically injects an` `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 share the same hard-coded 256-byte RC4 key** used to decrypt the transaction structure (configuration blob).

“`
1E 87 78 1B 8D BB A8 44 CE 69 70 2C 0C 78 B7 86 A3 F6 23 B7 38 F4 ED F9 AF 83 53 0F B3 FC 54 FA A2 1E B9 CF 13 32 FD 0F 0D A9 54 F6 87 CB 9E 18 27 96 97 90 0E 54 FB 31 7C 9C BC E4 8E 23 D0 53 71 EC C1 59 51 B7 F3 64 9D 7C A3 3E D6 8D C9 04 7E 82 C9 BA AD 96 99 D0 D4 58 CB 84 7C A9 FF BE 3C 8A 77 52 33 55 7D DE 13 A8 B1 40 87 CC 1B C8 F1 0F 6E CD D0 83 A9 59 CF F8 4A 9D 1D 50 75 5E 3E 19 18 18 AF 23 E2 29 35 58 76 6D 2C 07 E2 57 12 B2 CA 0B 53 5E D8 F6 C5 6C E7 3D 24 BD D0 29 17 71 86 1A 54 B4 C2 85 A9 A3 DB 7A CA 6D 22 4A EA CD 62 1D B9 FB A2 2E D1 E9 E1 1D 75 BE D7 DC 0E CB 0A 8E 68 C2 FF 12 63 40 8D C8 08 DF FD 16 4B 11 67 74 CD 6B 9B 8D 05 41 1E D6 26 2E 42 9B A4 95 67 6B 83 98 DB 2F 35 D3 C1 B9 CE D5 26 36 F2 76 5E 1A 95 CB 7C A4 C3 DD AB DD BF F3 82 53
“`

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 next 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:

`BTR.sysdriver from the local` `MpEngine.dllresource section. If the DLL is unavailable (cannot be found) or the hard-coded RC4 key inside the DLL has changed, it falls back to an embedded driver version (the latest one confirmed to be supported).` `Random.sys) and writes the encrypted transaction payload directly into` `Random.sys:changelist. The feedback path is similarly set to` `Random.sys:Random.dat.` `BootClean.log), followed by any user-defined actions (e.g., file deletion, registry modification, etc.).` `trigger now` `NtLoadDriver.` `trigger boot` `Start=1(System) and Group` `Boot Bus Extenderto execute during the early boot phase, bypassing active EDR/AV protections.`

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.

`Start=0is Impossible`

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`):

“`
System Reserved EMS WdfLoadGroup Boot Bus Extender <– BTR.sys executes here (Start=1) … (23 Groups) … FSFilter Replication FSFilter Anti-Virus <– WdFilter (the Group is lower, but Start=0) FSFilter Undelete FSFilter Activity Monitor <– UCPD.sys (Start=1) … (24 Groups) … NDIS <– Network Drivers … (14 Groups) …
“`

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.

`2:45:28.3130411 AM–` `WdBoot.sys(Defender ELAM Boot Driver) loads.` `2:45:28.3130685 AM–` `WdFilter.sys(Defender Minifilter) loads.` `2:45:28.3130700 AM–` `Ntfs.sys(Filesystem) loads.`

**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.

`2:45:28.6353170 AM–` `mlrmqchs.sys` `2:45:28.6915450 AM–` `UCPD.sys(User Choice Protection Driver) loads.`

**Phase 2: User Mode Initialization (Start=2 Automatic / Start=3 Manual)**

The Service Control Manager ( **SCM**) begins starting services. This occurs significantly later.

`2:46:02.7308562 AM–` `MpDefenderCoreService.exeloads.` `2:46:02.9603201 AM–` `MsMpEng.exe(Defender Service) loads.` `2:49:23.4912735 AM–` `WdNisDrv.sys(Network Inspection Driver) loads.`

By exploiting this load order gap, `BTR.sys` functions as a potent neutralizer for security solutions, including Microsoft Defender and potentially third-party EDRs.

`WdFilteris already loaded, the absence of the user-mode service (` `MsMpEng.exe) renders it susceptible to “legal” operations performed by a signed Microsoft kernel driver. Tests confirmed the successful deletion of example protected binaries such as` `WdFilter.sys,` `MsMpEng.exeand` `WdNisDrv.sysduring boot. Since the` `MsMpEng.exeservice binary is removed` `BTR.sys, operating in kernel mode, successfully deleted critical Service Registry keys (e.g.,` `HKLMSYSTEMCurrentControlSetServicesWdFilter) during runtime. This “blinds” the OS, preventing the` `WdFilter.sysdriver from loading on the subsequent reboot.` `WdBoot.sys) protects the initial boot chain, its role is limited to evaluating boot-start drivers during early initialization.` `BTR.sysexecutes in this post-ELAM environment (` `Start=1), meaning it is not evaluated by ELAM-related boot-driver checks. Furthermore, even if this architectural gap did not exist,` `BTR.syscarries a valid Microsoft signature, meaning it would normally pass signature enforcement, though this does not guarantee permanent trust or classification as “Known Good” in all contexts.`

**Conclusion:** The `BTR.sys` driver, when manually staged to execute at the next 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:

`mimidrv.sys– part of the Mimikatz post-exploitation tool) and modify Defender registry keys using standard Administrator privileges. Both actions are immediately blocked by Windows Defender and Tamper Protection.` `trigger nowmode, we instruct the` `BTR.sysdriver to delete the Service Registry keys for the Defender Kernel Filter and the Antimalware Service. Since the operation originates from a signed Microsoft kernel driver, Tamper Protection is successfully bypassed.`

“`
BTR_CLI.exe -chain -item “4|HKLMSYSTEMCurrentControlSetServicesWdFilter” -item “4|HKLMSYSTEMCurrentControlSetServicesWinDefend” -trigger now
“`

`trigger bootmode, we schedule the physical deletion of the Defender binaries (` `WdFilter.sysand` `MsMpEng.exe). These operations execute during the “`

“`
BTR_CLI.exe -chain -item “1|C:WindowsSystem32driverswdWdFilter.sys” -item “1|C:ProgramDataMicrosoftWindows DefenderPlatform4.18.26010.5-0MsMpEng.exe” -trigger boot
“`

`mimidrv.sysis then extracted without detection. Finally, we demonstrate an arbitrary write primitive by moving the malicious driver into the protected` `System32driversdirectory using the` `BTR.sysdriver.`

“`
BTR_CLI.exe -a 3 -s “C:UsersadminDesktopmimidrvmimidrv.sys” -d “C:WindowsSystem32driversmimidrv.sys”
“`

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**.

`BTR.sysis its reliance on Alternate Data Streams for configuration. Sysmon telemetry (Event ID 15) captures this behavior with high fidelity.` `:changeliston the driver file. Sysmon captures the encrypted RC4 payload directly in the` `Contentsfield.` `BTR_CLI` `Random.sys:Random.dat).` `MpEngine.dll` `C:ProgramDataMicrosoftWindows DefenderScansRebootActions.` `FileCreateStreamHash(Event ID 15) where` `TargetFilenameends in` `.sys:changelist. Secondarily, alert on` `.datstreams created on` `.sysfiles (specific to current PoC tool).` `BTR.sysexecutes actions, for example,` `Imageperforming the deletion is recorded as` `System(PID 4), not the user-mode tool that triggered it.` `System(PID 4) deleting arbitrary files (especially security binaries) immediately following a` `DriverLoad(Event ID 6) of a binary matching the` `BTR.syshash.` `BTR.sysis dropped and registered by legitimate Windows Defender processes (e.g.,` `MsMpEng.exe).` `DriverLoad(Event ID 6) where the` `Signatureis` `Microsoft Windowsand the` `Hashesmatch known` `BTR.sysversions, but the` `ParentImageor` `Imageresponsible for dropping the file is outside the Defender ecosystem (e.g.,` `cmd.exe,` `powershell.exe, or unknown binaries).` `MpEngine.dll` `CreateServiceW. This generates standard Windows Event Logs (e.g., System Event ID` `7045– A service was installed).` `BTR_CLI` `HKLMSYSTEMCurrentControlSetServices{Random}) and calls the undocumented` `NtLoadDriversyscall. This bypasses SCM, meaning Event ID` `7045will` `RegistryEvent(Event ID 12/13) creating a service key where the` `Argsvalue contains` `:changelistand` `Groupis set to` `Boot Bus Extender, especially if unaccompanied by a standard Service Installation event.` `SystemRootTempBootClean.logby the` `System(PID 4) process. This log creation is hardcoded in the driver and occurs regardless of the caller.` `BTR.sysfundamentally relies on the attacker possessing` `SeLoadDriverPrivilege. Enforcing the principle of least privilege and strictly monitoring the assignment and usage of this right is the primary defense.` `BTR.sys. Defense-in-depth must include monitoring the`

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.