Unlocking the Defender: How Check Point Researchers Turned Microsoft’s Own Boot-Time Remediation Driver into a Kernel Weapon

Executive Overview

At the Black Hat USA 2026 and DEF CON 34 conferences in Las Vegas, Jiří Vinopal, a threat researcher and reverse engineer at Check Point Research, unveiled a technique dubbed "BTR Reforged." This sophisticated attack method leverages Microsoft Defender’s own legitimately signed boot-time remediation driver—BTR.sys (Boot Time Removal Tool)—to perform arbitrary kernel-level file and registry operations.

Crucially, the technique exploits no software vulnerabilities and relies on no external drivers imported onto the target machine. Because BTR.sys is an essential, built-in component of the Windows ecosystem spanning from Windows 7 all the way to Windows 11 version 25H2, it cannot simply be added to Microsoft’s Vulnerable Driver Blocklist or blocked via Windows Defender Application Control (WDAC). Doing so would effectively cripple Microsoft Defender itself.

While Check Point Research has confirmed that telemetry and historical incident analysis show no evidence of real-world exploitation by threat actors, the implications are profound. BTR Reforged demonstrates that an attacker armed with administrative privileges can weaponize a native defensive tool to cleanly wipe security software stacks—including Tamper Protection-enabled Defender instances—while leaving virtually no standard forensic footprints behind.

Detailed Chronology: From Incident Response Mystery to Black Hat Briefing

The discovery of the BTR Reforged technique did not stem from theoretical academic research; rather, it was born out of the gritty realities of frontline incident response.

The Accidental Origin Story

According to Check Point Research’s published whitepaper, the investigation began during a routine incident response engagement on a compromised enterprise system. Analysts noticed highly anomalous endpoint telemetry that initially pointed toward sophisticated attacker persistence or tampering. However, deep-dive forensic analysis revealed a surprising twist: the suspicious activity was not malicious at all, but rather trace artifacts left behind by legitimate Windows Defender remediation workflows.

This unexpected encounter piqued the curiosity of researcher Jiří Vinopal. He began investigating how Defender handles remediation tasks that require touching files and registry keys locked down by the active operating system. This inquiry ultimately led him deep into the internal architecture of the core remediation engine.

Reverse-Engineering the Transaction Protocol

Vinopal’s deep dive focused on MpEngine.dll, the core scanning and remediation engine of Microsoft Defender. Embedded inside this DLL as a resource labeled BOOTTIMETOOL is the BTR.sys binary. This driver is deployed dynamically whenever Defender needs to clean up stubborn malware remnants—such as files locked during active Windows sessions—following a system reboot.

By reverse-engineering the proprietary, undocumented transaction protocol used by the driver, Vinopal made a critical discovery: every configuration blob passed to BTR.sys is protected via RC4 encryption. The decryption key—a static, 256-byte array—is hard-coded directly into the .rdata section of every BTR.sys build shipped since the days of Windows 7. Astonishingly, across 18 unique, analyzed 64-bit versions of the driver, this key remained entirely unchanged.

Development of BTR_CLI

To demonstrate the viability of this attack vector, Vinopal engineered BTR_CLI, a proof-of-concept (PoC) utility. Released publicly on GitHub under an MIT license on August 20, 2026, alongside the official research paper, BTR_CLI automates the exploitation chain:

1. It locates MpEngine.dll within the active Defender Definition Updates directory.
2. It extracts the embedded BTR.sys binary.
3. It constructs a valid, RC4-encrypted transaction payload tailored to the attacker’s desired file or registry modifications.
4. It bypasses the standard Windows Service Control Manager entirely to install the driver.

Live Demonstration in Las Vegas

During their main-stage briefings at Black Hat USA 2026 and DEF CON 34, Check Point researchers delivered a stark live demonstration. Running on a fully patched, up-to-date Windows 11 25H2 machine with active Tamper Protection, the BTR_CLI utility successfully orchestrated the complete surgical deletion of the entire Microsoft Defender security stack.

