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
610
5,798
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.

 
Last edited by a moderator:
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.
 
From the source Checkpoint publication:

Following responsible disclosure, MSRC confirmed that these findings do not meet the criteria for immediate servicing, as the technique relies on pre-existing administrative privileges (SeLoadDriverPrivilege). This classification establishes BTR.sys as a potent “Living-off-the-Landdriver (LOLDriver). Crucially, unlike third-party drivers often neutralized by the Microsoft Vulnerable Driver Blocklist or tracked by the LOLDrivers project, BTR.sys is an essential, built-in Windows component. It remains fully allowed and operational, enabling advanced evasion without the risks or constraints associated with traditional BYOVD techniques.
 
At least MS should consider modifying the already reverse-engineered transaction protocol encryption that Defender uses to communicate what is to be removed so that the POC cannot arbitrarily delete anything ? Lazy MS !

Say good bye to your AV engines.
 
Last edited:
The POC binaries are detected by MD and probably by other AVs. However, the problem can be with PE injections via FUDs, scripts, or VBA macros.
So, this method can be a very dangerous payload to tamper with AVs/EDRs.