Research by: Jiří Vinopal (@vinopaljiri)AbstractWhat 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.IntroductionThis 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:Value NameValue TypeDataTypeREG_DWORD1 (Kernel Driver)StartREG_DWORD1 (System Start)ErrorControlREG_DWORD0 (Ignore)ImagePathREG_EXPAND_SZ\\??\C:\Windows\system32\drivers\mzqnjtaq.sysGroupREG_SZBoot Bus ExtenderArgsREG_SZC:\Windows\system32\drivers\mzqnjtaq.sys:changelistAt first glance, several characteristics resembled attacker tradecraft:A randomly named driver dropped shortly before rebootCreation of a transient service entry for loading itPresence of RC4 encryption routinesInteraction with an Alternate Data Stream (:changelist) attached to the driver fileSelf-cleanup behavior after executionThese 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.Technical Analysis: The BTR DriverDriver OverviewFilename: BTR.sysFigure 1: “BTR.sys” driver – Boot Time Removal Tool.Origin: Embedded as a PE resource within 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).Figure 2: “MpEngine.dll” with embedded “BTR.sys” as a PE resource.Figure 3: “MpEngine.dll” dropping “BTR.sys” from the embedded “BOOTTIMETOOL” resource.Behavior: It is a “one-shot” driver. It loads, performs a list of transactions, reports status, and immediately requests self-unloading.The Configuration MechanismThe 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.Registry Path: HKLM\SYSTEM\CurrentControlSet\Services\{Random}\ArgsFigure 4: “BTR.sys” initialization logic querying the “Args” service value to locate the configuration.Format: A file path to an Alternate Data Stream (e.g., C:\Windows\system32\drivers\BTR.sys:changelist) containing RC4-encrypted binary data.Figure 5: “MpEngine.dll” constructing the configuration path by explicitly appending the “:changelist” ADS.Cryptography & IntegrityThe configuration blob is protected by both encryption and integrity checks to prevent tampering.Encryption: RC4 Stream Cipher.Key: A hard-coded 256-byte key embedded in the .rdata section of the driver (this key appears to be consistent across various BTR.sys driver versions).Figure 6: “BTR.sys” RC4 decryption of configuration using a hard-coded 256-byte key in “.rdata”.Integrity: Modified CRC-32 (~CRC32).The driver uses the standard CRC-32 polynomial (0xEDB88320) and initialization (0xFFFFFFFF). However, it deviates from the standard implementation by omitting the final bitwise inversion (Final XOR) step. Consequently, the resulting value is mathematically equivalent to the bitwise inverse of a standard CRC-32 (denoted as ~CRC32 in the tables in the next section below).Independence: Integrity checks are non-cumulative. The CRC register is reset to the initial value (0xFFFFFFFF) for every individual structure (Global Header, Global Payload, Item Header, and Item Data). This design isolates the validation of each component, effectively preventing CRC chaining manipulation where modifying one structure could impact the validity of subsequent structures.Figure 7: “BTR.sys” CalcCRC32 function → ~CRC32(Buffer, Size).The Transaction StructureThe 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).Figure 8: Transaction Structure Format → The Configuration.Global Header (24 Bytes)The file starts with a fixed header that defines the session.OffsetSizeFieldDescription0x004Magic0xFEE1DEAD (Little Endian)0x044Version0x000000020x084PayloadOffset0x00000010 (Relative offset from this field to the Global Payload; constant)0x0C4GlobalCRC~CRC32 of the Header (with this field zeroed)0x108TransIDComposite ID: Low 4 bytes = ~CRC32(Payload), High 4 bytes = Size(Payload)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)};Global Payload (Variable)It immediately follows the header.Content: A null-terminated Unicode string.Purpose: The Feedback File path (e.g., \??\C:\ProgramData\...\mzqnjtaq.dat). The driver creates this file and writes a Transaction Execution Report. This report mostly mirrors the structure of the input configuration but updates the first 4 bytes of each Item’s Data payload ([Flags]) with the NTSTATUS code resulting from that specific operation.Item Structure (The Action)Following the Global Payload is a list of Operation Items.Item Header (16 Bytes):OffsetSizeFieldDescription0x004DataSizeSize of the Item Data (including padding)0x044ActionIDThe operation to perform (see Section below)0x084HeaderCRC~CRC32 of this header (calculated with this field zeroed)0x0C4DataCRC~CRC32 of the Item DataThe 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]Padding (Reserved Space): The driver requires exactly 4 null bytes appended to the end of the Item Data.Technical Note: This is not for alignment. For simple actions (like File Deletion) which lack a leading 4-byte [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 NTSTATUS code, avoiding memory reallocation.Weaponized Primitives (Action IDs)We have identified and implemented the following Action IDs in the BTR_CLI tool: File OperationsAction 1: Delete FileStructure: [Path]Effect: Kernel-level deletion. Bypasses exclusive file locks.Action 2: Delete DirectoryStructure: [Path]Effect: Removes an empty directory.Action 3: Move / QuarantineStructure: [Flags] [Source Path] [Dest Path]Effect: Moves a file.Weaponization: If Dest Path is empty, this acts as a Delete operation. If Dest Path is valid, this allows Arbitrary File Write/Move (e.g., dropping a malicious DLL into System32). Registry OperationsAction 4: Delete KeyStructure: [Flags] [Key Path]Effect: Deletes a registry key and its subkeys.Action 5: Delete ValueStructure: [Flags] [Key Path + "\\" + Value Name]Critical Finding: The driver parses the string by searching for a double backslash (\\) to split the Key from the Value. Standard paths fail; specific formatting is required.Figure 9: “BTR.sys” Action 5 – double backslash “\\” parser.Action 6: Set ValueStructure: [Flags] [Type] [Size] [Key Path + "\\" + Value Name] [Data]Effect: Arbitrary Registry Write + Registry Creation.Weaponization: Can be used to establish persistence (Run keys, Services) or disable security controls (Tamper Protection, EDR configs). Creates not only a value but possibly the registry key path itself.Operational Findings & Anti-ForensicsThe “Success” Error CodeA unique trait of BTR.sys is its return value upon successful execution. It returns 0xC0000056 (STATUS_DELETE_PENDING) instead of STATUS_SUCCESS.Figure 10: “BTR.sys” successful execution → STATUS_DELETE_PENDING.Reason: This signals the Windows Kernel to immediately unload the driver and mark the driver object for deletion, ensuring it does not persist in memory.Anti-Forensics (Log Cleaning)The driver creates a text log at \SystemRoot\Temp\BootClean.log.Figure 11: “BTR.sys” DriverEntry – “BootClean.log” file creation.Technique: The BTR_CLI tool automatically injects an Action 1 item at the start of the transaction list targeting BootClean.log.Result: The driver creates the log, performs the user’s action, and then deletes its own log file before unloading. This leaves minimal forensic traces.BTR.sys Driver VersionsTo 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.Figure 12: Winbindex search – “MpEngine.dll”.Extracting the embedded BTR.sys from these 12 MpEngine.dll versions resulted in 5 unique driver builds (based on distinct SHA-256 hashes).Figure 13: Unique “BTR.sys” drivers extracted from “MpEngine” dlls (Winbindex).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 53Furthermore, 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 Tool: BTR_CLIThe 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.Figure 14: The “BTR_CLI” tool – 6 stage pipeline.The tool performs the following sequence of operations:Driver Extraction: It automatically locates and extracts the legitimate BTR.sys driver from the local MpEngine.dll resource 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).Stealth Configuration (ADS): Instead of creating visible configuration files, the tool utilizes Alternate Data Streams (ADS). It generates a randomized filename for the driver (e.g., Random.sys) and writes the encrypted transaction payload directly into Random.sys:changelist. The feedback path is similarly set to Random.sys:Random.dat.Payload Construction: It constructs a custom RC4-encrypted payload containing the specific remediation instructions (the config). This includes calculating the correct CRC32 checksums and padding required by the driver to accept the configuration.Action Chaining: The tool supports chaining multiple operations into a single execution transaction. By default, it injects an anti-forensics action to delete its own log file (BootClean.log), followed by any user-defined actions (e.g., file deletion, registry modification, etc.).Service Creation & Triggering:Runtime Execution (trigger now): Creates a service with a randomized name and loads the driver immediately via NtLoadDriver.Boot Execution (trigger boot): Configures the service with Start=1 (System) and Group Boot Bus Extender to execute during the early boot phase, bypassing active EDR/AV protections.Cleanup: It automatically unloads the driver and removes all artifacts (Service Registry Key, Driver File, and ADS streams) after execution.Usage:Figure 15: The “BTR_CLI” tool – usage.Source Code: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 “Golden Window” of Opportunity: Exploiting the BTR.sys Driver for EDR/AV NeutralizationFigure 16: The “Golden Window” – Filesystem Ready & Security Stack Dormant.The Operational Constraint: Why Start=0 is ImpossibleThe 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.Load Order Analysis & Service Group PriorityThe 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 ReservedEMSWdfLoadGroupBoot Bus Extender