Technical Deep Dive: Mechanics of the Attack Vector

Understanding how BTR Reforged operates requires examining the deep kernel mechanics of Windows boot cycles and trust boundaries. The attack succeeds not because of a coding error, but because of how Windows natively establishes and trusts its boot-critical subsystems.

[Attacker with Admin Privileges]
       │
       ▼ (Extracts via BTR_CLI)
[MpEngine.dll / BOOTTIMETOOL] ──► [Extracts BTR.sys Binary]
       │
       ▼ (Direct HKLM Registry Writes)
[Bypass Service Control Manager (No Event ID 7045)]
       │
       ▼ (Ring 0 Execution - System Process PID 4)
[The "Golden Window"] ──► [Wipes WdFilter.sys & MsMpEng.exe before locks apply]

Evading the Service Control Manager

Typically, loading a driver into the Windows kernel requires interacting with the Service Control Manager (SCM), an action that reliably triggers Windows Event ID 7045 ("A service was installed in the system"). This event serves as a primary tripwire for enterprise Endpoint Detection and Response (EDR) platforms and security operation centers (SOCs).

BTR_CLI cleverly sidesteps this detection mechanism. Instead of calling standard SCM APIs, the tool installs the driver via direct registry manipulation under the HKLM hive, configuring the driver keys with:

• Type = 1
• Start = 1
• Group = "Boot Bus Extender"

Because the operating system treats this configuration as a native boot-start driver initialization during early startup phases, no Event ID 7045 is generated, blinding traditional log-monitoring heuristics.

Execution in the "Golden Window"

Once loaded, BTR.sys executes from Ring 0, operating under the authority of the privileged System process (PID 4). The driver can be triggered in two modes: executing immediately or scheduling operations for the subsequent system reboot.

When configured for reboot execution, BTR.sys operates during what Vinopal terms the "golden window." This is the narrow temporal interval that occurs after the underlying filesystem becomes readable and writable, but before Microsoft Defender’s user-mode and kernel-mode monitoring services (WdFilter.sys and MsMpEng.exe) have spun up and locked their own binaries.

During this golden window, BTR.sys possesses unfettered kernel primitive capabilities:

• It can physically delete locked system binaries and security filters.
• It can move arbitrary files into unconstrained, protected system paths such as System32drivers.
• It can surgically delete or modify sensitive registry keys, overriding standard access control lists (ACLs).

Prerequisites: The Administrative Barrier

It is important to note that BTR Reforged is not an unauthenticated remote code execution (RCE) vulnerability. Exploiting the technique requires an attacker to already possess an administrative context with SeLoadDriverPrivilege enabled. The BTR_CLI tool is designed to automatically check for this privilege and enable it if the compromised account already holds it.

While this prerequisite means an attacker must first breach the perimeter and escalate privileges to the local administrator level, it represents a devastating post-compromise maneuver. For advanced persistent threat (APT) actors or ransomware syndicates looking to blind security monitoring tools prior to deploying payload encryption, this technique offers a surgical bypass that renders EDR solutions inert.

Supporting Context & Metrics: BYOVD vs. BTR Reforged

To fully appreciate the architectural significance of Check Point’s discovery, it helps to examine how it compares to existing kernel exploitation trends.

Historical Precedents

The weaponization of native operating system components—as opposed to third-party signed drivers—is a rising trend among sophisticated threat groups. A notable historical parallel is FIN7’s AvNeutralizer tool, discovered in mid-2024, which weaponized legitimate Windows drivers like ProcLaunchMon.sys alongside Process Explorer drivers to tamper with endpoint protection software.

Furthermore, BTR.sys itself is no stranger to security scrutiny. Five years prior, in February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a local privilege escalation vulnerability within the very same driver. That flaw allowed non-administrator users to overwrite arbitrary files by placing hard links at specific driver log paths. Microsoft patched CVE-2021-24092 swiftly in February 2021. However, Dekel noted at the time that the driver largely remained hidden because it is normally absent from the hard disk, dropped dynamically with a random name only when remediation tasks are demanded, and purged immediately afterward.

