When the Anti-Cheat Driver Becomes the Weapon: The mhyprot2.sys Supply Chain

Kernel anti-cheat systems are often discussed as a tradeoff between cheating prevention and user privacy, but there is a third party in this arrangement that gets less attention: the malware author who did not write the driver, did not install the game, and still benefits from both.

This technical deep-dive into kernel anti-cheat mechanics covers the architecture clearly. The part worth extending is what happens after a vulnerable anti-cheat driver ships to millions of machines, because the answer is not that the cheating problem gets worse. The answer is that unrelated ransomware groups add it to their toolkits.

What Signing Actually Guarantees

Windows requires kernel drivers to be digitally signed before the OS will load them. On 64-bit Windows Vista and later, Driver Signature Enforcement (DSE) is the gate: unsigned drivers are rejected. Anti-cheat vendors get their drivers through Microsoft’s WHQL program or via cross-signing certificates from approved certificate authorities, and the resulting .sys files carry a cryptographic signature that Windows verifies at load time.

What signing does not do is audit driver logic. The signature proves that the binary was produced by the registered entity and has not been modified since signing. It says nothing about what happens when a caller sends an I/O Control Code (IOCTL) to the driver’s dispatch routine. A driver can be correctly signed, WHQL-certified, and in production on fifty million machines while simultaneously exposing a kernel memory read/write primitive to any unprivileged caller on the system.

This is not a theoretical edge case. It is the standard condition under which BYOVD (Bring Your Own Vulnerable Driver) attacks operate.

The mhyprot2.sys Incident

MiHoYo’s anti-cheat driver for Genshin Impact, mhyprot2.sys, shipped with a set of exposed IOCTL handlers that allowed any process, regardless of privilege level, to issue requests to the driver and receive arbitrary kernel memory reads and writes in response. The specific handlers accepted physical and virtual memory addresses from user space and performed the requested operations in ring-0 context, with no access control check on the caller.

In August 2022, Trend Micro documented how the BlackByte ransomware group had integrated mhyprot2.sys into their attack chain. The kill chain had a clean structure: extract the driver binary from the Genshin Impact installer or from a bundled copy, install it as a Windows service via the Service Control Manager, use the arbitrary kernel write primitive to patch the callback arrays that EDR and antivirus software registered with the kernel, and then deploy the ransomware payload once the endpoint protection was disabled.

The machine that received this treatment did not need to have Genshin Impact installed. The attackers bundled the driver directly. A valid Microsoft-accepted signature was already on the binary, so DSE let it load without complaint.

Why Disabling Callbacks Works

To understand what BlackByte was patching, it helps to know how EDR software hooks into the Windows kernel. The OS exposes a set of documented callback registration APIs:

// Fires on every process creation and exit
PsSetCreateProcessNotifyRoutineEx(EDRProcessCallback, FALSE);

// Fires when any image is mapped into any process
PsSetLoadImageNotifyRoutine(EDRImageCallback);

// Intercepts handle creation operations
ObRegisterCallbacks(&callbackRegistration, &registrationHandle);

When an EDR product registers a callback, the kernel stores a pointer to the callback function in an internal array, such as PspCreateProcessNotifyRoutine. Subsequent events invoke these routines before returning control to user space, giving the security software visibility into process creation, DLL injection, and handle acquisition.

A kernel write primitive allows an attacker to zero out these function pointers. The callback array remains structurally intact; it just no longer points to anything meaningful. The kernel iterates the array, calls null pointers or skips them, and the EDR receives no notifications. From the security software’s perspective, the system goes quiet in a way that looks like no suspicious activity is occurring, because the mechanism that would report suspicious activity has been neutralized.

This is the pattern mhyprot2.sys enabled, and it required no vulnerability in the EDR software itself. The endpoint protection product was functioning correctly, registered its callbacks properly, and was then silently removed from the notification path by an attacker writing kernel memory through a gaming anti-cheat driver.

A Structural Property, Not An Accident

The reason this pattern appears across multiple anti-cheat drivers is not carelessness from individual vendors. It is a consequence of what these drivers need to do.

