Microsoft Defender’s legitimate Boot-Time Removal (BTR.sys) driver can be repurposed to perform powerful kernel-level file and registry operations, potentially enabling attackers with administrative privileges to neutralize endpoint security protections.
The Check Point research does not describe a conventional vulnerability or memory-corruption flaw; instead, it exposes how a trusted, Microsoft-signed remediation component can become a Living-off-the-Land driver when its undocumented transaction protocol is reproduced.
Microsoft Defender Driver Can Be Weaponized
BTR.sys is embedded within Microsoft Defender’s MpEngine.dll and is deployed when Defender needs to complete a remediation task after reboot, such as removing a file locked by the operating system.
During legitimate activity, the driver may appear with a randomly generated filename and service name, use an Alternate Data Stream (ADS) named :changelist for its encrypted configuration, execute its queued operations, and then clean up.
Those behaviors can resemble kernel-loader tradecraft during an incident response investigation, despite being part of Defender’s normal remediation architecture.
According to reverse-engineering findings shared by Check Point Research, the driver’s proprietary transaction format relies on an RC4-encrypted configuration blob protected by integrity checks.
The configuration can contain instructions to delete files and directories, move files, delete registry keys and values, and write registry data. In effect, a valid transaction can direct a signed Microsoft driver to perform privileged operations from Ring 0.
The research team created BTR_CLI, a proof-of-concept tool that constructs accepted transactions and stages the driver for execution.
The key security concern is timing. BTR.sys operates as a system-start driver rather than a boot-start driver because it needs access to the filesystem and Windows paths during initialization.
When assigned to the early “Boot Bus Extender” load-order group, it can run after the filesystem becomes available but before many user-mode security components initialize.
Researchers call this interval a “golden window,” during which the driver could remove security binaries or modify related service registry settings before an antivirus or EDR product’s full protection stack starts.
Unlike traditional Bring Your Own Vulnerable Driver attacks, this approach does not rely on loading a known-vulnerable third-party driver.
BTR.sys is a built-in Microsoft component with a valid signature, complicating security controls that treat driver signatures as a major trust signal.
The researchers said they found no evidence of in-the-wild abuse at the time of analysis, but the public release of the methodology makes proactive detection increasingly important.
| 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 |
Defenders should monitor for suspicious BTR.sys deployment context rather than relying solely on file hashes or Microsoft signatures. Sysmon Event ID 15, FileCreateStreamHash, records named file-stream creation and can help identify anomalous .sys:changelist ADS activity.
Sysmon Event ID 6, DriverLoad, records driver loads along with hash and signature details, making it useful for correlating unusual signed-driver activity with the process that deployed it.
High-value signals include a Defender remediation driver written or registered by PowerShell, command shells, unsigned tools, or other processes outside the normal Defender lineage; randomized service keys containing an Args value that references :changelist; and Microsoft-signed driver loads followed by SYSTEM-level deletion of security binaries.
Security teams should also investigate rapid creation and deletion of BootClean.log, anomalous ADS-backed feedback files on driver paths, and service-key creation that lacks an expected Service Control Manager installation record.
Organizations should tightly control and audit SeLoadDriverPrivilege, collect driver-load and ADS telemetry, enforce application-control policies where feasible, and build detections around execution lineage, boot-time persistence changes, and suspicious operations attributed 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
The post Microsoft Defender Driver Can Be Weaponized to Disable EDR and AV From Windows Kernel appeared first on Cyber Security News.
