A security research firm has identified a method to repurpose a legitimate, Microsoft-signed Windows Defender component, BTR.sys, into a kernel operation primitive, potentially allowing attackers to execute arbitrary file and registry operations from Ring 0. This technique, dubbed "BTR Reforged," does not rely on traditional exploits, vulnerabilities, or memory corruption, but rather on the intended functionality of the Boot-Time Removal driver.
The BTR.sys driver is a "one-shot" component embedded within MpEngine.dll, a core part of Windows Defender. It is deployed with a randomized filename (e.g., `mzqnjtaq.sys`) to `System32\drivers` only when a Defender remediation action, such as deleting a locked file, requires a system reboot. Upon loading, it performs a list of predefined transactions, reports its status, and then requests self-unloading.
Researchers initially encountered BTR.sys during an incident response investigation where its behavior, including a randomized filename, a transient service entry, RC4 encryption, interaction with an Alternate Data Stream (ADS) named `:changelist`, and self-cleanup, resembled attacker tradecraft. While the activity was ultimately confirmed as legitimate Windows Defender remediation, the discovery prompted a deeper analysis of the driver's undocumented functionality.
The BTR.sys driver does not expose a standard IOCTL interface. Instead, it reads its configuration from a file path specified in the `Args` value of its service registry key (e.g., `HKLM\SYSTEM\CurrentControlSet\Services\{Random}\Args`). This path points to an Alternate Data Stream, such as `C:\Windows\system32\drivers\BTR.sys:changelist`, which contains RC4-encrypted binary data.
The configuration blob is protected by both encryption and integrity checks. The encryption uses an RC4 stream cipher with a hard-coded 256-byte key embedded in the driver's `.rdata` section, which appears consistent across different BTR.sys versions. For integrity, the driver employs a modified CRC-32 algorithm, specifically the bitwise inverse of a standard CRC-32 (~CRC32), resetting the CRC register for each individual structure within the configuration to prevent chaining manipulation.
The RC4-decrypted configuration is a serialized list of actions, or "transactions." Researchers fully reverse-engineered this structure, despite the absence of a public PDB for BTR.sys. The configuration begins with a 24-byte Global Header containing a magic value (`0xFEE1DEAD`), a version number (`0x00000002`), a payload offset (`0x00000010`), a ~CRC32 of the header, and a `TransID` composed of the ~CRC32 and size of the payload.
A research tool, BTR_CLI, has been developed to construct valid encrypted transactions and safely exercise the driver's functionality. This tool demonstrates how the legitimate remediation component can be transformed into a universal kernel operation engine, potentially serving as an EDR/AV bypass technique by leveraging a trusted, Microsoft-signed driver instead of typical Bring Your Own Vulnerable Driver (BYOVD) methods.
The findings highlight how trusted security infrastructure can inadvertently expose powerful primitives, raising concerns for defenders about similar patterns potentially existing in other signed remediation components. The research combines reverse engineering, kernel internals, and detection engineering to illustrate how defensive technology can be repurposed into offensive capability.
