"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," Check Point Research wrote on August 20, 2026.
What Check Point Research disclosed
At Black Hat USA 2026 and DEF CON 34, Jiří Vinopal of Check Point Research presented a technique that uses Microsoft Defender's own boot-time remediation driver, BTR.sys, as a kernel-level offensive primitive. The research and a proof-of-concept tool named BTR_CLI were published on August 20, 2026. Check Point said the technique affects Windows 7 through Windows 11 25H2 and—crucially—requires no external driver and no software vulnerability to be exploited.
How the BTR Reforged technique works
BTR.sys is embedded inside Defender's MpEngine.dll as the BOOTTIMETOOL resource and is normally deployed to finish removing files or registry entries locked while Windows was running. Vinopal reverse-engineered the driver's proprietary, undocumented transaction protocol and found that each 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.
The BTR_CLI proof-of-concept locates MpEngine.dll under Defender's Definition Updates, extracts the embedded BTR.sys binary, constructs a valid encrypted transaction and installs the driver by writing service keys directly to HKLM with Type=1, Start=1 and Group="Boot Bus Extender." That installation method bypasses the Service Control Manager entirely and produces no Windows Event ID 7045 (Service Installed).
When loaded, BTR.sys executes queued operations from Ring 0 attributed to the System process (PID 4). Those operations can delete locked files and directories, move files into unconstrained paths including System32\drivers, delete registry keys and values, and write new registry values of any type. A second trigger mode schedules these actions for the next reboot. Vinopal described a "golden window" after the filesystem becomes writable but before Defender's user-mode services have started; in a live demo at Black Hat, BTR_CLI removed the entire Defender stack on a fully updated Windows 11 25H2 machine with Tamper Protection active.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildIndicators, detection controls and recommended hardening
Check Point Research published specific telemetry patterns that defenders can use to detect potential misuse:
- Sysmon Event ID 15 (FileCreateStreamHash) where the filename ends in ".sys:changelist", capturing the encrypted configuration Alternate Data Stream written to the driver file.
- Registry events (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.
- 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.
- Sysmon Event ID 6 (DriverLoad) immediately followed by Sysmon Event ID 23 (FileDelete) attributed to PID 4—the kernel-mode execution fingerprint of a live trigger.
As a primary hardening control, Check Point Research recommends restricting assignment of SeLoadDriverPrivilege. BTR_CLI requires an account with SeLoadDriverPrivilege and will auto‑enable that privilege for accounts that already hold it.
What this means for technologists, policymakers, and enterprises
Technologists and security teams should treat this as a detection and privilege-management problem: Check Point wrote that "the technique is currently unknown or unused by threat actors, making proactive detection engineering feasible before weaponization appears in the wild." The published indicators and the availability of the BTR_CLI proof-of-concept mean defenders can instrument Sysmon and registry monitoring and limit SeLoadDriverPrivilege ahead of any observed abuse.
Policymakers and regulators will note Microsoft's classification. The Microsoft Security Response Center (MSRC) told Check Point that the findings "do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges (SeLoadDriverPrivilege)." That servicing decision is now part of the public record associated with this research.
Affected enterprises and procurement leaders will have to accept that this attack path leverages a built‑in Windows component. Unlike bring-your-own vulnerable driver techniques that can be blocked via vulnerable-driver blocklists, BTR.sys is a required component and cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control without disrupting Defender itself.
Microsoft's response, patch posture and historical context
Check Point's paper notes that the research is an architectural issue rather than a traditional software flaw. Vinopal's GitHub repository for BTR_CLI includes the statement "No patch is planned"; Microsoft has not confirmed that characterization publicly. The Hacker News reported it contacted Microsoft and Check Point for comment; neither had responded by publication.
BTR.sys was previously examined in 2021 when SentinelLabs researcher Kasif Dekel disclosed CVE‑2021‑24092, a privilege escalation vulnerability that Microsoft patched on February 9, 2021. Dekel speculated then that the driver remained undiscovered because it is normally not present on disk until needed and then is purged away. The use of built‑in Windows drivers as kernel offensive primitives has precedents: Check Point cited FIN7's AvNeutralizer, which weaponized the ProcLaunchMon.sys driver alongside a Process Explorer driver to tamper with endpoint security software.
Check Point Research has published technical details and BTR_CLI; defenders now have known indicators and a narrow set of mitigations to apply. Whether those mitigations will be sufficient in practice—and whether Microsoft will change its servicing stance—remains to be seen.
