# Microsoft's Own Boot Driver Is Being Used to Kill Security Software Before Windows Fully Loads
The irony is almost too clean: a driver Microsoft ships specifically to clean up malware can be turned around to wipe out the security tools defending a system — before Windows has even finished booting.
Check Point Research dropped that disclosure this week, detailing a technique that leverages BTR.sys, the Boot Time Removal Tool embedded in Microsoft Defender, to perform arbitrary kernel-level file deletions and registry operations across every major Windows release — 7 through 11 25H2. No exploit. No foreign driver smuggled in. Just Microsoft's own code, doing exactly what it was designed to do, pointed in the wrong direction.
## What BTR.sys Was Built to Do
The driver exists for a legitimate reason. Some malware embeds itself deep enough that Windows can't clean it up while the operating system is running — rootkits that lock their own files, kernel-mode components that fight back, persistence mechanisms woven into protected registry hives. Microsoft's answer was BTR.sys: a signed, trusted boot-time driver that executes its removal list before most of Windows loads, when nothing is yet running to resist it.
That's the feature. And it's exactly what makes it dangerous in the wrong hands.
Because BTR.sys is signed by Microsoft, it passes every driver signature check. Because it runs at boot time, it operates before endpoint detection and response tools, before antivirus engines, before tamper protection mechanisms come online. It's the first thing that acts, which means anything it deletes or modifies is gone before any defensive software has a chance to notice.
Check Point found that an attacker with sufficient privilege — administrative access on the local system — can register arbitrary file and registry targets with BTR.sys using its own internal interface. The driver doesn't validate that what you're asking it to remove is actually malware. It just removes it. At boot. With kernel permissions. From a Microsoft-signed binary that no security tool is going to flag.
## A Different Beast Than BYOVD
The security community has spent the last several years watching attackers abuse third-party vulnerable drivers in "bring your own vulnerable driver" (BYOVD) attacks. Ransomware groups like BlackByte used Micro-Star's RTCore64.sys. Lazarus Group abused a Dell driver. The pattern became common enough that Microsoft eventually started blocking known-bad drivers through the vulnerable driver blocklist.
This technique is categorically different, and that distinction matters.
In BYOVD, an attacker has to bring something — drop a driver file, load it, hope it doesn't get flagged. Security tools got better at detecting that pattern. EDR vendors built detections around driver load events for known-bad hashes. Microsoft's blocklist grew. The attack surface narrowed, slowly.
BTR.sys doesn't require importing anything. It's already on the machine. It's already trusted. It's already designed to perform exactly the operations an attacker wants — file deletion and registry modification — at exactly the moment an attacker wants them, when defenses are dormant. There is no foreign artifact to detect, no anomalous driver load to alert on.
This is the kernel-level equivalent of judo: using your opponent's strength against them.
## The Windows Version Breadth Tells a Story
The fact that this technique works across every Windows release from 7 to 11 25H2 is worth sitting with. That's roughly 15 years of Windows releases, spanning everything from legacy corporate infrastructure to brand-new consumer hardware.
It means BTR.sys has existed in essentially this form, with this capability, for a very long time. It means the technique wasn't gated by a specific vulnerability that appeared in one release cycle. And it means the remediation path — if there is one — isn't a straightforward patch. You can't just fix a bug. The "bug" is the design.
## What Defenders Are Actually Up Against
If you're in a security operations role, the uncomfortable truth here is that the standard defensive toolkit gets challenged at a structural level. Tamper protection in modern Defender configurations is supposed to prevent unauthorized modification of security settings, but a boot-time driver operating before the OS is fully loaded occupies a space below where most tamper protection logic lives.
The practical attack scenario isn't subtle: an attacker with local admin access (through phishing, an unpatched vulnerability, credential theft — any of the usual paths) uses BTR.sys to schedule deletion of EDR agent files and registry keys at the next boot. System reboots. Security tooling is gone. Attacker proceeds with whatever comes next in the kill chain, now against a blind defender.
Organizations leaning heavily on a single endpoint security product and assuming tamper protection covers boot-time threats should take another look at their assumptions.
Monitoring BTR.sys interactions before reboot — specifically watching for unauthorized entries being registered with the driver — is a detection opportunity that defenders should be building toward. Event logging around boot-time driver configuration changes deserves elevation in your detection engineering backlog.
## HackWire Analysis
What makes this disclosure uncomfortable beyond the technical specifics is what it reveals about a broader, underexamined category of security risk: features built for defense that, under the right conditions, become weapons.
We've seen this pattern before. Defender's exclusion lists have been abused to hide malware from scans. Security software's kernel access has been leveraged to inject into protected processes. The very depth of access that makes security tools effective is the same depth that makes them attractive targets for abuse.
Check Point's research puts BTR.sys squarely in that category, but there's a harder question lurking underneath: how many other boot-time or kernel-level components in Windows, signed by Microsoft and trusted implicitly, have interfaces that could be similarly misused? The attack surface here isn't a single driver — it's the class of problem.
The ransomware ecosystem has every incentive to operationalize this. EDR killers have become standard pre-ransomware tradecraft. Techniques that wipe out endpoint protection cleanly and early, without triggering detections, are genuinely valuable to attackers running double-extortion playbooks. Expect to see BTR.sys-based EDR killing show up in incident response reports within the next 12 months if it isn't already quietly in play.
Microsoft's response — and whether they can meaningfully constrain this without breaking the legitimate functionality BTR.sys provides — will be the real story to watch. The fix, if one is possible, is architectural rather than cosmetic. That's a harder problem than releasing a patch.
For defenders right now: treat this as a reminder that "Defender is protecting us" is not a complete sentence. Understanding what your security tooling can be made to do against itself is part of your threat model.
— HackWire Editorial
## Related Coverage