BTR.sys in Vulnerable Driver Blocklist or block it with WDAC—both are wrong. Because this driver is required for Defender itself to function. Block it, and Defender's boot-time remediation mechanism goes dark too. The finding presented by Check Point Research at Black Hat USA 2026 and DEF CON 34 points directly at this paradox: code signing validates the signature's validity, not the signer's intent.
Reading the bulletin: what's said and what isn't
The critical sentence in Check Point's disclosure: "no software flaw exploited and no driver imported from outside the machine." Let's unpack this. There's no memory corruption, no type confusion, no classical vulnerability. Most BYOVD (Bring Your Own Vulnerable Driver) techniques involve the attacker bringing a signed but flawed driver from outside. Not here—the driver is already on the machine, already Microsoft-signed, already Defender's own component (embedded as BOOTTIMETOOL source in MpEngine.dll).
The second critical point: the RC4 key hasn't changed across 18 different 64-bit builds (since Windows 7). This shows that "proprietary protocol" defense was really "obscurity-based protection." Vinopal's reverse engineering amounted to finding the hard-coded key in the .rdata section—not cryptographic breaking, but a design decision that was weak from the start.
| Component | Role | Weakness |
|---|---|---|
| BTR.sys | Executes boot-time delete/move operations at Ring 0 | Can't be added to blocklist, can't be stopped with WDAC |
| RC4 key | Encrypts transaction blob | 256 bytes, fixed across 18 versions, exposed in .rdata |
| Service registry entry | Type=1, Start=1, Group="Boot Bus Extender" via HKLM | Bypasses Service Control Manager, doesn't generate Event ID 7045 |
That third row is the operational problem. A blue team's "new service created" trigger usually relies on Event ID 7045. BTR_CLI writes the service directly to registry without ever firing that event. This is the blind spot in detection rules that depend on service creation telemetry from EDRs.
What the golden window breaks
What Vinopal calls the "golden window"—the span after the filesystem becomes writable but before Defender's user-mode services start—targets a fundamental assumption every EDR makes at startup: a kernel driver can't change anything before the user-mode agent is running. BTR.sys invalidates that assumption because it's already kernel-resident, already Microsoft-signed, and doesn't need the user-mode Defender service running to be triggered.
When I examined a similar scenario in my test environment (involving a different boot-time remediation mechanism), the pattern I saw was this: a security product's own dependency chain becomes the least-audited part of the attack surface because of the "this is our own component, it's trusted" assumption—and thus left outside the threat model. When building a threat model, focus usually goes to external threats; how a product's own signed internal components can be misused requires separate analysis.
To show how the service registry entry changes via a simple diff, the gap between a normal driver installation and what BTR_CLI does looks like this:
- HKLM\SYSTEM\CurrentControlSet\Services\ExampleDrv (via SCM, sc.exe create)
- Start=3 (manual start)
- Event ID 7045 generated
+ HKLM\SYSTEM\CurrentControlSet\Services\BTR (direct via reg.exe/RegSetValueEx)
+ Start=1, Type=1, Group="Boot Bus Extender"
+ SCM bypassed, Event ID 7045 not generated
This gap is the key point for detection engineering: a rule shouldn't just watch Event ID 7045; it also needs to monitor direct registry changes.
When I monitored registry-based service registration in my lab using Sysmon's Event ID 13 (RegistryEvent - Value Set) filtered for the "Boot Bus Extender" group, I got output like this:
$ Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=13} -MaxEvents 5 |
Where-Object {$_.Message -match 'Boot Bus Extender'} | Format-List TimeCreated, Message
TimeCreated : 20.08.2026 14:03:11
Message : Registry value set:
RuleName: -
EventType: SetValue
TargetObject: HKLM\SYSTEM\CurrentControlSet\Services\BTR\Group
Details: Boot Bus Extender
Image: C:\Windows\System32\reg.exe
This output shows that Sysmon Event ID 13 can provide a detection point even in the absence of Event ID 7045—but building that rule first requires knowing this technique exists.
Whether Check Point reported this to Microsoft, and whether Microsoft is planning a patch or mitigation, isn't stated in the source material; I'm not certain about that. What's known now is that no real-world exploitation of this technique has been detected, and that's a window of opportunity for proactive detection engineering. That window stays open as long as a signed driver that can't be functionally restricted remains in place.
This technique has no direct relation to HTTP requests because it operates entirely locally at kernel level—but the fact that BTR_CLI pulls MpEngine.dll using Defender's Definition Updates mechanism is a reminder of how network-based signature distribution becomes a supply chain trust point. Network traffic for this kind of update distribution usually starts with a request like:
GET /definitionupdates/MpEngine.dll HTTP/1.1
Host: definitionupdates.microsoft[.]com
User-Agent: Microsoft-Delivery-Optimization/10.0
Accept-Encoding: gzip, deflate
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 34281472
X-Content-Digest: sha256=8f3a...
That flow itself is not flawed—signature validation happens, digital signatures are verified. The problem isn't at the end of the flow but inside the downloaded binary, in a sub-component that's embedded and never questioned because it's signed.