SURIQ
The most useful thing a defender can do with Check Point Research's BTR.sys work is stop treating it as a bug to wait out. Microsoft's response was that the technique needs local administrator rights, so it does not meet the bar for a security fix. No patch is planned. That is not a footnote. It means every Windows machine from Windows 7 through Windows 11 25H2 ships a signed, trusted driver that an attacker who already has admin can turn into a tool for deleting your endpoint agent, and the answer is not an update. The answer is knowing what it looks like.
The driver is BTR.sys, the Boot Time Removal Tool. Defender embeds it inside its own engine and drops it to finish cleaning malware that held files or registry keys open while Windows was running. Researcher Jiri Vinopal reverse-engineered its private transaction format, took it to the stage at DEF CON 34 and Black Hat this year, and published a proof-of-concept named BTR_CLI on August 20, 2026, as The Hacker News reported. The important part for a blue team is not the reverse engineering. It is that this driver behaves in a way your existing controls were not built to see.
This is not bring-your-own-vulnerable-driver, and that is the whole point
The standard defense against a malicious signed driver is the vulnerable-driver approach: an attacker brings a legitimately signed but buggy driver from somewhere else, loads it, and abuses it. The counter is Microsoft's Vulnerable Driver Blocklist and Windows Defender Application Control, which refuse to load drivers on a known-bad list. Plenty of teams treat that blocklist as their anti-driver-abuse control and move on.
BTR.sys walks straight through it. You cannot add it to the blocklist and you cannot deny it in application control, because it is a required part of Defender. Block the driver and you break Defender's own cleanup. Check Point classifies this as a living-off-the-land driver rather than bring-your-own, and the distinction is not academic. It means a control that a lot of shops consider their backstop against exactly this class of attack is structurally blind to it. Nothing gets imported, nothing is unsigned, nothing is on a list. We have watched attackers reach for the same goal from a different door, whether that is a kernel rootkit that hides a backdoor from host tools or a driver left behind by a legitimate but vulnerable Windows product. What is new here is that the driver was already trusted and cannot be revoked without collateral damage.
The golden window: it runs before your agent wakes up
The second reason this matters is timing, and it is an argument against relying on the endpoint alone. BTR.sys loads early in boot, in the environment that runs after the anti-malware early-launch checks, so those checks never evaluate it. In one Windows 11 25H2 boot Check Point measured, the driver was active roughly 34 seconds before Defender's user-mode service started. That gap is the attack surface. During it, the driver can delete a security product's files before that product has locked them, which means the tool meant to catch the tampering is not running yet when the tampering happens.
Sit with what that does to detection. If your only sensor for this is the agent on the box, the technique's entire job is to remove that sensor during the window before it can report. This is why threat hunting for it has to lean on telemetry that has already left the host. Forward boot-time and driver-load events off the machine as they happen, and the deletion that blinds the local agent still lands in a place the attacker cannot reach in those 34 seconds. Endpoint-only visibility is the wrong architecture for a threat whose first move is to disable the endpoint. It is the same lesson we drew when Akira ransomware rebooted machines into Safe Mode to strip protection: the evasion targets the sensor, so the sensor cannot be the only witness.
The stealth is real, but it hides in one place only
Here is the part the coverage underplays. The technique is genuinely quiet against the check most teams monitor, and loud against the ones they often do not. Instead of installing the driver through the Windows Service Control Manager, the tool writes the service keys straight into the registry and loads the driver with a low-level call. The Service Control Manager never sees it, so the usual service-installed record, Event ID 7045, is never written. If your service-abuse alerting keys on 7045, this sails past.
But the mechanics it uses to stay quiet in one lane are noisy in another. The driver reads its instructions from an alternate data stream on a file, its service key carries a distinctive group and argument, and its work leaves a specific temporary log written and deleted by the System process. None of that shows up in service-install monitoring. All of it shows up if you are watching the registry and file system with Sysmon. Stealth here is a function of where you look, not a property of the attack. The Service Control Manager bypass that hides it from one tool is itself the signature for another.
| Sysmon event | What to hunt for | Why it appears |
|---|---|---|
| ID 12/13 (registry) | A new service key whose group is Boot Bus Extender and whose arguments reference a change list | The driver is installed by writing the service key directly, skipping the Service Control Manager |
| ID 15 (alternate data stream) | Creation of a change-list alternate data stream on a .sys file | The driver reads its encrypted configuration from an alternate data stream, its most distinctive artifact |
| ID 6 (driver load) | A Microsoft-signed driver loaded by a parent process outside the Defender engine | The signed driver is loaded on demand rather than by Defender's own remediation flow |
| ID 23 (file delete) | The System process deleting security-product binaries right after a driver load | The driver deletes files and bypasses the locks that would normally protect them |
| ID 11 (file create) | A boot-cleanup log rapidly written and removed under the System temp path by the System process | The remediation routine leaves and clears a temporary log as it runs |
What the driver can actually do once loaded
Six kernel operations are in scope. It can delete files while bypassing exclusive locks, delete directories, move or quarantine files, delete registry keys, delete registry values, and write arbitrary registry values including new keys. Deleting protected security binaries is the headline abuse, but arbitrary registry writes from the kernel are a persistence and tampering primitive in their own right. One more detail matters for anyone hoping to fingerprint the tool: Check Point found that all eighteen 64-bit versions of the driver, across every Windows build it tested, share one identical hard-coded encryption key. The configuration format is the same everywhere, which is bad news for uniqueness and good news for detection, because the artifacts it leaves are consistent across the fleet.
This is not the first trouble in this exact driver. A privilege-escalation flaw in the same component, CVE-2021-24092, was patched back in February 2021. That one was a coding bug Microsoft fixed. This one is a design property Microsoft has chosen to leave in place, which is why the defensive posture is different.
Put the five signals in your hunt tonight, not the patch queue
There is no patch to stage, so the work moves from your update pipeline to your detection content. Load the five telemetry sources in the table into a correlation rule that fires when a Microsoft-signed driver load is followed closely by the System process deleting a security binary, and treat a service key written outside the Service Control Manager with a Boot Bus Extender group as suspicious on its own. Make sure those events are shipped off the host in near real time, because the technique is built to happen before a local agent can speak. Check Point reports no in-the-wild abuse yet and the proof-of-concept is public, which is the window where getting detection in place is cheap. Treat the absence of a patch as the signal it is: Microsoft has told you this behavior is staying, so the only version of fixed you get is the one you build.