When the EDR Goes Quiet: Detecting BYOVD Driver Kills Before the Encryptor Runs

EDR killers stopped being exotic a while ago. They are a routine stage in ransomware intrusions: get to SYSTEM, disable the sensor, then run the encryptor against a host that can no longer see itself. ESET’s March 2026 writeup put numbers on it that are worth sitting with: nearly 90 distinct EDR killers in active use, 54 of them built on bring-your-own-vulnerable-driver (BYOVD), abusing 35 different legitimately signed drivers. That is according to ESET telemetry, and it lines up with what the broader threat-intel reporting has been saying for two years. The part that matters for you is the sequencing. By the time the killer executes, the operator already holds local admin or SYSTEM and the encryptor is seconds behind. Your detection budget is spent before that moment, or it is spent on the incident review.

What BYOVD actually does to your sensor

EDR visibility on Windows is built on kernel callbacks. The agent registers process-creation, thread-creation, and image-load notify routines, plus object-handle callbacks through documented kernel interfaces, and that is how it sees what userland is doing. A signed-but-vulnerable driver that exposes an arbitrary kernel read/write primitive, or a process-terminate IOCTL, gives a userland tool a path into kernel memory to rip those callbacks out or kill the protected processes directly. The driver loads because Code Integrity sees a valid signature from a real vendor. That is the whole trick. It is not a zero-day in your EDR; it is a property of the driver trust model being used as designed.

The drivers themselves are commodities. The same handful keeps coming back: Truesight.sys, Avast’s aswArPot.sys, ThrottleStop.sys, rentdrv2.sys, Baidu’s BdApiUtil.sys, ThreatFire’s TfSysMon.sys. ESET’s point about attribution is the one defenders keep getting wrong: the same driver shows up in unrelated tools and the same tool switches drivers between builds, so the driver alone tells you almost nothing about who is on the box.

Why affiliates reach for this instead of hardening the encryptor is simple economics. Encryptors are noisy by nature, since they have to touch a lot of files fast, and keeping every new build undetected is expensive. Disabling the sensor once, with a tool you bought or forked, is cheaper and more repeatable. ESET’s framing is blunt and correct: EDR killers endure because they are “cheap, consistent, and decoupled from the encryptor.”

Why the obvious control is the weakest one

The instinct is to block the driver. Microsoft’s vulnerable driver blocklist plus HVCI (memory integrity) is the sanctioned answer, and yes, turn it on. But understand what you are getting.

The built-in blocklist updates roughly on the OS servicing cadence, not continuously. There was a stretch (see KB5020779) where it simply was not updating on some configurations, and even working as intended it lags the threat. A driver weaponized this month is not going to be on a list that ships with feature updates. Hash-based blocking fails for a more structural reason: Check Point showed in February 2025 that attackers produced over 2,500 distinct, still-validly-signed samples of Truesight.sys by exploiting a weakness in how signature validity gets checked. A year later, in February 2026, Huntress documented EnPortv.sys being abused even though its certificate was expired and explicitly revoked. Revocation is not the backstop people assume.

Then there is the operational cost nobody likes to say out loud. Aggressive driver blocking breaks things. ThrottleStop’s driver ships inside real OEM thermal utilities; aswArPot belongs to a real product. Block by file attributes too broadly and you knock over the legacy backup agent or the vendor utility that someone in facilities depends on, during an incident, which is the worst time to be debugging a Code Integrity policy.

HVCI is the strongest preventive control here, because it constrains what can run in the kernel at all. It is also frequently off, because driver compatibility kills it. On a Windows Server 2019/2022 fleet, assume it is disabled until proven otherwise. On Windows 11 workstations shipped with memory integrity and Smart App Control left at defaults, it is more likely on. If you are running to a DISA STIG or FedRAMP High baseline, you are being pushed toward enabling memory integrity and the blocklist where the hardware and driver inventory allow, and that pressure is justified, but “where the inventory allows” is doing real work in that sentence.

Detect the staging and the silence, not just the load

There are three places to look, and they are not equally useful.

