Recent findings from Check Point Research have unveiled a concerning potential within Microsoft Defender’s Boot-Time Removal (BTR.sys) driver. This component, typically employed for legitimate remediation tasks, can be exploited to execute powerful kernel-level file and registry operations. Such capabilities may grant attackers with administrative privileges the ability to circumvent endpoint security measures.
The research highlights that this is not a conventional vulnerability or memory-corruption issue. Instead, it reveals how a trusted, Microsoft-signed remediation tool can be transformed into a Living-off-the-Land driver by replicating its undocumented transaction protocol.
Microsoft Defender Driver Can Be Weaponized
BTR.sys is integrated within Microsoft Defender’s MpEngine.dll and is activated when the software needs to perform remediation tasks post-reboot, such as eliminating files locked by the operating system. During its legitimate operations, the driver may operate under a randomly generated filename and service name, utilizing an Alternate Data Stream (ADS) labeled :changelist for its encrypted configuration. It executes its queued tasks and subsequently cleans up, mimicking kernel-loader techniques often observed during incident response investigations.
According to the reverse-engineering analysis conducted by Check Point Research, the driver’s proprietary transaction format is secured by an RC4-encrypted configuration blob, which is further protected by integrity checks. This configuration can include directives to delete files and directories, move files, and modify registry keys and values. Consequently, a valid transaction can command a signed Microsoft driver to execute privileged operations from Ring 0.
The research team developed BTR_CLI, a proof-of-concept tool designed to construct valid transactions and prepare the driver for execution. A significant security concern arises from the timing of BTR.sys’s operations. As a system-start driver, it requires access to the filesystem and Windows paths during initialization. When positioned within the early “Boot Bus Extender” load-order group, it can execute after the filesystem is accessible but before many user-mode security components are initialized, creating what researchers refer to as a “golden window.” During this interval, the driver could potentially remove security binaries or alter related service registry settings prior to the full activation of antivirus or EDR product protections.
This method diverges from traditional Bring Your Own Vulnerable Driver attacks, as it does not depend on loading a known-vulnerable third-party driver. Instead, BTR.sys is a built-in Microsoft component with a valid signature, complicating security measures that typically regard driver signatures as a primary trust indicator.
While the researchers reported no evidence of real-world exploitation at the time of their analysis, the public disclosure of this methodology underscores the necessity for proactive detection strategies.
| Mechanism / Parameter | Implementation Specification | Security Impact |
| Driver Origin | Extracted from MpEngine.dll (BOOTTIMETOOL resource) |
Valid Microsoft signature evades driver-block rules |
| Configuration Path | Alternate Data Stream (.sys:changelist) |
Stealthy parameter staging bypassing standard file scans |
| Encryption & Hashing | RC4 Stream Cipher with modified CRC-32 | Integrity-validated execution without memory corruption |
| Load-Order Group | Boot Bus Extender (System-Start Driver) | Preempts user-mode security agents in the “golden window” |
| Execution Capabilities | Kernel file move/delete, registry write/delete | Unrestricted Ring-0 modification of protected system assets |
To enhance security, defenders should focus on monitoring for suspicious deployment contexts of BTR.sys rather than relying solely on file hashes or Microsoft signatures. Utilizing Sysmon Event ID 15, which records named file-stream creation, can aid in identifying anomalous .sys:changelist ADS activity. Additionally, Sysmon Event ID 6 captures driver loads along with hash and signature details, providing valuable insights into unusual signed-driver activity.
Key indicators of concern include a Defender remediation driver being written or registered by PowerShell, command shells, or unsigned tools, as well as randomized service keys referencing :changelist. Security teams should also be vigilant for rapid creation and deletion of BootClean.log, unusual ADS-backed feedback files on driver paths, and service-key creations lacking expected Service Control Manager installation records.
Organizations are advised to maintain strict control and auditing of SeLoadDriverPrivilege, gather telemetry on driver loads and ADS activities, enforce application-control policies where applicable, and develop detection mechanisms focused on execution lineage, boot-time persistence alterations, and suspicious operations linked to the System process.
Prevent incidents due to slow investigations. Power your Tier 1 with threat intelligence from 15K SOCs: Integrate TI Lookup in your SOC.