Security researchers at Check Point Research have disclosed a technique that turns a signed, built-in Windows boot-time remediation driver into a controllable kernel-level tool. In their analysis, the driver behind the method is a Microsoft Defender component—BTR.sys—which can carry out arbitrary file and registry operations during early boot, without exploiting a software flaw and without importing an external vulnerable driver.
The key requirement is significant: exploitation assumes an attacker already has administrator privileges, specifically the right SeLoadDriverPrivilege. Check Point Research did not find evidence that this approach has been used in real-world attacks at the time of publication, but they argue that detection engineering is still feasible before broader abuse appears.
What is BTR.sys and why it matters
BTR.sys (short for Boot Time Removal Tool) is part of the Windows Defender remediation flow. It’s embedded inside MpEngine.dll within the Defender installation and deployed when Defender needs to complete cleanup after a reboot—such as removing artifacts that were locked while Windows was running.
Because BTR.sys is a required Windows component shipped as part of Defender’s remediation mechanism, it is not a straightforward candidate for traditional mitigation approaches like adding the driver to Microsoft’s vulnerable driver blocklists. Blocking it through WDAC-style controls is also risky: doing so could disrupt Defender itself.
That combination—legitimacy, necessity, and early-boot execution—makes the disclosure particularly notable for defenders who rely on Windows’ security tooling being tamper-resistant.
Boot driver weaponization: capabilities at kernel level
Check Point Research describes the technique as boot driver weaponization because the driver can be steered to perform operations that go beyond what many defenders would expect from a self-contained cleanup module.
According to the research, when BTR.sys runs, it operates from Ring 0 and can process a queued set of actions. Those actions can include:
- Deleting locked files and directories
- Moving files to unconstrained destinations, including paths under System32\drivers
- Deleting registry keys and values
- Writing new registry values of varying types
Check Point Research also highlights a second execution mode in which the driver’s operations are scheduled for the next reboot. That matters because many defenders focus on behavior during a single session, while this technique can shift the most destructive operations to the next startup phase.
Why “golden window” execution gives attackers an edge
A major part of the risk is timing. The researchers describe an execution interval they refer to as the golden window: the period after the filesystem becomes writable but before Defender’s user-mode services have started.
In that window, BTR.sys can physically remove security binaries before they can lock themselves. The live demonstration reported in the disclosure showed BTR_CLI deleting the entire Defender stack on a fully updated Windows 11 25H2 system with Tamper Protection active.
In practice, this means an attacker leveraging boot driver weaponization doesn’t need to break Defender at runtime in the usual way. Instead, the removal can occur before the user-mode components that would normally enforce protections are fully up and running.
How the technique works (without exploiting a bug)
Check Point Research emphasizes that the method does not rely on a typical “find-and-exploit” software flaw, and it does not require importing a third-party signed vulnerable driver.
The driver uses a proprietary, undocumented transaction protocol. The researchers report two technical details that explain how the driver accepts work:
- RC4-encrypted configuration blobs: Every configuration blob passed to BTR.sys is described as RC4-encrypted using a 256-byte key that is hard-coded in the .rdata section of BTR.sys builds shipped since Windows 7. The researchers verified that this key content remained unchanged across 18 unique 64-bit versions.
- Embedded extraction via MpEngine.dll: The proof-of-concept tool locates MpEngine.dll under Defender definition updates and extracts the embedded BTR.sys binary.
After preparing a valid encrypted transaction, the tool installs the driver as a service. Notably, it uses direct registry writes to create the service entry with parameters such as Type=1, Start=1, and Group="Boot Bus Extender".
The researchers state this approach bypasses the Service Control Manager and does not generate a Windows Event ID 7045 entry that defenders commonly use to notice service installation activity.
Attribution and execution context
When BTR.sys loads, the driver executes queued operations and is attributed in telemetry to the System process with PID 4. From a detection perspective, that attribution can complicate triage: defenders can’t rely on the initiating process being an unusual userland binary.
Check Point Research also reports that exploitation requires an administrator account with SeLoadDriverPrivilege. Their proof-of-concept (BTR_CLI) reportedly auto-enables the privilege for accounts that already hold it.
The researchers contrast this with techniques that depend on bring-your-own-vulnerable-driver behavior, where attackers use known-vulnerable third-party signed drivers that can be blocked using driver blocklists.
Here, the primitive is built into every Windows installation from Windows 7 onward, which limits the effectiveness of mitigations based purely on blocklisting.
Microsoft response and “no patch planned” claims
After responsible disclosure, the disclosure indicates that the MSRC confirmation did not meet criteria for immediate servicing because the technique depends on pre-existing administrative privileges (SeLoadDriverPrivilege), rather than a traditional remotely exploitable vulnerability.
Additionally, the GitHub materials for BTR_CLI include a statement indicating that no patch is planned, and Microsoft has not publicly confirmed this position at the time of publication.
Because this issue is rooted in the trust model—administrative ability combined with a legitimate boot-time remediation driver—defenders should expect longer-term mitigation to focus on hardening and monitoring rather than a simple “update and forget” fix.
Related historical work on BTR.sys
Check Point Research notes that BTR.sys has been examined previously. In February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a privilege escalation issue that allowed a local non-administrator to overwrite arbitrary files by placing a hard link at the driver’s log path. Microsoft patched that issue on February 9, 2021.
The researchers assume that this earlier vulnerability stayed undiscovered because the driver is normally not kept on disk persistently. Instead, it is dropped and activated when needed under a random name and then purged away.
Detection ideas: Sysmon and Windows signals
To help organizations prepare for boot driver weaponization attempts, Check Point Research lists indicator conditions they associate with potential abuse of BTR.sys.
Examples include behavior observable with Sysmon and Windows event telemetry:
- Sysmon Event ID 15 (FileCreateStreamHash) where the target filename ends in .sys:changelist, capturing encrypted configuration written to an Alternate Data Stream on the driver file.
- Sysmon Registry events (Sysmon Event ID 12 or 13) that create a service key whose Args value contains :changelist, with Group="Boot Bus Extender". The researchers particularly call out cases where this is not accompanied by Windows Event ID 7045 (Service Installed).
- Sysmon Event ID 11 (FileCreate) and Event ID 23 (FileDelete) showing rapid creation and deletion of \SystemRoot\Temp\BootClean.log by the System process (PID 4), referencing a log path hard-coded in the driver that triggers regardless of the caller.
- Sysmon Event ID 6 (DriverLoad) immediately followed by Sysmon Event ID 23 (FileDelete), attributed to the System process (PID 4), representing the kernel-mode execution fingerprint of a live BTR.sys trigger.
As an overarching mitigation, Check Point Research recommends restricting assignment of SeLoadDriverPrivilege, treating that as a primary hardening control. Since exploitation requires that privilege already, tightening who can load drivers can reduce the attack surface dramatically.
Proof of concept availability
The research team published a proof-of-concept tool named BTR_CLI on GitHub under the MIT license. The repository includes prebuilt binaries for both x64 and x86 via its releases, along with instructions related to extracting the embedded driver and constructing a valid encrypted transaction.
While proof-of-concept code can accelerate defensive research, it also underscores why defenders should focus on monitoring and privilege hardening—especially around early-boot execution behavior.
Bottom line for defenders
This disclosure is a reminder that not all high-impact kernel actions come from newly discovered bugs. In this case, boot driver weaponization centers on a legitimate Defender boot-time remediation driver that can be repurposed if an attacker already controls the right privilege level.
Check Point Research states they found no evidence of real-world abuse of BTR.sys in the demonstrated manner. Still, the reported “golden window” execution timing, the ability to remove security components before user-mode services start, and the lack of reliance on third-party vulnerable drivers mean organizations should act now: review privilege assignments, strengthen logging visibility around early-boot driver loads, and test detection rules against the Sysmon and event patterns described in the research.
Source: https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
