Check Point Research disclosed on August 20, 2026 a technique that turns Microsoft Defender's own boot-time remediation driver, BTR.sys, into a tool for deleting security software before Windows finishes starting. No software flaw is exploited, and no outside driver is dropped onto the machine. The driver is already there, on every Windows install from Windows 7 through Windows 11 25H2. This analysis draws on reporting from The Hacker News.

Threat researcher Jiří Vinopal presented the work at Black Hat USA 2026 and DEF CON 34, along with a proof-of-concept tool called BTR_CLI. Check Point says it found no evidence the technique has been used in real attacks, which is the useful part of the timing for you.

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

What makes this hard to block is the driver's status. BTR.sys ships inside Defender's MpEngine.dll and is a required Windows component, so Microsoft cannot add it to the Vulnerable Driver Blocklist or block it through Windows Defender Application Control without breaking Defender itself. Traditional bring-your-own-vulnerable-driver attacks depend on third-party signed drivers that eventually land on a blocklist. This one does not have that expiry date.

The precedent for abusing built-in Windows drivers is real. FIN7's AvNeutralizer used the Windows ProcLaunchMon.sys driver together with the Process Explorer driver to tamper with endpoint security products, so the pattern of turning shipped, signed components against defenders is already in criminal hands.

Practical exposure depends on privilege. Running the technique requires an administrator account holding SeLoadDriverPrivilege, which means it is a post-compromise capability rather than an entry point. Microsoft's Security Response Center confirmed the findings do not meet its bar for immediate servicing for that reason. If an attacker reaches admin on one of your endpoints, they can remove the security agent that would otherwise report what happens next.

Attack Chain: From Legitimate Driver to Security Evasion

The attack chain starts with file extraction, not exploitation. BTR_CLI locates MpEngine.dll under Defender's Definition Updates directory and pulls the BOOTTIMETOOL resource out of it, recovering the BTR.sys binary that Defender normally drops with a random name and purges after use. Nothing is downloaded, and nothing unsigned touches disk.

Step two is the transaction blob. Vinopal reverse-engineered the driver's proprietary, undocumented transaction protocol and found that every configuration passed to BTR.sys is RC4-encrypted with a 256-byte key hard-coded in the .rdata section of the binary. That key has not changed since Windows 7 and was verified identical across 18 unique 64-bit builds, so an operator can craft a valid queue of file and registry operations without any interaction with Defender's user-mode components.

Business Impact: Undetected Persistence and Data Exfiltration Risk When the Defender stack is deleted during boot, your endpoint protection does not fail loudly. It simply is not there when Windows finishes starting. Files like WdFilter.sys and MsMpEng.exe are physically removed in the interval after the filesystem becomes writable but before Defender's user-mode services load, so the host comes up looking normal to a user and reports nothing to your console. Tamper Protection does not change that outcome. Check Point's live demonstration removed the full Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection enabled, because the deletion happens beneath the layer Tamper Protection defends. The telemetry problem is what makes this expensive for you.

Because the driver is installed through direct registry writes that skip the Service Control Manager, no Windows Event ID 7045 (Service Installed) is generated, and the kernel operations are attributed in logs to the System process (PID 4). If your SIEM correlation rules key on 7045 for new service installs, or filter out System-process activity as noise, the entire sequence lands inside your blind spots. What follows is ordinary post-compromise work performed without oversight. An operator on an unprotected host can stage credential theft, move laterally to file servers and finance systems, and stage data for exfiltration with no process-level detection and no behavioral alerts. FIN7 has already shown appetite for this specific objective with AvNeutralizer, which abused the Windows ProcLaunchMon.sys driver alongside the Process Explorer driver to tamper with endpoint security software.

The demand for kernel-level EDR disruption is established, even though Check Point Research observed no real-world abuse of this particular technique. Consider what that does to your incident timeline. Investigators reconstruct dwell time from endpoint telemetry, and if that telemetry stopped at the moment the driver ran, you have a gap in your evidence rather than a record of attacker behavior. Your forensic conclusion becomes an inference about what an attacker could have reached, which is a much weaker position when a regulator, an insurer, or a client asks what was accessed. That evidence gap drives your compliance exposure. Under SOC 2, continuous monitoring and logging commitments assume your controls were operating during the period under review, and an unexplained interruption in endpoint telemetry is a control failure your auditor will document.

