Microsoft Defender BTR.sys Exploit: Weaponizing Native Drivers

Microsoft Defender BTR.sys exploit deleting core security components

Attackers can force Microsoft Defender to delete its own security components using a native Windows driver. This technique affects systems from Windows 7 through Windows 11 25H2. It requires neither a software vulnerability exploit nor a third-party driver payload. An attacker merely needs administrative rights featuring the SeLoadDriverPrivilege. Subsequently, the built-in BTR.sys driver permits arbitrary file and registry operations directly from the Windows kernel.

Analyzing the BTR.sys Exploit

The Boot Time Removal Tool, or BTR.sys, resides within Microsoft Defender. It functions to sanitize the computer during the system boot sequence. The antivirus utilizes this driver when it cannot eliminate active malicious files or registry keys. Active processes often lock these files. Therefore, Defender saves the task and reboots the computer. It completes the deletion before other programs can lock the targeted objects again.

Researchers discovered that this native mechanism accepts a vastly broader command set than standard antivirus sanitation requires. A properly structured task allows BTR.sys to delete locked files and directories. It can also relocate files to arbitrary destinations, including System32\drivers. Furthermore, it can delete registry keys and write new values of any type. Crucially, all operations execute within Ring 0, the Windows kernel level.

Uncovering the Undocumented Protocol

Standard blocklists for dangerous drivers provide little defense here. Microsoft Defender intrinsically requires BTR.sys to function properly. Adding this component to the Microsoft Vulnerable Driver Blocklist would disrupt the antivirus itself. For the same reason, prohibiting BTR.sys via Windows Application Control remains highly problematic. Microsoft currently brands this feature as Windows Defender Application Control for Business.

The forensic analysis of a compromised computer led researchers to this technique. Initial telemetry partially resembled malicious software activity. However, deeper inspection revealed standard Microsoft Defender behavior during system sanitation. Consequently, specialists began analyzing the internal protocol connecting Defender to the BTR.sys task queue.

Executing the BTR_CLI Tool

This internal protocol proved entirely closed and undocumented. The system encrypts the command configuration utilizing the RC4 algorithm. Developers astonishingly hardcoded the 256-byte key directly into the .rdata section of every examined BTR.sys file. An examination of 18 distinct 64-bit versions revealed the exact same key across all releases since Windows 7. Possessing both the data format and the key allows an attacker to forge a transaction. The driver subsequently accepts this forgery as a legitimate task.

Bypassing the Service Control Manager

To validate this, the researchers engineered a tool named BTR_CLI. Initially, the program locates the MpEngine.dll library among the Microsoft Defender update files. The BTR.sys binary code resides inside this library within the BOOTTIMETOOL resource. Thus, attackers need not introduce external drivers. BTR_CLI simply extracts the embedded file directly from installed Defender components.

Next, the program constructs an encrypted command sequence. It registers BTR.sys as a driver service via direct writes to the HKLM registry branch. BTR_CLI defines critical parameters including Type=1, Start=1, and Group=”Boot Bus Extender”. This specific registration entirely bypasses the Windows Service Control Manager.

Eradicating Defender Components

Direct registry manipulation leaves significantly fewer conventional forensic artifacts. Windows typically generates an Event ID 7045 log upon standard service installation. However, BTR_CLI evades the Service Control Manager, preventing the appearance of this specific log entry. Simultaneously, the driver flawlessly acquires its requisite loading parameters.

Upon execution, BTR.sys reads the forged task. It then processes the commands masquerading as the System process with PID 4. Consequently, monitoring tools perceive these file operations as native Windows activities rather than standard user actions.

Expanding the Attack Window

BTR_CLI also supports an alternative deployment scenario. Attackers can preserve the malicious commands until the next system reboot. During the Windows boot sequence, a brief vulnerability window materializes. The file system permits writes while Microsoft Defender user services remain dormant. The protective processes have not yet locked their associated files.

BTR.sys initializes early enough to ruthlessly exploit this temporal gap. The driver can effortlessly eradicate WdFilter.sys, MsMpEng.exe, and other vital Defender files. This deletion precedes the full initialization of the antivirus shield. Crucially, a legitimately signed Microsoft component executes the deletion utilizing kernel privileges.

Microsoft Response and BYOVD Differences

The researchers demonstrated this devastating method on a fully updated Windows 11 25H2 system. The target computer had Tamper Protection actively enabled. This feature theoretically prevents unauthorized disabling of Microsoft Defender. However, BTR_CLI successfully deleted the antivirus components despite this protection. The native driver executed the operations securely during early Windows boot.

Evading Standard Protections

Attackers cannot achieve total system compromise utilizing only BTR.sys. Loading the driver dictates an administrative account possessing the SeLoadDriverPrivilege. BTR_CLI automatically activates this privilege if it already belongs to the current user profile. Yet, the tool itself neither grants this right nor inherently escalates privileges.

