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

Research by: Jiří Vinopal (@vinopaljiri)

Abstract

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.

Introduction

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:

Value Name	Value Type	Data
Type	REG_DWORD	1 (Kernel Driver)
Start	REG_DWORD	1 (System Start)
ErrorControl	REG_DWORD	0 (Ignore)
ImagePath	REG_EXPAND_SZ	\\??\C:\Windows\system32\drivers\mzqnjtaq.sys
Group	REG_SZ	Boot Bus Extender
Args	REG_SZ	C:\Windows\system32\drivers\mzqnjtaq.sys:changelist

At first glance, several characteristics resembled attacker tradecraft:

• A randomly named driver dropped shortly before reboot
• Creation of a transient service entry for loading it
• Presence of RC4 encryption routines
• Interaction with an Alternate Data Stream (:changelist) attached to the driver file
• Self-cleanup behavior after execution

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.

Technical Analysis: The BTR Driver

Driver Overview

• Filename: BTR.sys

• 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).

• Behavior: It is a “one-shot” driver. It loads, performs a list of transactions, reports status, and immediately requests self-unloading.

The Configuration Mechanism

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.

• Registry Path: HKLM\SYSTEM\CurrentControlSet\Services\{Random}\Args