The problem
We are told that Microsoft-signed drivers are the gold standard of trust in Windows. If a driver carries a valid signature from Redmond, the operating system lets it load, and security tools treat it as a trusted component.
But this week, that assumption took a heavy hit.
Check Point Research published a detailed disclosure showing that Microsoft Defender’s own signed remediation driver, BTR.sys (the Boot-Time Removal tool), can be completely repurposed by attackers. With local administrator access, you don’t need a fancy zero-day exploit, memory corruption, or a Bring Your Own Vulnerable Driver (BYOVD) technique to bypass endpoint detection and response (EDR) software. You can just instruct Defender’s own driver to perform arbitrary kernel-level (Ring 0) file and registry operations for you.
The driver wasn’t designed to help hackers. It was designed to clean up locked malware files on reboot, but its built-in design primitives make it a perfect, signed delete key for whatever security software is standing in an attacker’s way.
What is BTR.sys?
To understand how this happens, you have to look at how Microsoft Defender handles stubborn malware. When Defender finds a malicious file or registry key that is locked by an active process, it cannot always delete it on the spot. Instead, it schedules a reboot-time cleanup.
This is where BTR.sys comes in. The driver is not permanently sitting in your System32\drivers folder. Instead, it is embedded as a portable executable (PE) resource inside Defender’s core engine, MpEngine.dll.
When Defender decides a reboot is required to finish a cleanup, it extracts BTR.sys to disk under a randomized name (like mzqnjtaq.sys) and creates a temporary system service. Because it runs during early boot, the driver can delete locked files and clean up registry keys before the malware process has a chance to start and lock them again. Once the reboot is finished and the cleanup is done, the driver unloads and deletes itself.
Forging the changelist: How the bypass works
The driver doesn’t use standard IOCTLs (Input/Output Control) to receive instructions. Instead, it gets its configuration from a file path stored in the registry under its service key’s Args value.
That file path points to an Alternate Data Stream (ADS) attached to the driver file itself, named :changelist (for example, mzqnjtaq.sys:changelist). This stream contains an encrypted binary configuration blob.
Check Point researcher Jiří Vinopal reverse-engineered the driver and found that the configuration blob is protected by two main mechanisms:
- A hardcoded RC4 key. The driver decrypts the configuration using a static, 256-byte RC4 key embedded in its
.rdatasection. This key has remained identical across every version ofBTR.sysshipped over the last 15 years. - A modified CRC-32 checksum. To prevent tampering, the driver validates the configuration using a custom CRC-32 routine. It uses the standard polynomial (
0xEDB88320) and initialization (0xFFFFFFFF), but skips the final bitwise inversion (XOR) step.
By reverse-engineering these checks, researchers were able to write a tool called BTR_CLI that constructs valid, encrypted transaction headers and payloads. The driver accepts these forged transactions without complaint.
The transaction format supports six distinct Action IDs:
- Action 1 (Delete File): Kernel-level deletion that bypasses exclusive file locks.
- Action 2 (Delete Directory): Removes empty directories.
- Action 3 (Move / Quarantine): Moves a file. If the destination is empty, it acts as a delete. If valid, it allows arbitrary file writes (like dropping a malicious DLL into
System32). - Action 4 (Delete Key): Deletes a registry key and its subkeys.
- Action 5 (Delete Value): Deletes a registry value. The driver parses this by searching for a double backslash (
\\) to split the key from the value name. - Action 6 (Set Value): Arbitrary registry write and creation, which can be used to set up persistence or disable security policies.
The early boot “Golden Window”
You might wonder why an attacker would wait for a reboot instead of just running their commands immediately. The answer lies in the Windows boot sequence and what researchers call the “Golden Window.”
While standard security drivers load at Start=0 (Boot Start) to monitor the system from the earliest possible moment, BTR.sys has a limitation: it cannot run at Start=0. It performs file I/O (reading its configuration stream and writing logs) directly inside its DriverEntry routine. During Phase 0 of boot, the storage stack isn’t fully ready, and the SystemRoot symbolic link doesn’t exist yet, causing an immediate crash if forced to load that early.
Instead, the driver loads at Start=1 (System Start) and is assigned to the Boot Bus Extender load order group. This group executes at the very beginning of Phase 1, immediately after the filesystem (Ntfs.sys) initializes.
This timing is strategic. While early-launch anti-malware (ELAM) and basic filters are loaded, the heavy-duty user-mode security services (like Defender’s MsMpEng.exe) don’t start until Phase 2, which happens roughly 34 seconds later.
During this 34-second gap, the filesystem is fully writable, but the active intelligence of your security suite is dormant. Because BTR.sys is a signed Microsoft driver, it can delete protected security binaries (like WdFilter.sys or MsMpEng.exe) or modify critical registry keys before the security software is even running to defend itself. By the time the Service Control Manager attempts to launch the antivirus, its files are already gone.
The awkward part: Why Microsoft won’t patch it
When Check Point reported these findings to the Microsoft Security Response Center (MSRC), Microsoft declined to issue a patch. Their reasoning is a familiar one: the technique requires pre-existing administrative privileges (specifically, SeLoadDriverPrivilege) to stage the driver and write the registry keys. In Microsoft’s security model, once you are an administrator, the “admin-to-kernel” boundary is not considered a security boundary. If you already own the machine, you own the machine.
But this response overlooks the practical reality of modern security engineering. Administrators are regularly restricted by endpoint detection and response (EDR) agents and Tamper Protection. An attacker who has achieved local admin access still has to fight the security stack to maintain persistence or execute their payload.
This is what makes BTR.sys such a potent Living-off-the-Land Driver (LOLDriver):
- It cannot be blocked. Unlike third-party vulnerable drivers that get added to Microsoft’s Vulnerable Driver Blocklist,
BTR.sysis a core component of Windows Defender. If you block it, you break Defender’s ability to clean up real malware on reboot. - It is already on the machine. Attackers don’t need to bring their own driver (BYOVD) and risk triggering alerts for dropping known vulnerable drivers. They can just extract
BTR.sysfrom the localMpEngine.dllor use the one already sitting in the Defender engine. - It has a perfect signature. Because it is signed by Microsoft, it bypasses standard driver signature enforcement and application control policies (WDAC) without raising any red flags.
How to detect BTR.sys abuse
Since signature-based blocking is out of the question, defenders have to rely on behavioral detection. Fortunately, the way BTR.sys operates leaves highly specific, high-fidelity traces in your system logs.
If you are running Sysmon (System Monitor), here is what you should monitor:
- Alternate Data Stream (ADS) creation (Event ID 15). Legitimate Defender remediation and malicious tools both have to write the encrypted configuration payload to an ADS named
:changeliston the driver file (e.g.,Random.sys:changelist). Alert on anyFileCreateStreamHashevent where theTargetFilenameends in.sys:changelist. - Feedback stream anomalies (Event ID 15). Legitimate Defender usage writes its execution report to a standalone file inside a protected directory like
C:\ProgramData\Microsoft\Windows Defender\Scans\RebootActions\. Malicious tools likeBTR_CLIoften direct the driver to write the feedback report to a secondary stream on the driver itself (likeRandom.sys:Random.dat). Any.datstream created on a.sysfile is an immediate indicator of compromise. - Direct registry staging (Event ID 12 & 13). Legitimate Defender remediation uses the Service Control Manager (SCM) to register the driver, triggering a standard Windows Event ID
7045(A service was installed). Malicious tools often write the service keys directly to the registry (HKLM\SYSTEM\CurrentControlSet\Services\{Random}) and callNtLoadDriverto bypass the SCM entirely. Alert on registry events creating service keys where theArgsvalue contains:changelistand theGroupis set toBoot Bus Extenderwithout a corresponding7045event. - System-level file deletions (Event ID 23). When
BTR.sysdeletes files, the operation runs in Ring 0. Sysmon logs the file deletion, but attributes theImageperforming the deletion toSystem(PID 4). CorrelateSystem(PID 4) deleting files (especially security binaries inSystem32orProgramData) immediately following aDriverLoad(Event ID 6) of a binary matching theBTR.syshash. - Log file rapid creation and deletion (Event ID 11 & 23). The driver has a hardcoded behavior where it writes a log to
\SystemRoot\Temp\BootClean.log. Monitor for the rapid creation and subsequent deletion of this specific log file bySystem(PID 4).
At a broader level, you should also restrict administrative privileges. The abuse of BTR.sys fundamentally relies on the attacker possessing SeLoadDriverPrivilege. If you enforce strict least-privilege policies and monitor who has the right to load drivers, you cut off the attack before it can start.
