Security researchers at Check Point have disclosed a technique that weaponizes Microsoft Defender's own Boot Time Removal (BTR.sys) driver to perform arbitrary kernel-level operations on Windows systems. The method bypasses traditional vulnerability detection because no CVE exists, no malicious code is injected, and no unsigned drivers are loaded. This represents a meaningful shift in how infrastructure defenders should think about driver-level threats.
The Legitimacy Problem
The core issue is deceptively simple: BTR.sys is a legitimately signed Microsoft driver that runs at boot time with kernel privileges. Its documented purpose is remediation—removing malware and broken software during system startup. An attacker with local access can repurpose this driver's legitimate functionality to delete arbitrary files, modify registry keys, and perform other kernel-level operations without triggering signature verification or integrity checks.
This works because the driver itself is not flawed; the attack relies on legitimate functionality being misused. The technique affects Windows 7 through Windows 11 25H2, spanning a vast installed base. Check Point's detailed disclosure outlines how the driver can be instructed to delete specific files or modify boot-time configuration—potentially disabling other security software or persistence mechanisms.
Why Traditional Detection Fails
Endpoint detection and response (EDR) tools rely on several assumptions: unsigned drivers are suspicious, process creation is a reliable telemetry source, and file operations trigger forensic artefacts. This technique violates none of those assumptions from the perspective of the monitoring layer. The driver is signed by Microsoft. No new process spawns. The file deletion happens in kernel space before the OS fully boots, potentially before logging initialises.
Infrastructure teams running Windows Server deployments—particularly those operating in sensitive jurisdictions or with high-value services—should note that traditional post-boot intrusion detection has blind spots at the firmware and bootloader level. Defenders must assume that a system with local code execution already has the ability to tamper with security software unless additional controls are in place.
Implications for Hosted Environments
For organisations managing dedicated servers, virtual infrastructure, or hybrid deployments, this disclosure highlights the importance of immutable boot verification and secure boot policies. On shared infrastructure, a compromise of one tenant's virtual machine should not cascade to kernel-level access on the host. On dedicated hardware, UEFI Secure Boot and measured boot (TPM) can provide assurance that the kernel and drivers haven't been tampered with—but only if those mechanisms are correctly configured and their measurements validated by a trusted authority outside the machine.
The attack also underscores why infrastructure providers offering high-security or privacy-focused hosting often isolate workloads more aggressively than commodity cloud providers. If code execution is assumed possible at some layer, the goal becomes containment: ensuring that privilege escalation within a guest has strictly bounded impact on the host or sibling guests.
Detection and Mitigation Approaches
Mitigating this specific technique requires changes at several levels. At the firmware level, systems should enforce UEFI Secure Boot with custom certificate policies that restrict which drivers can load at boot time. At the OS level, Windows Defender itself can be hardened through Group Policy to prevent the BTR driver from being invoked except during scheduled Microsoft-controlled maintenance windows. Code integrity policies and hypervisor-enforced protection can add additional barriers.
Organisations should also consider whether their security monitoring includes pre-boot and early-boot phases. Tools that measure the integrity of boot components and drivers before the OS kernel initialises—such as Measured Boot with TPM event logs—can detect unauthorised driver activity. However, this requires infrastructure that supports these capabilities and processes to validate the measurements regularly.
The deeper lesson is that signed, legitimate drivers are a persistent target because they're explicitly trusted by the OS. An attacker with sufficient access doesn't need to find a bug; they can simply invoke the driver's intended functionality in an unintended context. This mirrors supply-chain attack patterns where legitimate software is misused rather than replaced. Infrastructure teams should audit which drivers have kernel privileges, document their intended use, and enforce additional controls around their invocation—especially at boot time, when traditional monitoring is silent.