PCI DSS requires log retention and integrity monitoring across systems in the cardholder data environment, and a host where antimalware binaries were deleted and log generation stopped will not satisfy that requirement for the affected period. HIPAA-covered entities face the harder question. Breach notification obligations turn on whether protected health information was accessed or acquired, and when you cannot demonstrate what happened on a host, the conservative determination is often to notify broadly. Notifying more individuals than were actually affected costs you the same legal review, mailing, credit monitoring, and reputational effort as a confirmed incident of that size. One more factor shapes how long you live with this. Following responsible disclosure, MSRC confirmed the findings do not meet the criteria for immediate servicing, since the technique depends on pre-existing administrative privileges through SeLoadDriverPrivilege.

Any account in your environment holding local administrator rights on a Windows endpoint carries this capability, which makes administrative privilege sprawl a measurable operational risk rather than a policy preference. Detection and Immediate Response Actions Start with a Sysmon rule for Event ID 15 (FileCreateStreamHash) where the target filename ends in .sys:changelist. That Alternate Data Stream carries the encrypted configuration written to the driver file, and Check Point Research lists it first among its indicators. If you are not running Sysmon on servers and admin workstations, that deployment is the immediate gap to close, because none of the remaining detections fire without it. Within the same shift, add three correlation rules covering the rest of Check Point's published conditions: Sysmon Event ID 12 or 13 creating a service key whose Args value contains :changelist and whose Group is Boot Bus Extender, with no matching Windows Event ID 7045 (Service Installed).

A service appearing in the registry without a 7045 entry means the Service Control Manager was skipped entirely, which is worth alerting on regardless of driver name. Sysmon Event IDs 11 and 23 showing rapid creation then deletion of \SystemRoot\Temp\BootClean.log by the System process (PID 4). That log path is hardcoded in the driver and fires no matter who triggers it, so it is a reliable execution marker. Sysmon Event ID 6 (DriverLoad) immediately followed by Event ID 23 (FileDelete) attributed to PID 4. Check Point calls this the kernel-mode execution fingerprint of a live trigger. Because the operations run from Ring 0 and are attributed to the System process, your analysts will see deletions with no user account and no parent process to pivot from. Tell your SOC that PID 4 file deletions outside of patching windows are an investigation trigger, not noise to filter.

Over the next 48 hours, work the privilege side. Pull the current holders of the "Load and unload device drivers" user right via Group Policy and strip it from any group that does not need it, including service accounts and helpdesk tiers that inherited local admin. Then enumerate every key under HKLM\System\CurrentControlSet\Services with Start=1 and compare against a known-good baseline, since boot-start entries are what execute before user-mode protection loads. Also confirm that older or long-lived hosts carry the February 9, 2021 fix for CVE-2021-24092, the SentinelLabs-reported privilege escalation in the same driver that let a local non-administrator overwrite arbitrary files through a hard link at the driver's log path. Any unpatched host gives an attacker a second path into the same component from a lower privilege level.

For execution review, hunt your process and driver-load history for tooling with the same objective. FIN7's AvNeutralizer abused the built-in ProcLaunchMon.sys driver together with the Process Explorer driver to tamper with endpoint security, and that pattern of loading signed, legitimate drivers to reach kernel space is the behavior to baseline against. Longer term, keep Secure Boot and code integrity enforced, and monitor driver loads centrally instead of per host. In environments Capstone manages, SentinelOne flags endpoint-protection tampering and kernel-level driver activity independently of the Defender stack, so removal of a protection component is reported by a second agent rather than going unnoticed. Pair that with a post-reboot health check that alerts when a host comes back online missing expected security services. Patching and Prevention for CVE-2021-24092 Confirm every Windows host in your estate has taken cumulative updates since February 9, 2021, the date Microsoft shipped the fix for CVE-2021-24092.

