Microsoft Defender's Signed BTR.sys Driver Can Be Weaponized in the Kernel, Check Point Finds

Check Point Research has disclosed that one of Microsoft Defender's own components can be turned against the machine it is supposed to protect. In a paper and conference briefing released on August 20, 2026, researcher Jiri Vinopal showed that BTR.sys, the legitimately signed Boot Time Removal Tool that Defender uses to finish cleaning up malware after a reboot, can be repurposed into an attacker-controlled kernel operation primitive. Once repurposed, it is capable of arbitrary kernel-level file and registry operations, up to and including deleting security software, on every Windows version from Windows 7 through Windows 11 25H2.

The uncomfortable part is that nothing is broken. No outside driver is imported, and no software flaw is exploited. The driver is signed by Microsoft, trusted by Windows, and doing something very close to what it was built to do. Check Point calls the work "BTR Reforged," and the reason it matters to defenders is not a new CVE to patch. It is that the usual way of containing a malicious driver does not apply here, and Microsoft is not treating this as a bug.

What Check Point Disclosed

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 paper alongside a proof-of-concept tool on August 20, 2026. The Hacker News reported the disclosure the following day.

BTR.sys is not a driver most administrators will recognize, because it is normally not sitting on disk. It ships embedded inside Defender's MpEngine.dll as the BOOTTIMETOOL resource, and Defender drops and runs it only when it needs to finish removing something that was locked while Windows was running: a malware file, a registry key, a driver that could not be deleted live. In other words, it is a cleanup tool that already has permission to reach into the kernel and delete things early in boot.

Check Point's research shows that same capability can be redirected. Repurposed, the driver can delete locked files and directories, move files into protected paths, and delete or create registry keys and values, executing from Ring 0 and attributed in telemetry to the System process. In a live demonstration at Black Hat, the proof-of-concept removed the entire Defender stack from a fully updated Windows 11 25H2 machine with Tamper Protection turned on.

This is not a remote or unprivileged attack. It requires an account that is already an administrator and holds the SeLoadDriverPrivilege right. That precondition matters, and it is central to how Microsoft has responded. But it is also a bar that plenty of post-compromise scenarios clear, which is exactly when an attacker wants to disable the tools watching them.

Check Point says it looked for signs this was already happening and found none. "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," the company wrote, adding that this makes "proactive detection engineering feasible before weaponization appears in the wild."

Why a Signed, Built-In Driver Is Harder to Contain

To see why this is a different problem, compare it with the technique defenders are used to. In a bring-your-own-vulnerable-driver attack, an intruder drags a known-bad third-party driver onto the machine and loads it to get into the kernel. The defense against that is a list: Microsoft's vulnerable-driver blocklist and Windows Defender Application Control can be told to refuse those specific drivers, and the ecosystem keeps adding new ones as they surface.

BTR.sys defeats that model on both ends. It is not third-party, so there is no import to catch, and it is a required Windows component, which means it cannot be added to the vulnerable-driver blocklist or denied through Windows Defender Application Control without breaking Defender itself. The one control built to stop malicious drivers cannot be pointed at this one. And because the driver has shipped inside Windows since Windows 7, the exposure is not limited to an unpatched subset of machines. It is the whole installed base.

There is a timing dimension too. Because BTR.sys is a boot-time tool, its operations can run early in startup, in the interval after the filesystem is writable but before Defender's own user-mode services have started and can protect themselves. That is what allowed the demo to physically remove security binaries before they could lock. The specific mechanics belong in Check Point's paper, and defenders should read them there rather than here. The point for planning is simpler: this sits squarely in the signed-driver-abuse risk category, where the thing you trust is the thing being used.

What Microsoft Has (and Hasn't) Said

Microsoft is not, at least so far, treating BTR Reforged as a security defect to service. Following responsible disclosure, Check Point says the Microsoft Security Response Center confirmed the findings do not meet the criteria for immediate servicing, because the technique relies on pre-existing administrative privileges.

Check Point frames the issue the same way. "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," the company wrote. That is an honest way to describe it, and it is also why there may be no clean fix: the driver is behaving as designed, and the trust that makes it useful is the same trust that makes it dangerous.

A few things are worth flagging as not yet confirmed, because the reporting leaves them open. The proof-of-concept's public repository states that "No patch is planned," but that is the researcher's characterization, and Microsoft has not confirmed it publicly. It is not confirmed whether Microsoft has revoked the driver's signature or shipped an updated build in response, and Check Point reported that the encrypted configuration format was unchanged across the 18 driver versions it examined. There is no indication the technique has been seen in the wild, no named victims, no public listing of the driver on a vulnerable-driver catalog tied to this research, and no confirmation that antivirus or endpoint-detection vendors have shipped detection for it. Treat all of those as open questions rather than settled facts.

Worth noting: this same driver drew scrutiny once before. In February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a separate privilege-escalation flaw in the Boot Time Removal Tool that Microsoft patched at the time. BTR.sys has a history of being interesting to the people who look closely at Defender's internals.

What Defenders Should Do Now

The first move is to stop expecting the vulnerable-driver blocklist to help. It is a genuinely good control against bring-your-own-driver attacks, but it structurally cannot cover a required Defender component, and assuming otherwise leaves a blind spot. Confirm your blocklist and Windows Defender Application Control policies are current for everything else, and mentally file BTR.sys as out of scope for that layer.

The control Check Point actually recommends is tightening SeLoadDriverPrivilege. Because the technique cannot begin without an account that holds that right, auditing where it has been granted and pulling it back to the smallest possible set of accounts is the highest-leverage hardening step available right now. This is standard least-privilege work, and it pays off well beyond this one driver.

On detection, Check Point has done defenders a favor by publishing concrete indicators, which is unusual for a technique with no in-the-wild activity yet. The signatures worth building around include a driver load immediately followed by a file deletion attributed to the System process, a ".sys:changelist" alternate data stream, and a service registered into the "Boot Bus Extender" group without the Windows event you would normally expect when a service is installed. If your endpoint-detection or SIEM tooling can express those, now is the time, while there is no attacker pressure. Also revisit what your tamper-protection settings actually guarantee, because a boot-time removal can operate in a window where user-mode protections are not yet running. And keep an eye out for any Microsoft signature revocation or official guidance, since that would change the calculus quickly.

My Read

My read: this is less a Defender problem than a category problem, and signed remediation tools are becoming a real trust liability. We have spent years teaching Windows to distrust unsigned and known-bad drivers, and the industry got good at it. The counter-move, visible here and in earlier cases like FIN7's abuse of a built-in Windows driver, is to stop importing anything and instead borrow the trusted, signed, un-blocklistable code already sitting inside the operating system. Any tool that is powerful enough to delete malware at boot is powerful enough to delete your defenses at boot, and its signature is not the safeguard it looks like. Assessment, not reported fact: expect more research in this direction, and expect the fix, when there is one, to be about privilege and telemetry rather than a patch. For related context, see our earlier coverage of a Defender flaw that could grant SYSTEM privileges.

Primary Documents

• Check Point Research: BTR Reforged, Weaponizing Defender's Remediation Driver as a Kernel Operation Primitive
• The Hacker News: Microsoft Defender's Own Driver Can Be Weaponized to Delete Security Software at Boot
• SentinelLabs: CVE-2021-24092, a prior privilege-escalation flaw in the same Boot Time Removal Tool (2021)