The BYOVD Arms Race: 34 Vulnerable Drivers Fueling 54 EDR Killers
Just caught the latest analysis on THN regarding the explosion of EDR killers leveraging the Bring Your Own Vulnerable Driver (BYOVD) technique. It’s staggering to see that 54 distinct tools are currently abusing just 34 signed drivers to bypass security controls.
The mechanics are nothing new—loading a legitimate, signed driver with a known vulnerability (often an arbitrary memory read/write primitive) to disarm kernel callbacks or kill EDR processes—but the scale is increasing. Ransomware affiliates are standardizing this because traditional userland AV/EDR hooks are too easily detected. If you have RWX (Read-Write-Execute) rights in the kernel, it's game over for the security stack.
For those hunting for this, simply relying on certificate validity isn't enough. We need to focus on the reputation of the specific driver hash and the loading context. I’ve been updating our Sigma rules to flag specific driver loads, even if they are signed.
Here is a basic KQL query for Sysmon (Event ID 6) to look for high-risk driver loads that are often abused in these campaigns:
Sysmon
| where EventID == 6
| where SignatureStatus == "Valid"
| where ImageLoaded in~ ("RTCore64.sys", "dbutil_2_3.sys", "procexp123.sys", "gdrv.sys")
| project TimeGenerated, Computer, ImageLoaded, Hashes, Signature, Signed
| extend DriverHash = extract("^(SHA256=)?([A-Fa-f0-9]{64})", 2, Hashes)
Are you all seeing success with Microsoft's vulnerable driver blocklist, or is it too reactive given the speed of new EDR killers popping up?
We've forced the vulnerable driver blocklist via Intune, but it's definitely a cat-and-mouse game. The report mentions 34 specific drivers; the moment a new one pops up in the wild, we're blind until the next update. We've had to supplement with application control policies (AppLocker/WDAC) to explicitly deny specific hashes, which is heavy on management but necessary for our high-value targets.
From a Red Team perspective, BYOVD is often the only reliable path against modern EDRs. Userland unhooking is detected too quickly. We specifically look for drivers exposing functions like MmCopyVirtualMemory without proper IOCTL validation. If you aren't enforcing HVCI (Hypervisor-protected Code Integrity) at the hardware level, you're making it trivial for attackers to map payloads into kernel space.
I'd add monitoring for ERROR_PRIVILEGE_NOT_HELD failures when loading drivers. Often, these tools need SeLoadDriverPrivilege. If a non-admin process tries to load a driver and fails, it's a huge IOC. Also, check for unexpected service creation events pointing to driver.sys files dropped in \System32\drivers\.
To expand on Tanya's point, relying solely on blocklists is reactive. Enabling Hypervisor-Protected Code Integrity (HVCI) is a strong proactive control. Even if a signed vulnerable driver loads, HVCI often blocks the kernel memory modifications required to disable callbacks. Verify your coverage with:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard
Priya is right, HVCI is the strongest control here, provided it's strictly enforced. The real challenge we face is drivers loaded from memory rather than disk to evade standard scanning. To ensure your defenses are actually active, you can verify HVCI and VBS status locally with:
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select-Object SecurityServicesConfigured, SecurityServicesRunning
To complement HVCI, ensure you're logging Sysmon Event ID 6. While HVCI prevents exploitation, logging is vital for detecting attempts involving new drivers not yet on blocklists. We filter for suspicious signature states to catch these quickly:
Sysmon
| where EventID == 6
| where SignatureStatus !in ("Valid")
| project TimeGenerated, ImageLoaded, Signature, Subject
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access