Any machine patched to a current level already carries it. The stragglers are the ones worth hunting: gold images built before that date and never rebased, lab and OT hosts kept offline, and systems restored from old backups after a hardware failure. CVE-2021-24092 was a local privilege escalation flaw in the same Defender remediation driver, reported by SentinelLabs researcher Kasif Dekel. A non-administrator could place a hard link at the path the driver wrote its log to, and the driver, running with kernel privileges, would overwrite whatever file that link pointed at. Applying the February 2021 update closes that path, so a standard user account on your endpoints can no longer use the driver's own logging behaviour to overwrite protected files. Be clear about what that patch does and does not cover. It has no bearing on the boot-time technique Check Point disclosed, which exploits no flaw at all.

Following responsible disclosure, MSRC confirmed the findings do not meet the criteria for immediate servicing because the technique depends on privileges an attacker must already hold. The BTR_CLI repository states that no patch is planned, a characterisation Microsoft has not confirmed publicly. Dekel noted in the original disclosure that the flaw likely went undiscovered for years 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." For the systems you do find behind on updates, sequence the rollout rather than pushing everything at once: Validate the update ring on a small non-production set that mirrors your production build, including any endpoint agents and disk encryption drivers, and watch it through at least two reboot cycles. Patch privileged infrastructure first: domain controllers, jump hosts, administrative workstations, and any server holding management tooling.

Move to production servers and business-critical endpoints, then the general fleet. Rebase your deployment images last so newly provisioned machines do not reintroduce the old build. The 2021 disclosure documented no compatibility side effects for this fix, and it arrived as part of a routine monthly rollup. Your pilot ring is still worth running, because the risk in a five-year-old catch-up patch is the accumulated cumulative payload, not the individual CVE. Where patching has to wait, the control that matters most is SeLoadDriverPrivilege, which Check Point Research names as its primary hardening recommendation. Audit which accounts and groups hold it through Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ User Rights Assignment \ Load and unload device drivers and strip it back to a named administrative group.

Adding the driver to Microsoft's Vulnerable Driver Blocklist or blocking it through WDAC is not available to you, because it is a required Windows component and blocking it breaks Defender. Pair that with tight control over who holds local administrator rights in the first place. Adlumin tracks privilege assignment and administrative logon behaviour across managed environments, so a service account or helpdesk identity suddenly gaining driver-load rights surfaces as an alert instead of sitting in a Group Policy object nobody reviews. Restricting the privilege is the durable control here, since the technique itself has no fix to apply. Key Takeaway: Prioritize Driver Integrity and Boot-Time Visibility The control point here is administrative privilege, not a patch. MSRC reviewed the disclosure and concluded it does not meet the criteria for immediate servicing, because the technique only works for an attacker who already holds administrative rights and SeLoadDriverPrivilege.

That means the exposure in your estate is defined by how many accounts carry those rights and how tightly you track them. The second point worth carrying into your planning is that blocklisting does not apply. BTR.sys is a required Windows component, so it cannot be added to Microsoft's Vulnerable Driver Blocklist or denied through Windows Defender Application Control without breaking Defender's own remediation. Every driver-integrity control that works by rejecting untrusted or known-bad binaries passes this one through, because the binary is legitimate, signed, and expected to be there. Check Point Research found no evidence of real-world abuse of BTR.sys, which it says makes proactive detection engineering feasible before the technique appears in attacker tooling. Treat that as a window, not as reassurance. FIN7's AvNeutralizer showed the broader pattern is already in criminal hands, using the built-in ProcLaunchMon.sys driver alongside the Process Explorer driver to tamper with endpoint security.

BTR_CLI is now published on GitHub under the MIT license with prebuilt x64 and x86 binaries, so the engineering effort a group would otherwise spend is already done. One practical complication shapes how you interpret what you see. The research began inside an incident response case where suspicious endpoint telemetry turned out to be genuine Defender remediation. Your analysts will face the same ambiguity, and the difference between routine cleanup and abuse sits in the surrounding context, not in the driver itself.