Defender's own boot driver is a kernel delete primitive, and Microsoft is not servicing it

Tamper Protection defends a Defender that is running. The technique never fights it. BTR_CLI registers the driver with Start=1 in the "Boot Bus Extender" group ^[5], which places it in the boot order ahead of the software it is told to remove, and the queued operations run in the interval after the filesystem becomes writable but before Defender's user-mode services start, which Vinopal calls the golden window ^[7]. WdFilter.sys and MsMpEng.exe are deleted before they exist as processes capable of locking themselves ^[7]. The Black Hat demonstration against a fully updated Windows 11 25H2 host with Tamper Protection active ^[8] is the arithmetic of that ordering, not a defeat of the protection's logic.

The other durable detail is the key. Every configuration blob handed to BTR.sys is RC4-encrypted with a 256-byte key sitting in the .rdata section of every build shipped since Windows 7, and Check Point verified it unchanged across 18 distinct 64-bit versions ^[4]. Zero rotations in 18 sampled builds ^[15] cuts both ways. It means a tool written once keeps working across a decade of Windows, and it also means the transaction format is a stable artifact defenders can write signatures against. Rotating the key per build would raise the cost of maintaining an offline toolchain, though the key ships inside the binary on every machine that has Defender, so anyone who can read MpEngine.dll can read the key ^[3][4].

Microsoft's position is that this is not a vulnerability but an architectural trust boundary crossed by an attacker who already holds administrative privileges, and MSRC told Check Point the findings do not meet the criteria for immediate servicing because the technique depends on SeLoadDriverPrivilege ^[11][9]. That is a consistent line. It is also worth noting what the same driver got in February 2021, when SentinelLabs' Kasif Dekel disclosed CVE-2021-24092, an arbitrary file overwrite reachable by a local non-administrator through a hard link at the driver's log path ^[14]. Five years and six months separate that fix from this disclosure ^[16]. The boundary moved from "non-admin can abuse BTR.sys" to "admin can abuse BTR.sys," and only one of those buys a patch.

So the defensive surface is narrow and specific. Service installation via direct HKLM writes skips the Service Control Manager and produces no Event ID 7045 ^[5], and execution is attributed to the System process at PID 4 ^[6], which removes the two artefacts most hunting content assumes: a service-install event and a suspicious parent. What remains is the registry write itself, the shape of the encrypted transaction, and the deletion of Defender binaries by PID 4 during boot. Check Point says it saw no evidence of real-world abuse in its samples and telemetry ^[2], which is the only reason that detection work can be done before it is needed rather than during an incident. BTR_CLI has been public since August 20, 2026 ^[13].