What is Bring Your Own Vulnerable Driver (BYOVD) – Bitdefender TechZone

The use of BYOVD is typically the final stage in a multi-step chain of escalation. Attackers often begin their journey with a standard user account, gained through methods like phishing or credential theft. Because a standard user is heavily restricted by the operating system, the first objective is to escalate to a local administrator account. This transition allows the attacker to modify system settings and manage services, but it still limits them to User-Mode.

To tamper with endpoint security solutions, the attacker must bridge the gap between User-Mode and Kernel-Mode. Drivers serve as the primary bridge for this escalation, as they are the only components authorized to execute code within the kernel. Windows strictly limits the ability to load or unload device drivers to the SeLoadDriverPrivilege, which is reserved for Administrators and the System account. However, even as administrators, attackers cannot simply load their own custom malicious drivers because they lack a valid digital signature from a trusted authority.

To overcome this hurdle, attackers look for pre-existing, trusted drivers that are either vulnerable to exploitation or provide unsafe functionality by design. By "bringing" these legitimate drivers to the system and loading them using their administrator rights, they create a bridge to the kernel-mode. Once they are in the kernel, attackers have numerous options to directly attack the security agent and its monitoring capabilities.

The goal of a BYOVD attack is to gain kernel-mode privileges, often called Ring 0. At this level, code has unrestricted access to system memory and hardware. Since an attacker cannot load an unsigned malicious driver, they "bring" a driver signed by a reputable vendor (such as a hardware manufacturer or an old antivirus version) that has a known vulnerability.

The Driver Lifecycle

The effectiveness of this technique relies on the attacker's ability to source the correct files. Not every driver is a candidate for BYOVD. For a driver to be useful, it must allow a user-mode application to trigger a kernel-mode action exceeding its intended scope.

Threat actors find these drivers through proactive methods. They monitor public security research and databases like "LOLDrivers," which catalog signed drivers known to be abusable. They also perform "driver hunting" by scanning large volumes of legitimate software installers from hardware vendors for common IOCTL vulnerabilities. Once a driver is identified, it is added to a repository of pre-signed exploits.

Attackers often prefer legacy drivers from the 2013 to 2016 era because they lack modern security features like Control Flow Guard (CFG), making them easier to exploit. Simultaneously, they scan brand new software releases, as newly discovered drivers are highly valuable because they are not yet included in any blocklists, providing a window of opportunity before security vendors can react.

Beyond abusing legitimate drivers, Bitdefender Labs has investigated cases involving purposefully designed malicious drivers. In these scenarios, threat actors develop custom malware from the ground up to operate specifically within the kernel. To bypass certification requirements, they use stolen digital certificates obtained from legitimate vendors who have suffered data breaches. In these instances, the primary remediation is for the certificate authority to revoke the stolen certificate entirely, rather than adding individual driver hashes to a blocklist.

Since you’ve learned the mechanics of how a driver is targeted (bugs vs. design), we can now analyze what the consequences are. BYOVD is a generic term that covers a variety of scenarios. The potential for damage depends entirely on the specific capabilities of the driver being abused. These capabilities generally fall into two categories.

The effectiveness of a BYOVD attack often depends on the type of security product installed. There is a significant difference in how consumer antivirus and enterprise EDR solutions handle anti-tampering. Consumer products often prioritize software compatibility to ensure that games, anti-cheat drivers, and performance overlays work without interruption. Modern gaming titles frequently include kernel-level anti-cheat systems, such as Riot Vanguard or BattlEye, which operate at the same privilege level as the security agent.

A compatibility problem arises because both the anti-cheat system and the security agent want to monitor the same sensitive kernel functions. When two different drivers attempt to "hook" or redirect the same system call at the same time, it can lead to immediate system instability or a Blue Screen of Death (BSOD). Aggressive anti-tampering features might also view the anti-cheat system's attempts to protect game memory as a malicious attack. To avoid the frequent system crashes or software blocks that would alienate home users, these products are often designed with a more permissive stance toward low-level kernel interactions.

This distinction is important because many public "EDR bypass" demonstrations utilize consumer products to showcase successful attacks. While these demonstrations are effective for educational purposes, they often fail to represent the reality of a modern enterprise environment. Consumer products lack the hardened self-protection mechanisms found in business-grade solutions, making them easier targets for termination or blinding.

Business-grade solutions, such as Bitdefender GravityZone, include specialized features, such as kernel-level hooks and callback monitoring, that are far more difficult for an attacker to bypass. In a business environment, if a security agent blocks a legitimate but vulnerable driver, an administrator can investigate and create an exclusion. In the consumer world, the user would often simply blame security software and uninstall it.

To understand why defending against BYOVD is difficult, it is necessary to look at the mechanisms intended to manage digital trust. A Certificate Revocation List (CRL) is a publicly accessible database maintained by a Certificate Authority (CA). It contains a list of digital certificates that have been cancelled before their scheduled expiration date. CRLs are not specific to drivers. They are used to manage trust for websites, encrypted communications, and software across the entire internet. When a system attempts to load a signed driver, it is supposed to check the CRL to ensure the certificate used to sign that driver is still considered valid. If the certificate appears on the list, the system should refuse to load the file.

The use of CRLs appeared to be a strong theoretical solution when the digital signing model was first established. The intent was to provide a mechanism where a compromised or vulnerable certificate could have its trust pulled by the issuing authority. However, as digital certificates became more common, CRLs began to act as a significant performance and practical bottleneck. CRL files are often non-atomic and grew to sizes that caused latency during every signature check on the system. Because a single CRL can contain thousands of entries, parsing the list in real-time is computationally expensive. Furthermore, Windows is unable to check CRLs during the boot process because network connectivity is not yet established. These issues led many administrators to disable CRL checks entirely to prevent system instability.

While CRLs remain part of the Windows security architecture, they are now treated as a worst-case scenario option rather than a primary defense. Microsoft has shifted toward the Vulnerable Driver Blocklist as a more practical and targeted strategy. This approach allows the operating system to block specific file hashes of known-bad drivers without the broad, destructive impact of revoking an entire vendor certificate. Since the Windows 11 2022 update, this blocklist has been enabled by default. It provides a more agile response to the BYOVD threat because new hashes can be distributed through standard Windows updates without requiring the coordination needed for a full certificate revocation.