Microsoft Defender’s Cleanup Driver Can Become the Tool That Removes Defender.
Microsoft Defender contains a signed kernel driver built for the jobs malware tries hardest to prevent: deleting locked files and registry entries before Windows security services are fully running. Check Point Research has shown that an attacker who already controls a machine can give that driver a different removal list and use it against Defender itself.
This is not a new remote entry point, nor is it a zero-day that turns an ordinary user into SYSTEM. The technique, named BTR Reforged, requires an administrator account able to exercise SeLoadDriverPrivilege. That is a substantial prerequisite. It is also not a reason to dismiss the research with “the attacker is already admin”. Modern endpoint protection is designed specifically to remain difficult to disable after an account or endpoint has been compromised. BTR Reforged demonstrates a built-in route across that last defensive boundary.
The uncomfortable part is not that Microsoft shipped another vulnerable third-party driver. No third-party driver is needed, and the research does not depend on a conventional software flaw. The component is Microsoft-signed, supplied with Defender and performing operations that closely resemble its intended purpose.
The cleanup mechanism was already inside Defender
BTR.sys is Microsoft Defender’s Boot Time Removal Tool driver. Defender uses it when malicious files, drivers or registry entries cannot be removed safely while Windows is running. Rather than continue fighting a process that has already loaded and protected its files, Defender can schedule the remaining work for the next restart.
The driver is not normally left sitting on disk under a predictable name. It is embedded inside Defender’s MpEngine.dll as the BOOTTIMETOOL resource, extracted when needed, given a randomised name and removed after the operation. It runs in kernel mode and can act during an early part of the boot process, when the filesystem is writable but many user-mode services have not yet started.
Check Point researcher Jiří Vinopal reverse-engineered the undocumented transaction protocol used to tell the driver what to do. The work covered 18 signed 64-bit builds spanning Windows 7 through a fully updated Windows 11 25H2 system. Across those builds, the configuration data was RC4-encrypted with the same hard-coded 256-byte key.
Once the format and key were understood, the driver no longer had to receive instructions created by Defender. A separate program could construct a valid transaction and ask the trusted driver to perform the same kernel-level operations against different targets.
BTR Reforged reproduces Defender’s own staging process
The proof-of-concept tool released with the research, BTR_CLI, reproduces the pipeline Defender uses to stage a boot-time cleanup. It extracts the driver, builds the encrypted transaction, writes the configuration into an NTFS alternate data stream named :changelist, creates the required service configuration directly in the registry and then triggers the operation immediately or schedules it for the next boot.
The driver exposes primitives for deleting files and directories, moving files, deleting registry keys and values, and writing new registry values. These actions execute from Ring 0 and appear in telemetry as activity performed by the Windows System process.
The boot-time option is the important part. Vinopal calls the interval after the filesystem becomes writable but before Defender’s user-mode services start the golden window. During that interval, security binaries that would normally be protected or locked can still be physically removed.
In the demonstration presented at Black Hat USA 2026, the technique removed Defender components from a fully updated Windows 11 25H2 system with Defender features and Tamper Protection enabled. Files including WdFilter.sys and MsMpEng.exe were targeted before they could start and protect themselves.
The result is not merely a changed setting or a temporarily stopped service. The security stack can be structurally removed during boot by a driver signed and trusted by Microsoft.
The prerequisite is serious, but so is the outcome
BTR Reforged requires administrative access and SeLoadDriverPrivilege, the Windows user right used to load or unload device drivers. An attacker who has reached that point already has significant control of the endpoint and may have several other ways to damage it.
That limits the technique’s role. It is not initial access and it is not a privilege-escalation path from an unprivileged user. It is a post-compromise security-control removal technique.
The distinction matters because “administrator” is not supposed to mean “can silently erase every defensive control without consequence”. Tamper Protection, protected processes, kernel components, application control and EDR self-protection exist because organisations assume that credentials and local administrator sessions may eventually be compromised. Their job is to make the next step harder, noisier and less reliable.
BTR Reforged gives an attacker who already holds the required privilege a signed, built-in mechanism for taking that next step. In a ransomware intrusion, espionage operation or hands-on-keyboard attack, removing endpoint visibility before deploying the final payload can materially change the outcome.
Why this is not a normal CVE story
The public BTR_CLI repository says the research was reported to the Microsoft Security Response Center on 21 February 2026. According to the researcher, MSRC declined immediate servicing because the technique depends on pre-existing administrative privilege and SeLoadDriverPrivilege. The repository also states that no patch is planned.
As of 23 August 2026, Microsoft had not published a separate security advisory confirming the “no patch” wording. It is therefore more precise to treat that as the researcher’s account of the disclosure outcome rather than a standalone Microsoft announcement.
The absence of a CVE is not surprising. BTR.sys is not being exploited through a buffer overflow, use-after-free or exposed IOCTL that gives an attacker a capability the driver was never meant to have. The driver is being instructed to perform the privileged cleanup operations it was designed to perform, but with attacker-selected inputs.
That makes this an architectural trust-boundary problem. Traditional vulnerability handling asks whether software behaves incorrectly. BTR Reforged asks whether a trusted component can distinguish a legitimate Defender remediation request from an attacker reproducing the same workflow.
Why the normal BYOVD response does not fit
Security teams are familiar with Bring Your Own Vulnerable Driver, or BYOVD, attacks. An attacker brings a legitimate but vulnerable third-party driver onto a compromised system and abuses it to terminate protected processes, read or write kernel memory, or disable endpoint security.
BTR Reforged reaches a similar operational result through a different route.
| Control question | Conventional BYOVD | BTR Reforged |
|---|---|---|
| Where does the driver come from? | Introduced by the attacker, usually from a third-party vendor | Extracted from Microsoft Defender’s own engine |
| What is abused? | A vulnerability or overly permissive driver interface | Defender’s intended boot-time remediation protocol |
| Can a known-bad driver blocklist help? | Often, once the driver is identified and listed | Not cleanly; blocking BTR.sys would interfere with Defender’s legitimate remediation function |
| What should look unusual? | Arrival and loading of an unexpected signed driver | The context, configuration and sequence around a trusted driver |
| What privilege is needed? | Usually administrator or kernel-driver loading capability | Administrator plus SeLoadDriverPrivilege |
Microsoft’s vulnerable-driver blocklist and Windows Defender Application Control remain useful controls, but they do not solve this case. The binary is not an optional third-party component that can simply be denied. A control that blocks BTR.sys risks disabling the recovery function Defender uses for legitimate malware removal.
The detection problem therefore shifts from identifying an untrusted binary to identifying untrusted use of a trusted binary.
The published detection opportunities are behavioural
Check Point says it found no evidence that BTR.sys had been abused in this way in real-world attacks. That gives organisations an opportunity to build detections before the technique becomes routine attacker tooling.
The research highlights four useful behavioural signals:
- Sysmon Event ID 15: creation of a named data stream where the target ends in
.sys:changelist. This captures the encrypted configuration attached to the randomised driver file. - Sysmon Event IDs 12 or 13: creation or modification of a service registry key whose
Argsvalue references:changelistand whose group isBoot Bus Extender. The activity is more suspicious when there is no corresponding Windows Event ID 7045 for service installation, because the proof of concept writes the service configuration directly to the registry rather than using the Service Control Manager. - Sysmon Event IDs 11 and 23: rapid creation and deletion of
\SystemRoot\Temp\BootClean.logby theSystemprocess. The log path is hard-coded in the driver and may appear during legitimate use as well, so it needs context. - Sysmon Event ID 6 followed by Event ID 23: a driver load immediately followed by file deletion attributed to
Systemor process ID 4. This is the runtime execution sequence described in the research.
None of these events is a reliable verdict on its own. Defender legitimately uses BTR.sys, and a good detection must distinguish normal remediation from an unexpected service configuration, target list or execution sequence. The value comes from correlating the indicators, not from alerting on every occurrence of BootClean.log.
Organisations should also monitor the health of Defender and any other endpoint sensor independently of the endpoint itself. If a security service, kernel filter or sensor disappears after a restart, that should be treated as a security event rather than a routine agent fault. Sending relevant Windows and Sysmon telemetry off the host matters because local evidence is of limited value after the product collecting it has been removed.
What security teams should do now
There is no patch to deploy and no evidence of active exploitation, so this should not be handled as an emergency patching campaign. It should be handled as an endpoint-resilience and detection-engineering task.
First, review where SeLoadDriverPrivilege is assigned. Microsoft’s own guidance is blunt: the right should not be granted to any account, group or process that is not trusted to take over the system. Remove unnecessary assignments, review delegated administrative groups and avoid treating standing local administrator access as a normal user state.
Second, confirm that driver-load, registry and file-delete telemetry is actually collected from the Windows systems that matter. A detection design based on Sysmon event IDs is useless where Sysmon is absent, filtered too aggressively or retained only on the endpoint.
Third, build and test the correlations published by Check Point. The test should include a fully isolated laboratory system and should verify both the alert and the response process. The objective is not simply to prove that the public tool works. It is to find out whether a Defender removal attempt would be visible before and after reboot, whether the SOC would recognise it, and whether the host would be isolated quickly enough to matter.
Fourth, treat endpoint-agent health as security telemetry. Unexpected loss of WdFilter, WinDefend, MsMpEng.exe or another EDR component after restart should create a high-priority investigation, particularly when preceded by administrative activity or an unusual driver-load sequence.
Finally, keep watching for Microsoft and vendor guidance. The lack of a conventional patch today does not prevent Microsoft from changing the transaction protocol, strengthening request validation, rotating keys, improving telemetry or altering Defender’s boot-time design later.
Trusted code is not the same as trusted behaviour
BTR Reforged does not mean that every Defender endpoint can be remotely stripped of protection. An attacker must first obtain administrative control and the right to load a driver. Those conditions are material and should stay prominent in any risk assessment.
The research does show why those conditions cannot be the end of the analysis. Once they are met, a component trusted because it belongs to the security product can be turned into the mechanism that removes that product. Driver signatures, blocklists and tamper protection do not answer the more difficult question of whether a legitimate component is acting on legitimate instructions.
Security architecture often treats provenance as a proxy for intent: Microsoft-signed means trusted, built into Defender means defensive, and activity by System means expected. BTR Reforged breaks that chain of assumptions.
The defensive response is not panic and it is not another blind blocklist entry. It is tighter privilege control, boot-time visibility, off-host telemetry and behavioural detection around the use of trusted components.
The most useful offensive capability on a Windows endpoint may not need to be installed at all.
Sources and further reading
- Check Point Research: Day 2 at Black Hat – BTR Reforged
- Jiří Vinopal / Check Point Research: BTR_CLI proof of concept and technical notes
- The Hacker News: Microsoft Defender’s Own Driver Can Be Weaponized to Delete Security Software at Boot
- Microsoft Learn: Load and unload device drivers
- Microsoft Learn: Sysmon events and configuration
