BYOVD Turns Trusted Drivers Against Windows Security

A growing number of great actor groups are quietly abusing legitimate Windows drivers to turn endpoint defenses against themselves. 

Known as Bring Your Own Vulnerable Driver (BYOVD), the technique allows attackers to load a digitally signed but flawed driver and exploit it to gain full kernel-level access. 

Attackers “… load a legitimate, digitally signed, but vulnerable driver onto a target system. They then exploit flaws in that driver to gain arbitrary kernel-mode (Ring 0) execution, the highest privilege level in Windows,” said Picus Security researchers.

How BYOVD Attacks Work

Attackers deploy BYOVD after gaining a foothold to disable EDR and other security controls, ensuring nothing interferes with encryption, credential theft, or lateral movement.

Because the drivers involved are legitimate and digitally signed, they typically pass Windows’ built-in trust checks, allowing attackers to weaponize trusted components rather than deploy obviously malicious kernel code.

BYOVD is not an initial access vector. Attackers must first obtain local administrative privileges through methods such as phishing, credential theft, exploitation of exposed services, or purchasing access from an initial access broker. 

Once administrative rights are secured, the BYOVD sequence begins.

The BYOVD Execution Process

The first step usually involves dropping a vulnerable .sys driver file onto disk. Adversaries often place the file in writable directories such as C:\Windows\Temp or C:\Users\Public to avoid permission barriers. 

These drivers are often extracted directly from legitimate vendor installers — hardware utilities, monitoring tools, or gaming software — making them appear benign during superficial inspection.

Next, the attacker registers and loads the driver into the Windows kernel. This is typically done using the Windows Service Control Manager with commands such as sc.exe create and sc.exe start, or programmatically through the NtLoadDriver API. 

Because the driver carries a valid digital signature, Windows permits it to load into kernel space without raising immediate alarms.

The real abuse begins after the driver is active. Many vulnerable drivers expose unsafe Input/Output Control (IOCTL) codes that allow arbitrary memory read and write operations. 

By sending crafted DeviceIoControl requests, attackers exploit these flaws to gain direct access to kernel memory. This effectively gives them the ability to read from and write to protected areas of the operating system.

With arbitrary kernel read/write capabilities, adversaries can systematically dismantle endpoint protections. 

They may remove EDR callback registrations from kernel structures, patch tamper-protection routines in memory, terminate antivirus processes using kernel-level APIs, and manipulate process objects — such as modifying EPROCESS structures — to hide malicious activity. 

At this stage, the endpoint is effectively defenseless, even though security software may still appear to be installed.

Genshin Impact Driver Abuse

One attack analyzed by Picus researchers involved ransomware actors abusing the mhyprot2.sys anti-cheat driver from the video game Genshin Impact. 

After installing the legitimately signed driver, a companion executable sent a specific control code instructing the driver to terminate designated antivirus processes. 

Because the driver operated at Ring 0, it successfully invoked ZwTerminateProcess to kill security services, clearing the way for ransomware deployment. The encryption phase then proceeded without interference.

Windows Driver Trust Gaps

The effectiveness of BYOVD stems from structural characteristics of Windows’ driver trust model. 

Since Windows 10, most new kernel-mode drivers must be signed through Microsoft’s Dev Portal. 

However, backward-compatibility requirements allow certain legacy cross-signed drivers to load under specific conditions, such as when Secure Boot is disabled or when systems were upgraded rather than clean-installed. 

These compatibility exceptions create exploitable trust gaps that attackers can leverage without forging or stealing new signatures.

Microsoft’s vulnerable driver blocklist is inherently reactive. Drivers are added only after vulnerabilities are identified and disclosed, often after they have been exploited. 

Because updates typically coincide with major Windows releases, newly discovered or lesser-known vulnerable drivers may remain usable for extended periods. 

As a result, BYOVD does not bypass Windows security mechanisms outright — it takes advantage of trusted drivers that are still permitted to load.

BYOVD Defense Strategies

Defending against BYOVD requires more than a single configuration change or security control. 

Because the technique operates at the kernel level and abuses legitimate driver trust, organizations must apply layered controls.

• Enable hypervisor-protected code integrity (HVCI) and the full virtualization-based security (VBS) stack, including credential guard, to protect kernel memory from tampering.
• Enforce Windows Defender Application Control (WDAC) policies and Microsoft’s vulnerable driver blocklist to restrict which drivers are allowed to load.
• Harden privileged access by eliminating unnecessary local administrator rights, enforcing least privilege, and requiring multi-factor authentication for administrative accounts.
• Monitor and alert on suspicious driver loads and kernel service creation events, including Sysmon Event ID 6 and Windows Event ID 7045.
• Keep Secure Boot enabled and restrict driver installation through group policy to prevent legacy or unauthorized cross-signed drivers from loading.
• Regularly audit and remove unnecessary or outdated third-party drivers to reduce the kernel attack surface.
• Continuously validate security controls and test incident response plans through breach and attack simulation to ensure defenses detect and contain BYOVD techniques effectively.

Together, these measures help limit blast radius, and build long-term resilience.

Legacy Drivers as an Attack Surface

BYOVD reflects a practical shift in attacker tactics: instead of relying solely on zero-day exploits, threat actors often leverage legitimate, trusted components already present in the environment. 

As long as legacy drivers, broad administrative access, and reactive blocklists exist, this technique will remain feasible. 

For security teams, driver trust should be evaluated as part of the overall attack surface rather than assumed to be inherently safe.  

Exploitation of legacy drivers is driving organizations to adopt zero trust solutions that minimize implicit trust and enforce continuous verification.