BYOVD Is Out of Control and Nobody's Fixing It

Another week, another ransomware gang using vulnerable drivers to disable security tools before encrypting everything.

This time it was a manufacturing company. Attackers dropped a vulnerable Gigabyte driver (gdrv.sys - yes, the same one from 2018), used it to kill their EDR agent, and had free run of the environment for six hours before anyone noticed.

I’m tired of writing about BYOVD. But until something changes, here we are.

Quick Primer

For those unfamiliar: Bring Your Own Vulnerable Driver (BYOVD) is a technique where attackers:

1. Bring a legitimately signed but vulnerable driver onto the system
2. Load the driver (Windows trusts it because it’s signed)
3. Exploit the vulnerability to get kernel access
4. Use that access to disable security tools

The genius/horror of it: the driver is legitimately signed by Microsoft’s WHQL process. Windows has no way to distinguish “legitimate driver” from “legitimate driver being abused.”

The Usual Suspects

The same drivers keep appearing in attacks:

Driver	Vendor	CVE	Years Known
gdrv.sys	Gigabyte	Multiple	6+ years
AsIO.sys	ASUS	2022-26522	3 years
DBUtil_2_3.sys	Dell	2021-21551	4 years
RTCore64.sys	MSI	2019-16098	6 years
ProcExp.sys	Microsoft (!)	-	2 years

That last one hurts. Microsoft’s own Process Explorer driver, signed by Microsoft, routinely used to kill EDR.

The drivers that were vulnerable in 2019 are still being used in 2025. Let that sink in.

Why It’s Getting Worse

Attackers Have Toolkits Now

It used to require real skill to weaponize a vulnerable driver. Now there are ready-made tools:

• Backstab - EDR killer using Process Explorer driver
• Terminator - Commercial “security tool” being abused
• AuKill - Used by multiple ransomware groups
• Various private tools shared in underground forums

The barrier to entry dropped dramatically.

EDR Dependency

We’ve bet heavily on EDR as a security control. When EDR works, it’s great. But it’s a single point of failure.

Attackers know this. “Disable EDR, then do whatever” has become standard operating procedure.

The sequence in most modern intrusions:

1. Get initial access
2. Find and disable security tools
3. Profit

Step 2 increasingly involves BYOVD.

Microsoft’s Driver Blocklist Is Inadequate

Yes, Microsoft has a vulnerable driver blocklist. Problems:

1. It’s not enabled by default on most systems
2. It only updates with Windows updates
3. It doesn’t cover all known-vulnerable drivers
4. Attackers find new vulnerable drivers constantly

I checked our incident. The driver used (gdrv.sys) was on the blocklist. But the client’s systems hadn’t updated in months because of “compatibility concerns.”

The Manufacturing Incident

Let me share some details from the recent case (sanitized, obviously).

Initial access: Compromised VPN credentials (purchased, probably from an infostealer)

Day 1: Attackers establish foothold, basic reconnaissance

Day 2: Deploy Cobalt Strike, move laterally

Day 3, 2:47 AM: Drop gdrv.sys, load driver, terminate EDR processes across 40+ systems

Day 3, 3:15 AM: Begin encryption

Day 3, 8:30 AM: First employee arrives, discovers ransom notes

The EDR was “working” right up until it wasn’t. The console showed agents healthy, then suddenly 40 went offline. By the time someone noticed, encryption was well underway.

Total time from EDR kill to detection: ~5.5 hours.

What’s Actually Helping

Based on what I’ve seen work:

1. HVCI/Memory Integrity

Hypervisor-Enforced Code Integrity blocks unsigned drivers and some vulnerable signed drivers. It’s one of the few technical controls that helps.

Problems:

• Not on by default for most devices
• Compatibility issues with some software
• Can be disabled if attacker has admin rights before enabling

Still worth enabling where possible.

2. Driver Load Monitoring

Alert on any driver load, especially:

• Drivers not in a known-good baseline
• Drivers with known vulnerabilities
• Any driver load outside of maintenance windows

You might not block the load, but at least you’ll know.

3. Redundant Detection

Don’t rely solely on EDR. Have:

• Network-level detection (they can’t kill your cloud SIEM from the endpoint)
• Out-of-band monitoring
• Canary files and accounts that trigger alerts

If EDR dies, you need another way to know.

4. Reduce Admin Rights

BYOVD requires admin privileges to load drivers. Users without admin rights can’t load vulnerable drivers.

This is basic, but “everyone is admin” is still depressingly common.

What I Wish Would Happen

Microsoft: Fix the Trust Model

The fundamental problem: Windows trusts signed drivers, and signature revocation doesn’t work well.

Ideas that would help:

• Make the vulnerable driver blocklist more comprehensive and update it faster
• Enable memory integrity by default on new devices
• Create a “known-good driver” allowlist option for enterprises
• Better telemetry on driver loads

Vendors: Actually Revoke Vulnerable Drivers

When a driver is found vulnerable, the vendor should revoke its certificate and push the revocation widely. This rarely happens.

The vulnerable Gigabyte driver has valid signatures despite being known-vulnerable for years.

Enterprises: Defense in Depth

Stop treating EDR as a silver bullet. It’s one layer.

• EDR can be disabled
• AV can be disabled
• Anything on the endpoint can be disabled by someone with kernel access

Your detection strategy needs to account for this.

Cynical Prediction

Nothing will fundamentally change.

Microsoft won’t break compatibility by blocking old signed drivers aggressively. Vendors won’t revoke their own certificates. Enterprises won’t magically fix their patch management.

We’ll keep playing whack-a-mole: new vulnerable driver discovered, gets abused for months/years, eventually gets blocked, attackers move to next driver.

The economics don’t incentivize real solutions.

Practical Takeaways

If you’re a defender:

1. Enable HVCI/Memory Integrity where possible
2. Monitor driver loads and alert on anomalies
3. Keep the vulnerable driver blocklist updated (it’s a separate update from Windows Update)
4. Have detection that works even if EDR fails
5. Reduce admin rights to reduce who can load drivers

If you’re in leadership:

1. Ask your security team: “What happens if our EDR gets disabled?”
2. If the answer is “we wouldn’t know,” that’s a problem
3. Invest in detection diversity, not just EDR

If you’re an attacker: you already know all this, which is why you keep winning.

---

BYOVD works because we built a trust model that can’t distinguish legitimate use from abuse. Until that changes, we’re stuck reacting to each new vulnerable driver as it’s weaponized.