An anti-cheat driver that protects a game’s memory from being read by external processes must be able to read that memory itself, from ring-0, to verify its integrity. A driver that scans for unauthorized kernel modules must be able to walk kernel structures and examine loaded code. A driver that detects memory patches must compare live memory contents against expected values. Every capability that makes an anti-cheat driver useful for detection is also a capability that an attacker wants.

Capcom’s capcom.sys, shipped as part of a PC port’s DRM in 2016, exposed a code execution primitive so straightforwardly that security researchers documented it as a rootkit installation helper. GIGABYTE’s gdrv.sys exposed physical memory read/write to local callers, allowing memory access that bypassed virtual address protections entirely. Both were legitimately signed, both shipped in quantity, and both became tools in the BYOVD catalog.

The deeper issue is distribution scale. An anti-cheat driver that ships with a game reaching ten million players creates ten million machines with that driver’s attack surface. A vulnerability that would be a limited incident in enterprise software becomes infrastructure for anyone who needs kernel access and does not want to develop their own driver.

The Blocklist Lag

Microsoft maintains a Vulnerable Driver Blocklist that prevents known-vulnerable drivers from loading even when they carry a valid signature. Windows 11 ships with this blocklist enabled by default via WDAC (Windows Defender Application Control). The blocklist applies to specific file hashes, so a vendor can issue a patched driver and the original vulnerable binary gets blocked without affecting the updated version.

The mechanism works, but it operates on a disclosure-to-enforcement timeline that the threat landscape exploits. After MiHoYo became aware of the vulnerability in mhyprot2.sys and revoked the certificate, the original binary continued to function on systems that had not received a blocklist update. Microsoft adds drivers to the list after they are reported and confirmed, not proactively. For drivers distributed at gaming scale, the period between initial exploitation and effective blocklist coverage is long enough for a ransomware campaign to complete multiple engagements.

What HVCI Changes, and What It Does Not

Hypervisor-Protected Code Integrity (HVCI), part of Windows Virtualization Based Security, addresses part of the BYOVD exploitation chain at a structural level. Under HVCI, a hypervisor running below the Windows kernel enforces that kernel memory cannot be simultaneously writable and executable. Code integrity policy is enforced from the hypervisor context, which the kernel itself cannot tamper with.

The practical effect on shellcode-based kernel exploits is significant. The standard payload after gaining a kernel write primitive is to allocate kernel memory, copy shellcode into it, and execute it. Under HVCI, allocating executable kernel memory requires going through the hypervisor’s code integrity check, which rejects unsigned content. The shellcode injection step fails before it can run.

What HVCI does not prevent is exploitation of the driver’s own IOCTL interface. A driver that exposes a kernel memory write through a documented IOCTL handler is still vulnerable to callers that use that handler for its intended purpose: writing kernel memory. The driver’s code is signed and approved; the hypervisor has no policy violation to detect. An attacker who uses mhyprot2.sys to zero out callback arrays is using the driver as designed, not injecting new code. HVCI stops shellcode execution but does not change the analysis for IOCTL-based exploitation.

Riot’s Vanguard now requires HVCI on supported hardware, which meaningfully raises the cost of certain attack chains. It does not close the gap that BYOVD exploitation through exposed IOCTL primitives represents.

The Broader Implication

The Windows kernel driver ecosystem has always had security properties that depend on the competence and security practices of whoever wrote the driver. Historically, this population was hardware manufacturers and enterprise software vendors, who had some accountability for the code they shipped into the kernel.

Kernel anti-cheat has expanded that population to include game studios, with a distribution model that pushes kernel code to consumer machines at a scale that dwarfs enterprise software deployments. The security review practices, vulnerability disclosure policies, and patch cadence of game companies now have direct bearing on the security posture of those machines, regardless of whether the owner plays the associated game or has any awareness that kernel code from that studio is installed.

The mhyprot2.sys incident is not an argument that kernel anti-cheat is wrong or that MiHoYo was uniquely negligent. It is an illustration of what happens when kernel code ships at consumer gaming scale: the installed base becomes infrastructure, and infrastructure attracts use cases its designers did not intend.