Check Point Research has disclosed a technique that abuses Microsoft Defender's own boot-time remediation driver to perform arbitrary kernel-level operations on Windows systems from version 7 through 11 25H2. The attack requires no software vulnerability, no external driver injection, and no code signing bypass—just abuse of a legitimately signed Microsoft component already present on the system.

How BTR.sys Becomes an Attack Vector

The driver in question, BTR.sys (Boot Time Removal Tool), is designed to run at boot time with full kernel privileges. Its legitimate purpose is to remove malware before the Windows kernel fully loads, making it a trusted component that bypasses standard driver signing and load-time verification. This is exactly the kind of early-boot access that makes it attractive to threat actors.

The technique discovered by Check Point Research demonstrates that an attacker with local code execution (or direct system access during boot) can redirect the driver's legitimate file and registry operations toward arbitrary targets. Rather than removing a specific malware sample, the driver can be made to delete security software, modify system configurations, or install persistence mechanisms—all before the operating system's standard security checks activate.

Why This Matters for Hosted Windows Systems

For operators of Windows VPS, dedicated servers, or hybrid infrastructure, this represents a meaningful escalation path. An attacker who gains initial access to a Windows instance—whether through a web application vulnerability, stolen credentials, or insider access—can potentially weaponise BTR.sys to disable endpoint protection without triggering obvious security alerts during normal runtime.

The attack surface is particularly relevant in multi-tenant environments where kernel-level access might be harder to detect immediately. Once a malicious actor reaches kernel mode via this driver, they operate outside the visibility of standard user-mode security tools and event logs.

Boot-time attacks are inherently difficult to detect after the fact because the system initialises with the attacker already in control. By the time Windows finishes booting and security monitoring tools activate, the damage—or persistence mechanism—is already in place.

Mitigation and Detection Strategy

Immediate steps include disabling or restricting BTR.sys where Defender's boot-time remediation is not actively required. On systems where early-boot malware removal is necessary, consider:

Microsoft has not disclosed whether this is a design flaw or expected behaviour. Since no CVE vulnerability is involved, standard patching cycles may not address it. The recommendation is to treat this as a configuration hardening issue rather than waiting for a security update.

Broader Implications for Windows Infrastructure

This disclosure reinforces a long-standing principle in system security: legitimate, trusted, privileged code is a high-value target. Boot-time drivers occupy a special position because they run before almost everything else, and they carry implicit trust built into the operating system.

For anyone operating Windows dedicated servers or VPS infrastructure, the lesson is straightforward. Assume that standard endpoint protection tools, while valuable, are not a complete security boundary. Kernel-level access requires layered defences: restrictive physical/administrative access, boot-time integrity verification, and continuous kernel activity monitoring.

The fact that this technique works on unpatched Windows 7 systems through the latest Windows 11 versions indicates this is a structural issue rather than a recent regression. Organisations still running older Windows versions in production should treat this as an additional reason to accelerate migration plans.