Windows Defender’s own driver can leave systems defenseless

A Microsoft-signed Windows Defender remediation driver can be repurposed into a kernel-level “operation engine” capable of deleting files, modifying the registry and neutralizing security controls, according to new research from Check Point Research (CPR). The technique does not exploit a vulnerability or rely on the traditional Bring Your Own Vulnerable Driver (BYOVD) model. Instead, it abuses functionality intentionally built into Defender’s Boot-Time Removal driver, “BTR.sys,” CPR researcher Jiří Vinopal said in a blog post. Vinopal reverse-engineered the driver and its undocumented transaction format, finding that BTR.sys can be instructed to perform arbitrary file and registry operations from kernel mode. BTR.sys is a legitimate Microsoft-signed component and is used when Defender needs to perform remediation requiring a reboot, such as deleting a locked file. CPR team has shared a proof-of-concept tool, BTR_CLI, that demonstrates the technique on Windows versions ranging from Windows 7 through fully updated Windows 11 25H2. The attack path remains open with no evidence of in-the-wild abuse yet, as Microsoft’s Security Response Center (MSRC) found it “did not meet the criteria for immediate servicing.” The attack relies on pre-existing privileges, MSRC reportedly said. A Defender cleanup mechanism turned malicious The technique abuses the way BTR.sys receives its instructions. Rather than exposing a conventional IOCTL interface, the one-shot driver reads an encrypted configuration stored in an Alternate Data Stream attached to the driver. CPR found that the configuration uses RC4 encryption with a hard-coded 256-byte key and a custom CRC-32 integrity check. Once decrypted, the configuration contains a sequence of actions like file deletion, directory deletion, file moves, and registry operations. Registry operations found possible included deleting registry keys and values, setting registry values, arbitrary registry modification, and, potentially, persistence or security control tampering. When the destination is set to System32, the file-move primitive can become an arbitrary file-write capability, Vinopal noted. The abuse was automated with BTR_CLI, including the extraction of the legitimate driver from the local Defender installation, construction of the encrypted transaction, and loading the driver. Using the target machine’s own copy of BTR.sys, the tool avoids introducing external drivers as with conventional BYOVD attacks, CPR noted. The researchers identified 18 unique Microsoft-signed 64-bit versions of the driver and found the same transaction format and RC4 key across the versions examined.Microsoft did not immediately respond to CSO’s request for comment. Boot timing made things worse CPR also flagged where BTR.sys sits in Windows’ boot sequence. The driver cannot run as a traditional Start=0 boot driver, but can execute very early in Phase 1 when configured as a Start=1 system driver in the Boot Bus Extender group. This, Vinopal noted, creates a “Golden Window” as the filesystem is already available for modification, but important security services and user-mode protection components have yet to start. “The primary AV service starts roughly 34 seconds after the BTR driver has finished its work,” he said. CPR demonstrated that this timing could be used to delete Defender binaries and modify Defender-related registry keys before the protection services could launch. CPR said signature-based blocking is ineffective because BTR.sys is legitimate and recommended using behavioral context instead. Looking for signs that the driver is being used outside its normal Defender workflows, such as unusual process lineage and unexpected file or registry activity, may help, it said.