BYOVD (Bring Your Own Vulnerable Driver)

Definition

An attack technique where threat actors load a legitimate but vulnerable kernel-mode driver into a target system to exploit that driver's vulnerabilities for kernel-level code execution, security tool disabling, or privilege escalation — bypassing driver signing enforcement by using a Microsoft-signed legitimate driver.

Technical Details

Windows requires kernel-mode drivers to be signed by Microsoft through its Windows Hardware Quality Labs (WHQL) or attestation signing process. This requirement, enforced through Secure Boot and kernel code signing policies, is designed to prevent malicious code from running at the kernel level. BYOVD attacks circumvent this protection by using legitimate drivers that have already been signed by Microsoft but contain exploitable vulnerabilities — typically memory corruption bugs that provide kernel-level code execution when triggered from user space. The attacker's workflow involves: obtaining a vulnerable legitimate driver (either from a gaming anti-cheat system, hardware manufacturer utility, or security software), dropping it to disk and loading it using Windows service control manager or other driver loading mechanisms, and then sending specially crafted IOCTLs (I/O Control Codes) to the driver to trigger its vulnerability. Because the driver is legitimately signed, Windows kernel protection mechanisms (Driver Signature Enforcement, PatchGuard) do not prevent its loading. Once kernel-level code execution is achieved, the attacker can disable EDR agents, security kernel callbacks, and other protective mechanisms — a technique called 'kernel callback removal' or 'EDR unhooking at the kernel level'. Notable examples of drivers abused in BYOVD attacks include: gdrv.sys (GIGABYTE driver), WinRing0.sys (hardware monitoring driver used by gaming tools), iqvw64e.sys (Intel Network Adapter Diagnostic Driver), and ZAM.sys (Zemana AntiMalware driver). Microsoft maintains a Vulnerable Driver Blocklist and incorporates it into Windows Defender Application Control (WDAC), but the list has historically lagged behind new discoveries. The LOLDrivers project (loldrivers.io) catalogs known vulnerable drivers, analogous to how LOLBAS catalogs vulnerable binaries. Ransomware groups have heavily adopted BYOVD to disable endpoint protection before deploying ransomware payloads. BlackByte, AvosLocker, and RobbinHood ransomware have all used BYOVD techniques. Nation-state actors also use it for stealth purposes — loading a vulnerable driver, exploiting it to remove security hooks, and then continuing activity with dramatically reduced visibility to EDR agents.

Practical Usage

For security teams, BYOVD represents one of the most difficult threat classes to detect and prevent because it exploits the fundamental trust model of Windows driver signing. The most effective defense is deploying and maintaining a comprehensive vulnerable driver blocklist through Windows Defender Application Control (WDAC) or equivalent. Microsoft's recommended driver block rules should be deployed, but organizations should supplement them with the LOLDrivers list. This blocklist must be actively maintained as new vulnerable drivers are continuously discovered. Detection opportunities exist at the service installation and driver loading stage. Windows events for new service installation (Event ID 7045) and driver loading should be monitored for unexpected driver files, particularly when the loading process is an unexpected parent (e.g., a ransomware dropper loading a driver). Sysmon Event ID 6 (Driver Loaded) provides driver hash information that can be cross-referenced against the LOLDrivers database. EDR platforms that monitor kernel callback registration and deregistration can detect when a BYOVD attack successfully removes security hooks — though this detection may come after the fact. Organizations that rely heavily on endpoint detection for their security posture must account for the possibility that EDR agents can be disabled by BYOVD attacks. Defense-in-depth is essential: network-based detection that doesn't rely on endpoint agents (NDR, DNS monitoring, firewall logging) should be maintained so that even if an EDR is killed, attack activity generates detectable network signals. Canary files and honeypot accounts that generate alerts when accessed can also provide detection even after endpoint protection is disabled.

Examples

• The BlackByte ransomware group used a vulnerable version of the MSI Afterburner driver (RTCore64.sys) to disable over 1,000 different security tools and process monitoring utilities before deploying ransomware.
• RobbinHood ransomware used a vulnerable GIGABYTE driver (gdrv.sys) to terminate Windows processes including security products that could not be terminated by standard user-mode processes.
• The Scattered Spider threat group used BYOVD techniques with a vulnerable Avast driver to disable EDR agents on victim systems before conducting hands-on-keyboard intrusion activities.

Related Terms