Driver-load telemetry. Sysmon Event ID 6 gives you ImageLoaded, Signature, SignatureStatus, and Hashes. Useful, with a caveat the Sysmon community guide is honest about: EID 6 does not give you the process that loaded the driver, and its coverage of very-early-boot loads is incomplete. So you do not hunt on “unsigned” (these are signed). You hunt on rarity and path. Kernel drivers loading from C:\Users, C:\ProgramData, or C:\Windows\Temp instead of \System32\drivers are worth a look every time. Stack first-seen driver hashes across the estate: a driver that appears on exactly one host, signed by a vendor you do not deploy, is the thing.

Service creation. A kernel driver load means a service. System log Event ID 7045, or Sysmon 13 on HKLM\SYSTEM\CurrentControlSet\Services, with a Type 1 (kernel) service whose ImagePath points at a .sys in a user-writable directory. Lower volume than EID 6, higher fidelity, and honestly the better place to start if you are picking one.

If the blocklist or HVCI is enforcing, blocks land in Microsoft-Windows-CodeIntegrity/Operational (3077 for enforcement, 3076 for audit, 3033 for the broader signing-requirement failure). Run the blocklist in audit before you enforce so you find out which of your own drivers it would have killed.

None of that catches a driverless kill, though, and that gap is the point. EDRSilencer adds Windows Filtering Platform filters to drop the agent’s outbound traffic; EDR-Freeze suspends the agent process into a coma. Neither loads a driver. What they share with the BYOVD approach is the outcome: the sensor stops reporting while the host is still alive. So the detection that actually generalizes is the absence of telemetry.

Baseline agent check-in per host and alert when a host that normally reports goes silent while other liveness signals say it is up. Rough shape in Splunk:

| tstats latest(_time) as last_seen where index=edr by host
| eval gap=now()-last_seen
| where gap > 900
| lookup asset_liveness host OUTPUT last_auth
| where now()-last_auth < 600

A 15-minute reporting gap on a host that authenticated to AD in the last 10 minutes is a host that is alive and blind. That is the condition you care about.

The false positives write themselves: laptops sleeping, VPN drops, patch windows, decommissioned machines still sitting in the asset lookup, the agent that dies at 0300 and self-restarts before the on-call notices. First-round tuning is mostly scoping. Start with servers, because a production server going quiet is anomalous in a way a laptop is not; exclude known maintenance windows; and require the corroborating liveness signal so you are not paging because someone shut a lid. In a few-thousand-host estate, expect the raw gap query to light up constantly for the first week until the sleep and VPN behavior is carved out and the threshold is moved off 15 minutes onto whatever your environment actually tolerates. One more trap: host clock skew breaks the gap math, so compute against index time rather than the event’s own _time, or skewed hosts look permanently dead.

Where to actually spend the budget

BYOVD runs after the attacker has admin. That single fact reorders the priorities. The earlier and richer detections live upstream: the privilege escalation, the credential theft, the lateral movement that handed them SYSTEM in the first place. Deny the admin and the kill never gets a chance to load anything. The driver load is the last reliable chokepoint before encryption, and you should instrument it, but if it is your only detection you are catching the intrusion at the worst possible second.

Turn the blocklist on, treat it as the floor, and assume it lags. The detection that pays for itself is the telemetry-gap monitor backed by driver-staging hunts, because it survives driver switching and catches the driverless tools too. The prevention that pays for itself is HVCI, on every host where your hardware and driver inventory let you keep it on. Anything past that is hoping the blocklist shipped an update before the affiliate did, and that is not a bet the index data supports.

Sources

• EDR killers explained: Beyond the drivers (WeLiveSecurity)
• 54 EDR Killers Use BYOVD to Exploit 35 Signed Vulnerable Drivers and Disable Security (The Hacker News)
• Large scale exploitation of a legacy driver (Check Point Research)
• enCase: a BYOVD EDR killer (Huntress)
• Microsoft recommended driver block rules (Microsoft Learn)
• KB5020779 – The vulnerable driver blocklist after the October 2022 preview release (Microsoft Support)
• Sysmon Community Guide: driver loading (TrustedSec, GitHub)
• Steer clear of bad drivers with Microsoft’s recommended driver block rules (Red Canary)