Security News Microsoft Defender's Own Driver Can Be Weaponized to Delete Security Software at Boot

Minimalist

Level 13
Thread author
Verified
Top Poster
Well-known
Forum Veteran
Oct 2, 2020
603
5,738
1,168
Slovenia
Check Point Research has disclosed a technique that uses Microsoft Defender's own legitimately signed boot-time remediation driver to perform arbitrary kernel-level file and registry operations on Windows systems ranging from Windows 7 through Windows 11 25H2, with no software flaw exploited and no driver imported from outside the machine.


The driver, BTR.sys (Boot Time Removal Tool), is a required Windows component, which means it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control (WDAC) without disrupting Defender itself.

 
Check Point Research has disclosed a technique that uses Microsoft Defender's own legitimately signed boot-time remediation driver to perform arbitrary kernel-level file and registry operations on Windows systems ranging from Windows 7 through Windows 11 25H2, with no software flaw exploited and no driver imported from outside the machine.


The driver, BTR.sys (Boot Time Removal Tool), is a required Windows component, which means it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control (WDAC) without disrupting Defender itself.

This appears to describe an abuse of a trusted Defender component rather than a conventional vulnerable-driver exploit. The important distinction is that the attacker would be repurposing a Microsoft-signed driver already present on the system, instead of bringing an unsigned or third-party vulnerable driver.

I cannot independently verify the linked report or its stated Windows 11 25H2 coverage. The claim that BTR.sys “cannot be blocked” should also be read carefully: Microsoft could potentially change Defender’s architecture, signing, loading conditions, or policy handling. However, blocking a required Defender component through ordinary enterprise controls could clearly have availability and protection consequences.

If confirmed, the practical implications are:

  • A threat actor would generally need substantial privileges or an existing foothold before abusing the driver.
  • The driver’s trusted signature would make simple driver-blocking defenses less effective.
  • File and registry tampering performed at kernel level could interfere with security tools, persistence locations, and forensic evidence.
  • Detection should focus on unusual Defender remediation activity, unexpected BTR.sys loading or invocation, service/process ancestry, and changes to protected files or registry areas.
  • Organizations should apply Microsoft security and Defender platform updates promptly, while testing any WDAC or driver-blocking policy changes before deployment.

This is not evidence that BTR.sys itself is malware or that normal Defender operation is unsafe. It would represent a security design and abuse concern that requires Microsoft’s mitigation guidance. Until official details are available, defenders should avoid manually deleting or blocking the driver and should rely on supported Microsoft updates and documented enterprise controls.