A Microsoft-signed Defender cleanup driver can delete protected security binaries and registry keys before the antivirus service starts. Check Point researcher Jiří Vinopal demonstrated the effect on a fully updated Windows 11 25H2 system by turning the built-in BTR.sys remediation component into a kernel file-and-registry engine.
The technique needs an administrator with SeLoadDriverPrivilege. It is a post-compromise control bypass, rather than remote initial access or a memory-corruption exploit. Check Point found no real-world abuse. The company says Microsoft declined immediate servicing because an attacker must already hold administrative privilege.
Check Point is evaluating a Microsoft component in its own vendor research. It does not describe sponsored placement.
Defender cleanup accepts signed transactions
Defender embeds the one-shot boot-time removal driver as a resource inside MpEngine.dll. When legitimate remediation needs a reboot to remove a locked file, the engine drops the driver under a randomized eight-letter filename such as mzqnjtaq.sys, creates a temporary service, gives the driver a transaction list, and removes the artifacts after execution.
That transaction list sits in an alternate data stream named :changelist. The blob uses RC4 with a hard-coded 256-byte key and modified CRC-32 checks. Once decrypted, it describes numbered actions: delete a file or directory, move a file, delete a registry key or value, or set a registry value. Check Point reproduced the format in a research tool that can construct valid transactions without exploiting a software flaw.
The researchers found 18 distinct signed 64-bit driver versions. All accepted the same transaction structure and key. Their tool worked across tested systems from Windows 7 build 7601 through Windows 11 25H2 as of July 2026.
The investigation began with an important false lead. On a compromised host, a random driver name, an encrypted alternate data stream, and self-cleanup looked like attacker tradecraft. Reverse engineering showed that this activity came from legitimate Defender remediation. The same resemblance makes isolated artifacts weak evidence of abuse.
Boot order opens the gap
The strongest effect arrives during a narrow boot interval. BTR.sys cannot run as a phase-zero Start=0 driver because it needs the filesystem and SystemRoot path. A staged service instead uses Start=1 and the Boot Bus Extender group, which runs early in phase one after NTFS is ready.
Figure details
The timeline begins in phase zero, where WdBoot.sys, WdFilter.sys, and Ntfs.sys load within microseconds of one another. Phase one begins about 322 milliseconds later, when the test copy of BTR.sys loads in the Boot Bus Extender group and performs file or registry transactions before UCPD.sys. User mode starts roughly 34 seconds later with MpDefenderCoreService.exe and MsMpEng.exe. WdNisDrv.sys loads on demand almost four minutes after the BTR transaction. The figure distinguishes the demonstrated boot interval from a vulnerability or an initial-access path.
Check Point’s Procmon trace placed the test driver at 2:45:28.6353170 AM. MsMpEng.exe started at 2:46:02.9603201 AM, about 34 seconds later. The network inspection driver appeared almost four minutes after the BTR operation.
During that interval, the signed kernel driver deleted test copies of WdFilter.sys, MsMpEng.exe, and WdNisDrv.sys. It also removed HKLM\SYSTEM\CurrentControlSet\Services\WdFilter and the WinDefend service key, bypassing user-mode Tamper Protection. Early Launch Anti-Malware had already run, but the Microsoft signature and intended driver behavior left no conventional vulnerable-driver decision for the blocklist to make.
This scope matters. An attacker must first gain administrative control and load the driver. Check Point reported: “We did not observe evidence of real-world abuse of BTR.sys in the manner demonstrated in this research.” Its telemetry did not quantify exposed endpoints, attacks, or victims.
Legitimate cleanup has a lineage
The useful recognition point is the sequence around the driver. Legitimate Defender remediation originates from Defender processes such as MsMpEng.exe, creates the service through the Service Control Manager, and writes feedback under C:\ProgramData\Microsoft\Windows Defender\Scans\RebootActions\.
The published proof of concept behaves differently. It creates the service registry keys directly, invokes NtLoadDriver, assigns Group to Boot Bus Extender, and places both configuration and feedback streams on the driver. The configuration name ends in .sys:changelist; its current feedback stream resembles .sys:Random.dat. Direct registry creation can produce Sysmon events 12 and 13 without the System event 7045 that normally records service installation.
The driver itself produces more context. Sysmon event 6 records its load. File deletion appears as System process ID 4 in event 23. The driver creates \SystemRoot\Temp\BootClean.log; the proof of concept schedules that log for deletion before unloading, producing a rapid event 11 and event 23 pair. Successful driver execution returns 0xC0000056 (STATUS_DELETE_PENDING) as it unloads.
A random signed .sys file or :changelist stream can belong to normal cleanup. Confidence rises when non-Defender lineage, direct service-key writes, early-boot grouping, security-file deletion, and self-cleanup occur together.
Correlate the BTR sequence
Collect Sysmon events 6, 11, 12, 13, 15, and 23 plus System event 7045 across the reboot boundary. Search for [a-z]{8}.sys, .sys:changelist, .sys:*.dat, Boot Bus Extender, \SystemRoot\Temp\BootClean.log, and service Args values beneath HKLM\SYSTEM\CurrentControlSet\Services\ that point to :changelist. Retain the parent or dropping process, driver signature and hash, service creation method, target files, and registry paths.
Prioritize cases where cmd.exe, powershell.exe, or an unknown process stages a Microsoft-signed driver outside the Defender process tree. Correlate a driver load with PID 4 deletion of security files, changes to WdFilter or WinDefend, and absence of event 7045. Signature allowlisting and the vulnerable-driver blocklist alone cannot distinguish intended remediation from a valid BTR transaction.
Use a controlled remediation event as the verification test. The expected result is a BTR driver created by a Defender process through the Service Control Manager, a :changelist configuration stream, feedback in Defender’s RebootActions directory, event 7045, and no deletion of Defender binaries or service keys. A sequence that instead uses direct registry staging, the Boot Bus Extender group, feedback on the driver, and PID 4 deletion of security controls warrants incident scoping around the administrator session and the preceding compromise.
The driver is already trusted, so the decisive evidence is who staged its transaction and what the kernel changed. Defenders who retain the reboot boundary can separate cleanup from control neutralization. Teams that record only the signed load discard the part of the story that establishes intent.