Loading today’s stories
Security1 distinct publisher3 min readUpdated
Check Point's BTR Reforged turns a required Defender component into Ring 0 file and registry deletion on Windows 7 through 11 25H2. It cannot be blocklisted, so detection is the only lever left.
The Watch · Security desk
Compiled by The WatchSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
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 [7], 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 [9]. WdFilter.sys and MsMpEng.exe are deleted before they exist as processes capable of locking themselves [9]. The Black Hat demonstration against a fully updated Windows 11 25H2 host with Tamper Protection active [10] 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 [6]. Zero rotations in 18 sampled builds [1] 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 [5][6].
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 [13][11]. 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 [15]. Five years and six months separate that fix from this disclosure [2]. 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 [7], and execution is attributed to the System process at PID 4 [8], 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 [4], 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 [3].
Ranked by verification strength, evidence, and original report placement.
BTR.sys (Boot Time Removal Tool) is a required Windows component, which means it cannot be added to Microsoft's Vulnerable Driver Blocklist or blocked via Windows Defender Application Control without disrupting Defender itself.
Unlike bring your own vulnerable driver attacks, which depend on known-vulnerable third-party signed drivers that can be added to blocklists, the BTR Reforged technique uses a driver built into every Windows installation from Windows 7 onward.
Vinopal's GitHub repository for BTR_CLI states that "No patch is planned", a characterization Microsoft has not confirmed publicly.
In February 2021, SentinelLabs researcher Kasif Dekel disclosed CVE-2021-24092, a privilege escalation vulnerability in the same driver that allowed a local non-administrator to overwrite arbitrary files by placing a hard link at the driver's log path.
Check Point Research disclosed a technique that uses Microsoft Defender's legitimately signed boot-time remediation driver to perform arbitrary kernel-level file and registry operations on Windows systems from Windows 7 through Windows 11 25H2, with no software flaw exploited and no driver imported from outside the machine.
Jiri Vinopal, a threat researcher and reverse engineer at Check Point Research, presented the findings as a main-stage briefing at Black Hat USA 2026 and DEF CON 34 in Las Vegas and published the research paper alongside a proof-of-concept tool, BTR_CLI, on August 20, 2026.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed first-party technical evidence, single publisher, no independent replication
The mechanism is described at artifact level — embedded BOOTTIMETOOL resource, a hard-coded RC4 key stable across 18 builds, registry-only service install with no Event ID 7045, Ring 0 operations attributed to PID 4 — and is backed by a published paper, a released PoC, and a live on-stage demonstration against a patched Windows 11 25H2 host. What holds the score down is provenance: one publisher reporting one vendor's research, with no Microsoft statement and no independent reproduction in the supplied material.
Public PoC and conference exposure, but no observed real-world use
Adoption of the technique itself is near-floor by the researcher's own measurement: Check Point states it found no evidence of real-world abuse across all collected samples and telemetry. What has been adopted is exposure — a published paper, a public PoC, and two main-stage briefings — plus a defender-side starting point in the form of named Sysmon and Windows event conditions. No deployment of mitigations or detections by any operator is reported.
Mildly overstated: real primitive, softened by admin precondition and unconfirmed patch posture
The technical substance largely matches the framing — the driver genuinely cannot be blocklisted without breaking Defender, and the boot-time deletion was demonstrated. Two things push the framing ahead of the evidence: exploitation requires an administrator already holding SeLoadDriverPrivilege, a threshold at which many kernel-tampering options exist, and the 'not servicing it / no patch planned' posture comes from Check Point's relay of MSRC plus a GitHub note rather than any Microsoft statement. Check Point's own telemetry reports zero in-the-wild abuse, which argues against urgency framing.
Vendor research with detection-market and conference-visibility incentives
The disclosing party is a commercial security vendor publishing under its own research brand, presenting on two main stages and shipping a named PoC, with the practical conclusion that detection — the vendor's product domain — is the only remaining lever. That is a visible incentive to emphasize severity and unservicability. Offsetting factors are that Check Point voluntarily disclosed the absence of in-the-wild abuse, published concrete hunting artifacts others can validate, and stated the administrative precondition plainly. No pricing, contract, or commercial-relationship facts are supplied, so this is scored on disclosure posture alone.
Technically well-specified but single-publisher and one-sided
Confidence is moderate: the claims are unusually specific and internally consistent, dated, and tied to named artifacts and a demonstrated result, which supports the technical core. It is held back by structural thinness — one publisher, one originating vendor, no Microsoft comment, no independent reproduction — which is exactly where the servicing and permanence claims live.
build
ShieldBreak: a Defender-to-SYSTEM PoC that your last patch cycle did not stop1 distinct publisher
security
Defender's own signed driver becomes the bypass: BTR.sys and the week's trusted-component defects1 distinct publisher
build
Microsoft is generating its detection test logs, and admitting what they do not prove1 distinct publisher
security
The bottleneck moved: 622 CVEs in July, and no one left to write up the fixes1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 21, 2026