A growing number of sophisticated threat 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. As researchers at Picus Security explain, 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.”
Unlike noisy exploits or custom rootkits, BYOVD weaponizes trust. Instead of bypassing Windows security controls outright, attackers abuse drivers that the operating system already allows to run.
How BYOVD Attacks Work
BYOVD is not an initial access vector. Attackers must first obtain local administrative privileges through 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 goal is straightforward: disable endpoint detection and response (EDR), antivirus, and other security controls at the kernel level—ensuring nothing interferes with ransomware encryption, credential dumping, or lateral movement.
Because the drivers involved are legitimate and digitally signed, they typically pass Windows trust checks. This allows attackers to deploy trusted components instead of obviously malicious kernel code.
The BYOVD Execution Process
1. Dropping a Vulnerable Driver
Attackers first place a vulnerable .sys driver file on disk. Common locations include:
C:\Windows\TempC:\Users\Public
The driver is often extracted from legitimate vendor software—hardware utilities, system monitoring tools, RGB controllers, overclocking tools, or gaming anti-cheat packages—making it appear benign during superficial inspection.
2. Registering and Loading the Driver
The attacker registers and loads the driver into the Windows kernel using:
sc.exe createsc.exe start- Or programmatically via the
NtLoadDriverAPI
Because the driver carries a valid digital signature, Windows permits it to load into kernel space without raising immediate alarms.
At this point, the attacker has successfully placed controlled code at Ring 0.
3. Exploiting Unsafe IOCTL Handlers
The real abuse begins after the driver is active.
Many vulnerable drivers expose unsafe Input/Output Control (IOCTL) codes that allow arbitrary memory read/write operations. By sending crafted DeviceIoControl requests, attackers exploit these flaws to gain direct access to kernel memory.
This provides the ability to:
- Read protected kernel memory
- Write to arbitrary kernel addresses
- Modify security-critical structures
Effectively, the attacker now operates at the highest privilege level in Windows.
4. Dismantling Endpoint Protections
With arbitrary kernel read/write capabilities, adversaries can systematically dismantle defenses:
- Remove EDR callback registrations from kernel structures
- Patch tamper-protection routines in memory
- Terminate antivirus processes using kernel-level APIs
- Modify
EPROCESSstructures to hide malicious processes - Strip kernel notification routines
At this stage, the endpoint is functionally defenseless—even though security software may still appear installed and running.
Case Study: Genshin Impact Driver Abuse
One attack analyzed by Picus Security 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. Once endpoint protections were neutralized, ransomware deployment proceeded without interference.
This was not a zero-day exploit. It was abuse of a trusted component.
Why Windows Driver Trust Creates 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 introduce exceptions:
- Legacy cross-signed drivers may load under certain conditions
- Systems upgraded from older versions may allow older drivers
- Secure Boot may be disabled in some environments
- Blocklists are reactive, not proactive
Microsoft maintains a vulnerable driver blocklist, but drivers are typically added after vulnerabilities are identified and disclosed, often after exploitation has already occurred.
Because blocklist updates frequently coincide with major Windows releases, newly discovered vulnerable drivers can remain usable for extended periods.
BYOVD does not break Windows security—it exploits drivers that Windows still trusts.
Defensive Strategies Against BYOVD
Defending against BYOVD requires layered controls. There is no single configuration that eliminates the risk.
1. Enable VBS and HVCI
Activate the full virtualization-based security (VBS) stack, including:
- Hypervisor-Protected Code Integrity (HVCI)
- Credential Guard
These mechanisms isolate and protect kernel memory from tampering.
2. Enforce WDAC and Driver Blocklists
Implement:
- Windows Defender Application Control (WDAC) policies
- Microsoft’s vulnerable driver blocklist
Restrict which drivers are allowed to load—explicitly deny unnecessary third-party kernel modules.
3. Eliminate Excessive Administrative Privileges
BYOVD requires local administrator rights. Reduce exposure by:
- Enforcing least privilege
- Removing standing local admin accounts
- Requiring multi-factor authentication for privileged access
No admin rights, no driver loading.
4. Monitor Driver and Service Creation Events
Watch for suspicious driver loads and kernel service creation:
- Sysmon Event ID 6 (Driver Loaded)
- Windows Event ID 7045 (Service Installed)
Unusual driver activity outside standard change windows should trigger investigation.
5. Keep Secure Boot Enabled
Secure Boot reduces legacy cross-signed driver abuse and ensures stronger driver validation enforcement.
6. Reduce Kernel Attack Surface
Regularly:
- Audit installed drivers
- Remove outdated third-party utilities
- Eliminate unnecessary hardware management tools
Every unused driver is potential kernel-level attack surface.
7. Continuously Test Controls
Conduct breach and attack simulations to validate:
- Detection of malicious driver loads
- EDR resilience against kernel tampering
- Incident response containment effectiveness
Controls that aren’t tested can’t be trusted.
Legacy Drivers: The Quiet Attack Surface
BYOVD reflects a practical shift in attacker tactics. Instead of relying exclusively on zero-days, threat actors increasingly leverage:
- Legitimate signed drivers
- Trusted vendor software
- Backward compatibility exceptions
- Reactive blocklists
As long as legacy drivers, broad administrative access, and implicit trust in signed components exist, BYOVD will remain viable. This trend is pushing organizations toward zero trust architectures—where driver trust is not assumed simply because code is signed.
Kernel-level trust must be evaluated as part of the overall attack surface, not treated as inherently safe. Because in modern Windows environments, the most dangerous code may not be malicious at all—it may simply be trusted.
