BYOVD explained: how attackers abuse legitimately signed but vulnerable Windows kernel drivers to reach Ring 0, disable EDR, and bypass Secure Boot - and how to defend against it.
Bring Your Own Vulnerable Driver (BYOVD) is one of the most effective ways attackers gain kernel-level control of a modern, fully patched Windows machine. Instead of finding a fresh kernel exploit, the adversary simply brings a legitimate, signed driver that already contains a flaw and loads it. Because the driver is validly signed, Windows lets it in - and from Ring 0 the attacker can do almost anything.
Why kernel drivers are such a high-value target
A Windows kernel driver runs at Ring 0, the highest CPU privilege level. At that level there is no meaningful boundary left: code can read and write arbitrary physical memory, patch kernel structures, terminate protected processes, and unhook the callbacks that security products rely on. Compromising a single driver is therefore equivalent to compromising the whole operating system.
How a BYOVD attack works, step by step
- Select a vulnerable driver. The attacker picks a signed driver with a known dangerous primitive - typically an IOCTL that exposes arbitrary read/write of kernel or physical memory, or one that maps physical memory via
MmMapIoSpace.
- Drop and load it. The driver is written to disk and loaded as a service. Default Driver Signature Enforcement (DSE) permits it because the Authenticode signature is valid - even on Secure Boot systems.
- Abuse the primitive. Through the driver's IOCTL interface the attacker reads or writes kernel memory to escalate privileges (for example, stealing the SYSTEM token), disable security callbacks, or unload protections.
- Kill defenses. Many BYOVD campaigns ship purpose-built "EDR killers" that use the borrowed driver to terminate or blind endpoint detection and response agents before deploying ransomware.
Why a valid signature is not safety
This is the core misconception BYOVD exploits. A code signature proves who shipped a driver and that it has not been tampered with. It says nothing about whether the driver is safe. A reputable vendor can - and many have - shipped drivers with exploitable IOCTLs. Once such a driver exists in the wild, it can be reused by anyone, indefinitely. Even revoked or end-of-life drivers remain dangerous because the attacker supplies their own copy.
How to defend against BYOVD
- Microsoft vulnerable driver blocklist. Enable the recommended driver blocklist so known-bad drivers are refused at load time.
- HVCI / Memory Integrity. Hypervisor-Protected Code Integrity validates kernel code and makes many BYOVD primitives far harder to use.
- Secure Boot and DSE. Keep them enabled; they raise the bar even though they do not stop a validly signed vulnerable driver on their own.
- Attack-surface monitoring. Alert on service creation that loads unusual drivers, and on drivers writing to other processes' memory.
- Vet drivers before they run. Check unknown
.sys files against a corpus of known-vulnerable drivers and inspect their IOCTL surface.
How DriverShield helps
DriverShield is purpose-built for exactly this problem. Upload a .sys file or look up its SHA256 and the platform cross-references it against a curated corpus of known vulnerable and malicious drivers, extracts and risk-classifies every IOCTL, flags dangerous kernel imports, verifies the Authenticode chain, and returns a 0-100 risk score with a clear verdict. Browse the BYOVD research index and the CVE library to see which drivers are already known to be abused, or read the analysis methodology for how each signal is scored.