The BTR Reforged technique takes this historical vulnerability concept a step further: it proves that even without software bugs or code execution flaws, the intended architectural design of the driver can be subverted if an adversary controls the configuration transaction blobs.

Official Statements and Industry Response

The disclosure of BTR Reforged has sparked intense debate within the cybersecurity community regarding the definition of software vulnerabilities versus architectural trust boundaries.

Microsoft Security Response Center (MSRC) Position

Following responsible disclosure protocols, Check Point Research submitted their findings to the Microsoft Security Response Center (MSRC). According to CPR’s published paper, Microsoft confirmed that the technique does not meet the criteria for immediate servicing or patching.

MSRC’s rationale centers on the prerequisite trust model: because the attack relies on pre-existing administrative privileges (SeLoadDriverPrivilege), Microsoft classifies it as operating within the bounds of an already compromised administrative trust boundary rather than a standalone security vulnerability. Vinopal’s GitHub repository for BTR_CLI mirrors this reality, noting bluntly under implementation details that "No patch is planned"—a stance Microsoft has not formally contested in public statements.

Check Point Research Assessment

Check Point’s analysts emphasized the proactive window of opportunity this disclosure provides. In their official statement, the research team noted:

"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."

By publicizing the technique at major industry conferences and releasing the BTR_CLI proof-of-concept code, Check Point aims to force defensive engineering teams to adapt their monitoring postures before cybercriminals adopt the primitive into their offensive toolkits.

At the time of publication, neither Microsoft nor Check Point Research representatives had provided additional comments to media inquiries regarding revised mitigation timelines.

Future Outlook and Defensive Recommendations

As the cybersecurity industry absorbs the reality of BTR Reforged, enterprise security architects must look beyond traditional patch management to safeguard their environments. Because Microsoft will not be issuing a software patch for BTR.sys—and because the driver cannot be added to driver blocklists without breaking core operating system functionality—defenders must adopt aggressive behavioral monitoring and privilege-hardening strategies.

1. Hardening SeLoadDriverPrivilege

The single most effective preventative control against BTR Reforged is restricting the assignment of SeLoadDriverPrivilege. By default, this user right is assigned strictly to members of the Administrators group. Enterprise security teams should audit Active Directory and local machine policies to ensure that this privilege is tightly controlled, monitored, and removed from any service accounts or non-standard user profiles.

2. Implementing Advanced Telemetry and Detection Rules

Because BTR_CLI bypasses the Service Control Manager and generates no Event ID 7045, SOC analysts must look for secondary indicators of abuse. Check Point Research and blue-team analysts recommend monitoring for:

• Suspicious File Extraction: Unusual file creation or read operations targeting MpEngine.dll definition update directories followed by the extraction of raw binary resources.
• Registry Manipulation: Direct modifications to registry hives concerning boot-start drivers outside of standard installation tooling.
• Boot-Start Anomaly Detection: Monitoring the exact parameters of drivers configured with Group = "Boot Bus Extender" during initialization phases.
• System Process Anomalies: Auditing unexpected file and registry modifications attributed directly to the System process (PID 4) during early boot stages.

3. Transitioning to Zero Trust and Out-of-Band Validation

Ultimately, BTR Reforged highlights a sobering truth of modern computing: if an attacker achieves kernel-level administrative access, they effectively own the machine. Therefore, enterprise defense strategies must embrace a robust Zero Trust architecture. Security stacks should rely on hardware-backed security (such as Virtualization-Based Security (VBS) and secured-core PCs), out-of-band telemetry monitoring, and immutable cloud-backed logging that cannot be wiped by local kernel primitives.

As threat actors continually look for creative ways to subvert native defenses, the discovery of BTR Reforged serves as a vital wakeup call for the industry. By understanding the mechanics of how trusted tools can be turned inward, defenders can build the behavioral tripwires necessary to stop tomorrow’s advanced attacks today.