This strict requirement for administrative access defined Microsoft’s official posture following disclosure. The Microsoft Security Response Center declined to classify this mechanism as an immediate vulnerability. They argued that attackers must already possess administrative rights to load drivers. The BTR_CLI repository notes that no immediate fix is planned. Microsoft, however, remains silent regarding this decision publicly.

This technique differs fundamentally from standard Bring Your Own Vulnerable Driver (BYOVD) attacks. During a BYOVD assault, adversaries load a legitimately signed third-party driver containing a known flaw. They exploit this flaw to access the kernel and disable protective software. Defenders can easily add the offending driver to a blocklist.

Detecting the BTR.sys Manipulation

In stark contrast, BTR.sys resides permanently within Microsoft Defender. It boasts a valid Microsoft signature and facilitates standard antivirus operations. Furthermore, the researchers avoid exploiting memory corruption or classical authorization failures. The driver merely receives perfectly formed instructions via its proprietary protocol. It then diligently executes the operations for which it naturally possesses elevated privileges.

Attackers previously employed similar principles against defensive software utilizing different Windows components. The AvNeutralizer tool, linked to the infamous FIN7 syndicate, abused the ProcLaunchMon.sys system driver. It collaborated with the Process Explorer driver to disrupt endpoint protection platforms. BTR.sys elegantly expands upon this exact philosophy. Intruders require no externally vulnerable components when native, trusted Windows drivers already harbor the requisite capabilities.

Tracking Registry and File Anomalies

Interestingly, BTR.sys previously attracted security research attention for an entirely distinct reason. In February 2021, Microsoft patched the CVE-2021-24092 vulnerability within this driver. This critical flaw permitted local users lacking administrative rights to overwrite arbitrary files. They accomplished this via a hard link placed on the driver’s log path. Microsoft officially deployed the remediation patch on February 9, 2021.

For years, BTR.sys remained an incredibly elusive target for comprehensive analysis due to its operational quirks. Defender does not permanently store the driver on the disk under a static filename. The protective software extracts the component exclusively when required and assigns it a randomized moniker. Following the sanitation sequence, it promptly deletes the ephemeral driver.

Researchers have yet to uncover tangible evidence of this novel technique actively exploited in the wild. A thorough review of collected malware samples and telemetry revealed zero instances of adversarial BTR.sys manipulation. Consequently, defensive efforts now prioritize identifying specific behavioral signatures. These signatures allow security platforms to detect the deployment of BTR_CLI or analogous instruments.

The initial conspicuous forensic artifact involves the Alternate Data Stream (ADS) named :changelist. Attackers utilize this stream to record the encrypted configuration. Sysmon Event ID 15, tracking FileCreateStreamHash, can potentially capture filenames terminating in .sys:changelist. This specific sequence explicitly indicates the creation of a supplementary data stream adjacent to the driver file.

The subsequent forensic indicator manifests directly within the system registry. Sysmon Event IDs 12 and 13 illuminate the creation of a suspicious service key. Here, the Args parameter predictably contains :changelist, while the Group assumes the value Boot Bus Extender. This unique combination becomes highly dubious absent a corresponding Windows Event ID 7045. BTR_CLI registers the driver directly via HKLM, bypassing standard service control mechanisms.

Furthermore, BTR.sys rigidly employs the hardcoded path \SystemRoot\Temp\BootClean.log. The driver diligently generates this log regardless of the initiating program. Sysmon Event IDs 11 and 23 can effectively expose the rapid creation and immediate deletion of BootClean.log. Crucially, the System process bearing PID 4 executes this rapid sequence.

To detect active execution within a live Windows environment, researchers propose monitoring an additional sequence. Sysmon Event ID 6 meticulously documents the loading of the driver. Subsequently, Event ID 23 might instantaneously register the deletion of a file by the System process with PID 4. Together, these paired events provide a definitive signature of a forged task executing at the kernel level.

Ultimately, researchers advocate restricting the SeLoadDriverPrivilege as the primary defensive countermeasure. This formidable right allows the loading of kernel drivers. System administrators must never assign it to accounts without absolute necessity. Absent administrative access and this vital privilege, adversaries cannot exploit BTR.sys using this methodology.

The complete source code for BTR_CLI is publicly available on GitHub under the MIT license. Precompiled versions for both 64-bit and 32-bit architectures reside within the releases section. As of publication, Microsoft has announced no immediate plans to alter the BTR.sys architecture. They have also declined to issue a dedicated patch specifically addressing this elegant technique.

Support Our Threat Intelligence

If you find our technology report and cybersecurity news helpful, consider supporting our work.

Crypto QR Code
USDT (TRC20):
TN8BdV8cp4T1Cd28gK9qTAnZknzzuwyUtm
USDT (ERC20):
0x3725e1a7d3bc5765499fa6aaafe307fabcd75bce

Leave a Reply