In July 2022, a ransomware actor walked into a corporate network, found a system with endpoint protection properly configured, and disabled it. Not by exploiting a zero-day in the antivirus software. Not by finding a misconfiguration in the firewall. They used a driver signed by miHoYo, the developer of Genshin Impact, one of the world's most popular video games.
The driver was legitimate. Its certificate was valid. A valid signature is the entry requirement for the kernel, though other security policies can still block a driver from loading. This one passed. And it could terminate any process on the machine, including every security tool running on it, because it executed in the kernel.
This is the central paradox of Bring Your Own Vulnerable Driver, or BYOVD: a driver can be legitimately signed, accepted by Windows, and still become a weapon. Understanding why requires understanding what a driver signature actually proves, and what it deliberately does not.
The Kernel Is Not Just Another Layer
When Windows runs, it splits execution into two distinct privilege levels: user mode and kernel mode. User-mode code runs in a sandboxed environment. A browser, a text editor, an antivirus agent: they all operate in user mode, separated from each other and from the OS itself. If a user-mode process crashes, Windows can contain the damage. It cannot reach across and terminate another protected process, modify arbitrary memory, or directly touch hardware.
Kernel mode is different. Code running in kernel mode executes with the full privileges of the operating system. It can read and write any memory address, terminate any process, and access hardware directly. There is no sandbox. A crash in kernel mode is a system crash. A successful attacker in kernel mode has, in practice, won.
Drivers live in kernel mode. A graphics driver, a storage controller driver, a network interface driver: they all run with those elevated privileges because that is what their job requires. Controlling hardware at a low level demands direct access to memory, I/O ports, and system structures that user mode simply cannot touch.
This creates an obvious security concern. If arbitrary code can run in kernel mode, any attacker who gets their code loaded as a driver owns the machine. Microsoft's answer to this was Kernel Mode Code Signing, which became mandatory on 64-bit Windows starting with Vista: to load into the kernel, a driver binary must carry a valid digital signature from a trusted certificate authority.
The assumption embedded in that policy is reasonable. Getting a certificate requires a real identity. Signing a driver is a deliberate act that creates accountability. Unsigned code stays out.
The assumption is also incomplete.
What a Signature Proves, and What It Does Not
A digital signature on a kernel driver answers a specific question: has this binary been modified since it was signed, and does the certificate chain trace back to a trusted authority? It is an integrity and identity check. It says nothing about whether the code's implementation is secure, whether its privileged operations are safe to expose, or whether an attacker could send it the right inputs to make it do something it was never intended to do.
Before a driver can run on modern Windows, it generally must pass through the Windows Hardware Quality Labs process, where it is signed by Microsoft after testing. But WHQL testing focuses on stability and compatibility. It does not perform the kind of adversarial security review needed to guarantee that every function the driver exposes is safe against malicious inputs. A driver can pass certification, ship with legitimate hardware or software, and still contain vulnerabilities that allow attackers to abuse its kernel-level access.
There are also two distinct ways a driver can become a BYOVD target. The first is a genuine vulnerability: a memory corruption bug, a logic error, a path that allows arbitrary code execution or memory manipulation. The second, and arguably more common in recent incidents, is dangerously over-exposed functionality: the driver intentionally provides operations like process termination or arbitrary memory reads, but with insufficient access controls, so any process that can reach its device interface can issue those commands. Both categories end up in the same place: a signed, trusted driver doing things on behalf of an attacker.
The Attack, Step by Step
BYOVD requires an attacker who has already obtained administrative privileges on the target system. That is the prerequisite that matters most. This is not a technique for gaining initial access; it is a technique for expanding what you can do once you are in, particularly for defeating security tools that are deliberately hardened against user-mode tampering.
Once the attacker has admin access, the attack follows a consistent pattern.
The vulnerable driver, a .sys file, is dropped onto disk. It does not need to be installed; it just needs to be present. The attacker then registers it as a kernel service, typically through the Windows Service Control Manager, and starts it. Because the driver carries a valid signature and the signing certificate is trusted, Windows loads it into the kernel without raising an alarm based on signature alone.
At this point, the driver is resident in kernel mode, and the attacker's user-mode code can communicate with it through the driver's device interface using I/O control codes, or IOCTLs. These are essentially function calls into the driver from user mode. A legitimate driver exposes IOCTLs for its intended purpose: a hardware driver might expose IOCTLs for device configuration or status queries. A vulnerable or over-exposed driver may also happen to expose IOCTLs that can terminate processes, read or write kernel memory, or perform other privileged operations.
The attacker sends the right IOCTL to the loaded driver. The driver, executing in kernel mode, carries out the request. If the target is process termination, the driver calls kernel APIs like ZwTerminateProcess in its own privileged context, bypassing the process protection mechanisms that would prevent a user-mode process from doing the same thing directly. Protected processes, including security agents specifically designed to resist user-mode tampering, can be killed this way.
What the attacker gains from this depends entirely on what the driver can do. BYOVD does not automatically grant unlimited kernel-level control. The attack is bounded by the driver's own capabilities and what it exposes. But terminating endpoint detection and response processes is typically sufficient for the next phase of an intrusion, whether that is deploying ransomware, exfiltrating data, or establishing persistence.
Case Study: The Genshin Impact Driver
In August 2022, Trend Micro published a detailed incident report documenting a ransomware campaign that used exactly this technique. The driver was mhyprot2.sys, the anti-cheat component shipped with Genshin Impact and signed by miHoYo.
Anti-cheat systems are a particularly fertile source of BYOVD candidates. To do their job, they need kernel-level access to inspect game memory, detect unauthorized modifications, and terminate processes. The functionality they need is precisely the functionality attackers want.
The mhyprot2.sys driver exposed IOCTLs that allowed a user-mode process to enumerate modules loaded into any given process and to terminate any process by PID using ZwTerminateProcess, the kernel's own process termination interface. The driver performed these operations in kernel mode, on behalf of whoever sent the right command.
Genshin Impact does not need to be installed on a victim's machine for this to work. The driver runs independently of the game. In the Trend Micro incident, the attacker dropped two files onto a compromised user's desktop: mhyprot2.sys and a malicious executable called kill_svc.exe. The executable installed the driver, then issued IOCTLs through its device interface to work through a list of processes to terminate. That list included the antivirus services running on the machine. With endpoint protection down, the attacker deployed ransomware through a shared network folder.
The driver in this attack was the version built in August 2020. At the time of Trend Micro's report, the code signing certificate was still valid. The developer had been informed of the vulnerability before the attack, but the certificate had not been revoked.
That last point is important. The response to a vulnerable driver is not just to patch it. A newer, patched version of the driver does not invalidate the old signed binary. As long as the original certificate remains valid and the old binary is not explicitly blocked, attackers can continue using the older version indefinitely.
Why Signing and Revocation Cannot Solve This Cleanly
The logical response to a vulnerable signed driver is to revoke its certificate. This would prevent Windows from loading the signed binary. In practice, it is often not done promptly, and sometimes not done at all.
Certificate revocation is blunt. Revoking a certificate affects every binary signed with it, including legitimate software currently in use. A hardware vendor with thousands of deployed devices, all using drivers signed with the same certificate, faces a significant compatibility problem if revocation breaks those drivers for their customers. The commercial and support costs are real, which creates reluctance to act quickly.
Microsoft's answer to the revocation problem is the vulnerable driver blocklist: a list of specific driver binaries, identified by hash, file name, version number, and signing certificate, that Windows should refuse to load. The blocklist allows a much more surgical response than certificate revocation. Since Windows 11 22H2, the blocklist is enabled by default on all devices and can be toggled via Windows Security. It is also enforced independently when HVCI (Hypervisor-Protected Code Integrity), Smart App Control, or S mode is active on a device. Prior to 22H2, the blocklist was only active on systems running HVCI or S mode. On Windows 10 systems and older Windows 11 configurations without these features enabled, the blocklist is not guaranteed to be in effect.
The blocklist has a structural limitation that BYOVD exploits by design: it is reactive. A driver cannot be added to the blocklist until a vulnerability is known, reported, confirmed, and processed. During that window, the vulnerable driver remains usable. In late 2022, security researcher Will Dormann documented that the blocklist had not received significant updates in nearly three years on some configurations, leaving many known-vulnerable drivers usable well after their vulnerabilities had become public. Microsoft has since committed to updating the blocklist with each major Windows release and through servicing updates, but the fundamental reactive nature of the mechanism remains.
This is also why attackers choose BYOVD over writing a kernel exploit from scratch. A novel kernel vulnerability is expensive to develop, risky to use (it may destabilize the system), and will be patched when it becomes known. A collection of signed, legitimate drivers with documented kernel capabilities and no current blocklist entry is a catalog of ready-made tools that an attacker can bring to any adequately privileged intrusion.
Defenses That Actually Help
Keeping HVCI enabled is the most structurally important control. HVCI uses the CPU's virtualization capabilities to isolate code-integrity enforcement into a protected environment, separate from the kernel itself. Even if the kernel is compromised, the hypervisor layer that HVCI relies on can continue to enforce that only verified, known-good code runs in kernel mode. A kernel driver cannot tamper with that enforcement because it operates at a privilege level below where HVCI's protections live.
HVCI and the vulnerable driver blocklist are distinct controls that work well together. The blocklist specifies which drivers should be refused; HVCI makes it harder for a compromised kernel component to circumvent whatever policy is in place. Without HVCI, a sophisticated attacker who has already loaded a driver may be able to interfere with kernel-level enforcement mechanisms. With HVCI active, the integrity verification itself is harder to undermine.
For enterprises, Windows Defender Application Control allows organizations to deploy custom driver allowlists and blocklists. The ASR rule "Block abuse of exploited vulnerable signed drivers" can add a layer of detection, though Microsoft's documentation notes it does not prevent a driver already on the system from loading.
Detection is harder than prevention but still meaningful. Legitimate drivers are generally not dropped into temporary user directories and registered as services from user desktop folders. A driver installed via the Service Control Manager from an unusual path warrants investigation. Monitoring for unusual IOCTL patterns, unexpected process terminations of security agents, and driver loads from non-standard locations gives defenders something to work with even when prevention has failed.
Endpoint protection products with kernel-level self-protection (tamper protection), when properly configured, can raise the bar for what a BYOVD attack needs to accomplish. Some products monitor for attempts to kill their own processes through kernel-level calls and can alert or resist those attempts. This does not make them immune, but it creates observable signal.
The least complicated defense is also the most consistently undervalued: limiting administrative privileges. A BYOVD attack begins after the attacker has administrative access. Restricting who has local administrator rights, enforcing just-in-time access for privileged operations, and monitoring for unexpected privilege escalation reduces the pool of machines on which BYOVD becomes an option.
Trusting Origin vs. Trusting Behavior
The core problem with driver signing as a security boundary is that it conflates two different properties: where the software came from and what the software does. A signature is evidence of origin and integrity. It cannot be evidence of safe behavior, because safe behavior depends on implementation details that signing does not and cannot inspect.
BYOVD is the gap between those two properties made into an attack technique. A driver signed by a legitimate manufacturer, shipped with a popular video game, passing every certificate check Windows performs, can still call kernel APIs that terminate protected processes and disable the security tools meant to detect an intrusion.
The defensive implication is that a policy of "only allow signed kernel code" is necessary but not sufficient. The question has to extend further: which signed code, and does it remain safe given what we know about its implementation today? That is a harder question to answer, and the blocklist, revocation infrastructure, and HVCI together represent the current best approximation of an answer.
The driver was trusted. The certificate was valid. The security tools were running. And the ransomware still deployed.
Primary Sources
- Trend Micro Research: Ransomware Actor Abuses Genshin Impact Anti-Cheat Driver to Kill Antivirus (August 2022)
- Microsoft Learn: Microsoft recommended driver block rules
- Microsoft Learn: Windows driver signing tutorial
- Microsoft Support: Vulnerable driver blocklist KB5020779
- CrowdStrike: Falcon Prevents Multiple Vulnerable Driver Attacks in Real-World Intrusion (December 2024)
- MITRE ATT&CK: T1068 - Exploitation for Privilege Escalation / Bring Your Own Vulnerable Driver
- Expel: The Feature That Stops BYOVD
Top comments (0)