Critical Microsoft Defender Driver Security Flaw

Microsoft Defender includes a legitimate driver called BTR.sys, designed to help complete security remediation tasks that require changes during system startup. Security researchers have found that this trusted component can potentially be misused by attackers with administrator-level access.

The technique does not depend on a traditional software vulnerability. Instead, it takes advantage of how the signed Defender driver processes its internal commands, turning a trusted security component into a tool capable of performing privileged operations.

How BTR.sys Works

BTR.sys is part of Microsoft’s Defender engine and is normally used when Defender needs to remove or modify files that cannot be handled while Windows is running.

During a legitimate remediation process, the driver can be given a configuration containing operations that need to be completed after a reboot. Once the work is finished, the driver and its supporting data are removed.

Researchers found that these capabilities can be reproduced outside the normal Defender workflow.

Turning a Trusted Driver Into an Attack Tool

Analysis by Check Point Research showed that BTR.sys uses an internal transaction format to receive instructions.

These instructions can include operations such as:

Deleting files and directories
Moving files
Removing registry keys and values
Writing registry information

Because the operations are performed by a Microsoft-signed kernel driver, the activity can receive a level of trust that ordinary unsigned tools would not.

Researchers also developed a proof-of-concept utility called BTR_CLI to demonstrate how these transactions could be created and supplied to the driver.

The Dangerous Boot-Time Window

The most concerning part of the technique is when the driver runs.

BTR.sys operates during an early stage of Windows startup, after important filesystem components are available but before many user-mode security services have fully initialized.

Researchers describe this period as a “golden window.”

An attacker who already has administrative control could potentially use this stage to remove security files or modify security-related registry settings before an EDR or antivirus product becomes fully operational.

Why This Differs From BYOVD Attacks

The technique is different from the traditional Bring Your Own Vulnerable Driver (BYOVD) approach.

BYOVD attacks generally rely on a legitimate but vulnerable third-party driver to gain kernel-level capabilities.

In this case, the component being abused is a built-in Microsoft Defender driver with a valid Microsoft signature.

That makes detection more difficult for security controls that primarily rely on driver reputation, signatures, or known vulnerable-driver lists.

What Security Teams Should Monitor

Security teams should look beyond the driver signature and examine how and why the driver was deployed.

Useful indicators include:

Unexpected BTR.sys activity outside normal Defender remediation.
Suspicious :changelist Alternate Data Stream activity.
Driver loading initiated by PowerShell, command shells, or unknown tools.
Unexpected service creation associated with the driver.
Security files being deleted immediately after a driver load.
Unusual boot-time configuration changes.
Suspicious registry modifications involving security products.

Sysmon Event ID 6 (DriverLoad) can help identify driver loading activity, while Event ID 15 (FileCreateStreamHash) can provide visibility into named Alternate Data Streams.

How Organizations Can Reduce the Risk

Organizations should closely monitor privileged driver activity and maintain strong controls around administrative access.

Security teams should also collect driver-load, registry, and filesystem telemetry and correlate these events with the process that initiated them.

Restricting unnecessary administrative privileges, monitoring boot-time changes, and using application-control policies can make it harder for attackers to abuse trusted system components.

This research highlights an important challenge for modern endpoint security: a valid digital signature does not automatically mean that a component is being used legitimately.

Attackers increasingly look for trusted Windows components that already have powerful capabilities instead of introducing obviously malicious tools.

For defenders, understanding execution context, process lineage, timing, and behavior is therefore just as important as checking whether a driver is digitally signed.