Your EDR cost six figures. Your CFO signed off on it. Your CISO put it in the board presentation. And a threat actor just killed it with a 25-year-old signed printer driver before anyone got out of bed.
That’s BYOVD in 2026. Not a niche APT trick anymore — 54 distinct EDR killer tools are actively weaponizing 35 different vulnerable drivers right now. The Reynolds ransomware gang literally ships a BYOVD driver inside their payload. It’s not tradecraft anymore — it’s a product feature.
Let me break down why this attack class keeps winning and what’s actually going on under the hood.
What “Bring Your Own Vulnerable Driver” Actually Means at Ring 0
Most people explain BYOVD at the altitude of a Wikipedia article. Here’s what’s actually happening:
Windows enforces Driver Signature Enforcement (DSE) — you can’t load unsigned kernel code on a modern system. But signed ≠ safe. Vulnerable drivers from legitimate vendors (network tools, antivirus utilities, even forensic software) have accumulated CVEs for years. They’re still signed with valid certs. Windows will load them, no questions asked.
Once your vulnerable driver is running at Ring 0, the game changes entirely. Kernel space means:
- You can directly manipulate
PspCreateProcessNotifyRoutine— the array of callbacks EDRs register to watch process creation - You can remove
ObRegisterCallbacksobject callbacks that protect EDR processes from termination - You can blind the ETW Microsoft-Windows-Threat-Intelligence provider that logs LSASS access, process injection, and other high-value events
- You can just straight-up call
ZwTerminateProcessfrom kernel context to kill the EDR process, and no userland hook will catch you
Here’s a simplified view of what wsftprm.sys (CVE-2023-52271) exploitation looks like — this driver caught heat because it loads fine on fully patched Windows 11 with Secure Boot and HVCI enabled:
// Load the vulnerable driver
sc create wsftprm binPath= "C:\Windows\System32\drivers\wsftprm.sys" type= kernel
sc start wsftprm
// Send malicious IOCTL to trigger ZwTerminateProcess at kernel level
// IOCTL code varies by driver — enumerate with IDA/Ghidra first
DeviceIoControl(hDevice, IOCTL_KILL_PROCESS, &pid, sizeof(DWORD), NULL, 0, &bytesRet, NULL);
That’s it. EDR process dead. No alerts fired. Your beacon is now the loudest thing on the box.
The Tools That Are Doing This Right Now
I’ve been tracking this for a while and the public tooling has gotten genuinely impressive. Here’s what’s worth knowing:
EDRSandblast — The OG. Wavestone dropped this and it’s still one of the cleanest implementations. It handles kernel callback removal, ETW-TI disabling, and userland unhooking in one package. If you’re doing authorized red team work and want to understand the full chain, this is where I’d start.
# EDRSandblast: kill callbacks + userland unhook in one shot
EDRSandblast.exe --kernelmode --usermode --verbose
BlackSnufkin/BYOVD — A collection of PoCs targeting drivers NOT on LOLDrivers blocklist. The ones on the blocklist are tourist traps at this point — defenders know to watch for them. This repo goes after the weird stuff.
Sigurd — Written in Rust, supports multiple vulnerable drivers, built for operational use. The Rust angle is interesting — harder to reverse, smaller footprint, no CRT dependencies.
0xJs/BYOVD_EDRKiller — Straightforward, documented, good for understanding the flow. Uses wsftprm.sys by default.
And for the driverless angle — EDRSilencer — this doesn’t kill the EDR, it just cuts off its telemetry by blocking outbound connections with WFP (Windows Filtering Platform). The EDR is alive and “healthy” on the dashboard, but none of its events reach the SIEM. Sneakier. I actually prefer this on engagements where I want to maintain stealth rather than brute-force kill the sensor.
The Move That Burns Me Every Time: Driver Blocklist Complacency
I’ve run internal red team reviews where the blue team was confident because they had “the Microsoft driver blocklist deployed.” That blocklist has somewhere around 200 entries. There are thousands of signed vulnerable drivers in the wild.
The loldrivers.io project currently tracks hundreds of vulnerable/malicious drivers and that list is incomplete. Researchers find new exploitable drivers routinely — the attack surface isn’t shrinking.
Here’s the OPSEC move that most red teamers miss: don’t use the famous drivers. The moment you try to load RTCore64.sys or gdrv.sys, you’re triggering alerts at every mature SOC. The smart play is enumeration:
# Find signed drivers on a target with known CVEs not in blocklist
# Cross-reference output against loldrivers.io API
Get-WmiObject Win32_SystemDriver | Select-Object Name, PathName, State |
Where-Object { $_.State -eq "Running" } |
Export-Csv drivers.csv
# Then check each against loldrivers.io
curl "https://www.loldrivers.io/api/drivers.json" | jq '.[] | select(.Tags[] | contains("vulnerable"))'
Or better — target drivers already present on the victim machine. If you can find a vulnerable driver they already have loaded for legitimate purposes, you don’t even need to drop a file. Zero new artifacts.
What EnCase Taught Me About Revocation (The Hard Way)
Earlier this year, someone used an old EnCase forensic driver in a live BYOVD attack. A forensic tool. The kind blue teams literally use for incident response.
The reason this works is subtle: Windows doesn’t always validate certificate revocation lists at kernel load time. DSE checks the signature chain but doesn’t necessarily phone home to check if the cert was revoked. So a driver signed with a cert that was revoked three years ago can still load in certain conditions.
This is why certificate revocation as a defense is weaker than people think. HVCI helps — a lot — but the wsftprm.sys issue proved even that’s not a guarantee. The driver was able to load on HVCI-enabled systems because it carries a valid (non-revoked) signature, and HVCI’s WDAC policy didn’t cover it.
The lesson: your kernel attack surface is defined by every signed .sys file that Windows will load, ever. That’s a big surface.
My Take: The Vendors Are Playing Defense on the Wrong Field
Every EDR vendor’s blog post about BYOVD ends with “we detect the known malicious drivers.” That’s true. They do. But the entire attack model assumes the attacker brings an unknown or low-prevalence driver.
The correct defense isn’t blocklist expansion — it’s kernel telemetry attestation. If your EDR process gets killed, something in your monitoring stack needs to notice that and alert immediately, independent of the endpoint agent. Crowdstrike and SentinelOne have cloud-based heartbeat detection for this. Most customers don’t have it configured to alert aggressively enough. I’ve seen engagements where our beacon killed the EDR and the SOC noticed… four hours later. By then, we’d been through three domain controllers and had golden tickets.
The other defense that actually works: Microsoft’s Vulnerable Driver Blocklist pushed via Windows Update + HVCI enforced + Audit logging for driver load events (Event ID 7045). Stack all three and you make BYOVD significantly harder, though not impossible.
# Check if HVCI is enabled
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus, CodeIntegrityPolicyEnforcementStatus
# Monitor new driver installs - Event ID 7045
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7045} |
Select-Object TimeCreated, Message | Format-List
What You Should Do Right Now
If you’re red teaming: stop reaching for the obvious drivers. Spend two hours on loldrivers.io and find three drivers not in the blocklist. Test them in a lab. You’ll be surprised what still works.
If you’re defending: check if your EDR has a “sensor health” alert configured for agent kill/disconnect. If it doesn’t, you’re flying blind when BYOVD hits. Set a 5-minute SLA on that alert. Five minutes. Not four hours.
Either way — read this Wavestone deep dive and the ESET breakdown of EDR killers. This is not theoretical. Reynolds ransomware embedded it in their default payload. The technique is commoditized.
Hot Take: The EDR Market Is Selling You Confidence, Not Coverage
Here’s the thing nobody says out loud at vendor conferences: your EDR is a userland process. At the end of the day, it’s a .exe with a signed driver, and any code running at the same privilege level or higher can ruin its day. The whole “next-gen AI behavioral detection” pitch means nothing if I can kill the sensor before it phones home.
The vendors know this. The mature ones are building kernel attestation, cloud-based corroboration, and HWID-locked sensor certificates to make tampering detectable. But most enterprise deployments are still on default configs, default heartbeat intervals, and default alerting thresholds — which is basically “trust the endpoint until proven otherwise.”
If your threat model includes ransomware gangs (and it should, because they’re now shipping BYOVD in their off-the-shelf payloads), your EDR is not your last line of defense. It might not even be your third. Build your detection strategy assuming the endpoint agent is compromised and work backwards from there.
That’s not a scary thought. That’s just realistic tradecraft in 2026.
