Check Point Research has disclosed a technique that uses Microsoft Defender's own legitimately signed boot-time remediation driver to perform arbitrary kernel-level file and registry operations on Windows systems ranging from Windows 7 through Windows 11 25H2, with no software flaw exploited and no driver imported from outside the machine.
The driver, BTR.sys (Boot Time Removal Tool), is a required Windows component, which means it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control (WDAC) without disrupting Defender itself.
Jiří Vinopal, a threat researcher and reverse engineer at Check Point Research, presented the findings as a main-stage briefing at Black Hat USA 2026 and DEF CON 34 in Las Vegas and published the accompanying research paper alongside a proof-of-concept tool, BTR_CLI, on August 20, 2026. Check Point Research said it found no evidence the technique has been used in real-world attacks.
"During our analysis across all collected samples and telemetry sources, we did not observe evidence of real-world abuse of BTR.sys in the manner demonstrated in this research. This suggests the technique is currently unknown or unused by threat actors, making proactive detection engineering feasible before weaponization appears in the wild," Check Point Research said.
BTR.sys is embedded in Defender's MpEngine.dll
as the BOOTTIMETOOL
resource and is deployed when Defender must finish removing malware after a reboot, deleting files or registry entries that were locked while Windows was running.
Vinopal reverse-engineered the driver's proprietary, undocumented transaction protocol and found that every configuration blob passed to BTR.sys is RC4-encrypted with a 256-byte key hard-coded in the .rdata
section of every BTR.sys build shipped since Windows 7, verified unchanged across 18 unique 64-bit versions.
BTR_CLI, the proof-of-concept tool, locates MpEngine.dll
under Defender's Definition Updates and extracts the embedded BTR.sys binary.
The tool then constructs a valid encrypted transaction. It then installs the driver as a service via direct HKLM registry writes using Type=1
, Start=1
, and Group="Boot Bus Extender"
, a method that bypasses the Service Control Manager entirely and generates no Windows Event ID 7045 (Service Installed) entry.
When loaded, BTR.sys executes the queued operations from Ring 0, attributed in telemetry to the System process (PID 4), and can delete locked files and directories, move files to unconstrained paths including System32\drivers
, delete registry keys and values, and write new registry values of any type.
A second trigger mode schedules those operations for the next reboot.
The driver then executes during what Vinopal calls the "golden window," the interval after the filesystem becomes writable but before Defender's user-mode services have started, allowing BTR.sys to physically remove security binaries such as WdFilter.sys
and MsMpEng.exe
before they can lock themselves.
A live demonstration at Black Hat showed BTR_CLI deleting the entire Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection active.
Exploitation requires an administrator account with SeLoadDriverPrivilege
, which BTR_CLI auto-enables for accounts that already hold it.
Unlike attacks that rely on the bring your own vulnerable driver technique, which depend on known-vulnerable third-party signed drivers that can be added to blocklists, the BTR Reforged technique uses a driver built into every Windows installation from Windows 7 onward.
"The issue is not a vulnerability in the traditional sense, but rather an architectural trust boundary that can be crossed if an attacker already has administrative privileges. Following responsible disclosure, MSRC confirmed that these findings do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges (SeLoadDriverPrivilege)," Check Point Research said in the paper.
Vinopal's GitHub repository for BTR_CLI adds that "No patch is planned," a characterization Microsoft has not confirmed publicly.
BTR.sys was examined by security researchers for a different flaw in the same driver five years earlier.
In February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a privilege escalation vulnerability that allowed a local non-administrator to overwrite arbitrary files by placing a hard link at the driver's log path. Microsoft patched CVE-2021-24092 on February 9, 2021.
"We assume that this vulnerability remained undiscovered until now because the driver is normally not present on the hard drive but rather dropped and activated when needed (with a random name) and then purged away," Kasif Dekel said in the SentinelLabs disclosure.
The use of a built-in Windows driver as a kernel offensive primitive, rather than a third-party vulnerable one, was previously demonstrated in the context of FIN7's AvNeutralizer, which weaponized the Windows ProcLaunchMon.sys driver alongside the Process Explorer driver to tamper with endpoint security software.
Check Point Research said the investigation that produced these findings had an unusual origin.
"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," Check Point Research said in the paper.
Check Point Research has identified the following Sysmon and Windows event conditions as indicators of potential BTR.sys abuse -
- Sysmon Event ID 15 (FileCreateStreamHash) where the target filename ends in
.sys:changelist
, capturing the encrypted configuration Alternate Data Stream written to the driver file - RegistryEvent (Sysmon Event ID 12 or 13) creating a service key whose Args value contains
:changelist
and whose Group is "Boot Bus Extender," especially when unaccompanied by a Windows Event ID 7045 (Service Installed) entry - Sysmon Event IDs 11 (FileCreate) and 23 (FileDelete) logging the rapid creation and deletion of
\SystemRoot\Temp\BootClean.log
by the System process (PID 4), a log path hardcoded in the driver that fires regardless of the caller - Sysmon Event ID 6 (DriverLoad) immediately followed by Sysmon Event ID 23 (FileDelete) attributed to the System process (PID 4), the kernel-mode execution fingerprint of a live BTR.sys trigger
Check Point Research also recommends restricting the assignment of SeLoadDriverPrivilege
as the primary hardening control.
BTR_CLI is available at github.com/Dump-GUY/BTR_CLI under the MIT license, with prebuilt x64 and x86 binaries attached to the repository's releases.
The Hacker News contacted Microsoft for comment on its position regarding the BTR.sys technique and Check Point Research for additional technical detail; neither had responded by publication.
Facts Only
* Check Point Research disclosed a technique using Microsoft Defender's boot-time remediation driver (BTR.sys) for arbitrary kernel-level file and registry operations on Windows 7 through Windows 11 25H2.
* The driver, BTR.sys, is a required Windows component embedded in Defender's MpEngine.dll.
* Configuration data passed to BTR.sys is RC4-encrypted using a key hardcoded in every build since Windows 7.
* A proof-of-concept tool, BTRCLI, extracts BTR.sys and constructs encrypted transactions.
* BTRCLI installs the driver as a service via direct HKLM registry writes, bypassing the Service Control Manager.
* Execution in Ring 0 allows for deletion of locked files, movement to unconstrained paths, and modification of registry values.
* The technique exploits a "golden window" after filesystem writability is restored but before Defender user-mode services start.
* A live demonstration showed BTRCLI deleting the entire Defender stack on Windows 11 25H2 with Tamper Protection active.
* Exploitation requires SeLoadDriverPrivilege, which BTRCLI can enable for accounts that already possess it.
* The technique uses a built-in Windows driver rather than external vulnerable drivers.
* Indicators of abuse include specific Sysmon events related to file operations on .sys files and service key creation without standard service installation entries.
Executive Summary
Full Take
The mechanism described leverages an architectural trust boundary inherent in the operating system rather than exploiting a traditional software vulnerability, shifting the focus from flaw exploitation to privilege escalation within the existing trust model. The core insight is that the driver's presence and legitimate function create a high-trust kernel primitive exploitable through specific administrative privileges ($\text{SeLoadDriverPrivilege}$). This moves the defensive posture from patching known bugs (which Microsoft has already addressed) to engineering controls around established, trusted components.
The finding that no real-world abuse was observed suggests a significant gap between theoretical capability and practical weaponization. The research points toward an attack pattern where exploiting inherent administrative privileges is sufficient for control, implying that detection must focus on the anomalous interaction patterns—such as the specific sequence of Sysmon events involving file creation/deletion and driver loading—rather than signature matching on the executable code itself. The lack of a planned patch by Microsoft indicates that this represents a fundamental architectural trust issue within the Windows kernel's remediation framework, forcing defensive reliance onto behavioral anomaly detection at the system call or telemetry level.
What does this imply for agency is that hardening strategies must prioritize strict control over the assignment and use of $\text{SeLoadDriverPrivilege}$, treating it as the primary boundary condition rather than assuming successful exploitation can be prevented by standard exploit mitigation techniques alone. The research's emphasis on behavioral indicators suggests a paradigm shift toward monitoring system state transitions during critical operations, recognizing that kernel-level tampering, even with trusted components, generates unique temporal and file system footprints.
Bridge Questions: If the capability relies entirely on existing privileges, how can administrative segmentation effectively prevent the required privilege from being present in the first place? What is the long-term architectural stability of relying on behavior logging (Sysmon) to detect modifications to a kernel component that is intentionally embedded by the OS vendor? Is there an inherent risk in creating specialized tooling like BTR\CLI, even if it targets an undocumented mechanism?
Sentinel — Human
The text reads as a detailed journalistic report on specific cybersecurity research, characterized by deep technical citation and structured analysis, suggesting a high likelihood of human authorship or expert curation.
