signed-driver-abuse chain Explained: How Attackers Weaponize Legitimate Signed Drivers

The shortest possible definition

signed-driver-abuse chain stands for signed-driver-abuse chain. An attacker drops a legitimately signed kernel driver onto a target machine, loads it through the Service Control Manager, then sends it an IOCTL that triggers a bug the vendor never patched. The bug hands them an arbitrary kernel read, an arbitrary kernel write, or a raw physical memory alias. From there, ring 0 is theirs. No exploit chain, no zero-day, no signing cert of their own. The driver is already trusted by the kernel because Microsoft, or somebody Microsoft cross-signed, said it was fine.

That is the entire game. Everything else is variations on which driver, which primitive, and how loudly the loader announces itself.

Why the technique exists at all

Windows requires kernel drivers to be signed. Since Vista x64, the loader will refuse an unsigned image at boot time, and Patchguard makes runtime patching of key structures a fatal proposition. On paper, that closes the door on arbitrary ring-0 code.

The door reopens because the signing check verifies the driver was signed. It does not verify the driver is correct. A driver written by a motherboard vendor to expose SMBus reads and PCI config writes to a userspace tool is still a signed driver even when its IOCTL handler blindly trusts a userspace pointer as a physical address to write to. Windows loads it, the driver registers \Device\SomeVendorTool, an unprivileged process opens the handle, and now anyone can perform kernel writes through a DeviceIoControl call. The signature stays valid.

For roughly fifteen years, that gap defined offensive kernel tradecraft. The pattern even earned its own name in industry writeups and [Wikipedia entry](https://en.wikipedia.org/wiki/signed-driver-abuse chain).

A short history of the ecosystem

Every era had its emblematic driver.

• mimidrv.sys (2013). Benjamin Delpy shipped a signed driver alongside mimikatz to detach protected processes and manipulate token privileges. It was the first widely deployed proof that a small, purposeful signed driver could hand a userland tool the kernel.
• capcom.sys (2016). Capcom shipped a driver with Street Fighter V that exposed an IOCTL letting userspace pass a function pointer for the driver to call at IRQL PASSIVE_LEVEL with SMEP disabled. It was, functionally, "please execute this shellcode in ring 0." Every red team and every game cheat loader adopted it within weeks.
• iqvw64e.sys (Intel Ethernet, CVE-2015-2291). Arbitrary ring-0 write through a poorly validated IOCTL. Weaponized for the better part of a decade. RobbinHood ransomware used it in 2019 to disable endpoint security. It is the driver that made "signed-driver-abuse chain" a household term inside the SOC community.
• NVIDIA nvoclk64.sys, ASUS AsIO2/AsIO3, MSI Afterburner, Gigabyte GDrv, ASRock AsrDrv. Vendor tools written to poke hardware directly from userspace. Almost universally, the "poke hardware" part translated to MmMapIoSpace plus a user-controllable physical address, which is precisely the primitive an attacker needs.
• RTCore64.sys (Micro-Star / MSI RivaTuner). Used by the UNC2452 crew and, later, by the BlackByte ransomware operators to blind EDRs by nulling their kernel callback registrations.

The pattern held for years because there was no cost to being on the list. A vendor who shipped a broken driver in 2014 was, in most cases, still shipping the same broken driver in 2022, and it was still cross-signed and still loadable.

What the categories look like

If you spent an afternoon fuzzing the IOCTL surface of every driver in the loldrivers.io index, you would find the offenders cluster into a handful of buckets.

1. Motherboard vendor RGB and monitoring tools. ASUS Armoury Crate, MSI Dragon Center, ASRock A-Tuning, Gigabyte AORUS Engine. The userland GUI needs to read voltages and set fan curves, and the vendor's cheapest path to that is a driver that exposes raw MmMapIoSpace and MSR reads to anybody with a handle.
2. Old firmware and BIOS flashing utilities. Winflash, AFUWIN, Intel SetupUtility. These need physical memory access by design. They were written before HVCI existed and never revisited.
3. Gaming peripherals and overclocking software. RivaTuner, EVGA Precision, Corsair iCUE's early driver revisions. Same story: hardware access exposed to userspace with a token check that amounts to "did you open the handle."
4. HWID and system information tools. CPU-Z, AIDA64, HWiNFO, OpenHardwareMonitor's kernel component. Read primitives, sometimes with sloppy bounds checking on the buffer sizes.
5. Anti-cheat and DRM drivers themselves. Some Denuvo revisions have appeared on the exploited list, and older revisions of certain vendor drivers have been abused by cheat authors to bootstrap into the very anti-cheat process they were meant to protect.

Anything that touches hardware directly and predates 2020 should be assumed vulnerable until proven otherwise.

What a signed-driver-abuse chain attack actually looks like

The mechanics are surprisingly boring. The attacker registers the driver as a kernel service, starts it, opens the control device, and fires an IOCTL. The interesting part is the shape of the IOCTL payload, because it tells you what primitive the driver hands back.

A generic control code carrying a physical-memory read request looks approximately like this. Structure names below are illustrative of the shape you see in a broad class of vendor drivers; no specific still-signed driver is named.

// Illustrative shape only. Field names and IOCTL code
// pulled from the general pattern of vendor RGB drivers.
typedef struct _PHYS_MEM_REQUEST {
    ULONG64 PhysicalAddress;   // user-supplied, unchecked
    ULONG   Length;            // user-supplied, unchecked
    ULONG   Reserved;
    UCHAR   Buffer[1];         // in/out
} PHYS_MEM_REQUEST, *PPHYS_MEM_REQUEST;

#define IOCTL_VENDOR_READ_PHYS \
    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, \
             FILE_READ_ACCESS | FILE_WRITE_ACCESS)

BOOL ReadPhys(HANDLE hDrv, ULONG64 pa, PVOID out, ULONG len)
{
    SIZE_T total = FIELD_OFFSET(PHYS_MEM_REQUEST, Buffer) + len;
    PPHYS_MEM_REQUEST req = LocalAlloc(LPTR, total);
    req->PhysicalAddress = pa;
    req->Length = len;

    DWORD returned = 0;
    BOOL ok = DeviceIoControl(hDrv, IOCTL_VENDOR_READ_PHYS,
                              req, (DWORD)total,
                              req, (DWORD)total,
                              &returned, NULL);
    if (ok) memcpy(out, req->Buffer, len);
    LocalFree(req);
    return ok;
}

The driver's handler for IOCTL_VENDOR_READ_PHYS calls MmMapIoSpace on req->PhysicalAddress, memcpys req->Length bytes into req->Buffer, unmaps, completes the IRP. There is no check that the requested physical range belongs to the caller. There is no check that the range even belongs to userspace. Any physical address on the machine is fair game, including the physical backing of ntoskrnl's .data section, PsInitialSystemProcess, or the token of a SYSTEM process.

To turn that into a full LPE, the attacker walks page tables in software. Read CR3 (there are legal ways to obtain the kernel CR3 value on stock Windows, all of which involve a separate leak primitive), walk PML4 to PDPT to PD to PT for the target virtual address, and translate. Physical read gives you the token pointer of any process. Physical write, if the driver exposes one, lets you swap that token for PsInitialSystemProcess->Token, and you have SYSTEM. This is the classic token-stealing shellcode, done from userland through an unaware chauffeur.

Loading the driver in the first place is the loud part, and the part most modern EDRs actually catch:

# Requires local admin. This is the noisy step every EDR watches.
sc.exe create VulnDrv type= kernel start= demand `
       binPath= "$PWD\vuln.sys" DisplayName= "VulnDrv"
sc.exe start VulnDrv
# Alternatively, direct NtLoadDriver against a registry key under
# HKLM\SYSTEM\CurrentControlSet\Services\VulnDrv

That sc create plus sc start is telemetry gold. Sysmon Event ID 6 fires. Any EDR worth its license flags a service creation whose image is a signed but unusual driver dropped seconds ago into %TEMP%. The signed-driver-abuse chain chain does not fail at the exploit. It fails at the deployment step, when defenders see a driver load event they cannot account for.

Microsoft's response, in three phases

Microsoft took a long time to treat signed-driver-abuse chain as an ecosystem problem instead of a per-vendor problem. Once they did, the response arrived in three overlapping layers.

Phase one: the signed third-party driver Blocklist

Microsoft maintains a driver.stl blocklist that names, by hash, drivers known to expose privilege escalation primitives. It has existed since 2020 but was originally opt-in. Starting with Windows 11 22H2, it is enabled by default when HVCI or Smart App Control is on, and Windows Update pushes new signatures for it as new drivers are added. The full policy and the current list contents are documented in Microsoft's recommended driver block rules.

Enforcement means that when the kernel goes to load a driver, Code Integrity checks the image hash against the blocklist. A match refuses the load, no matter that the signature is valid. Vendors do not have to revoke certificates. The kernel simply says no.

Operators who want to see the current posture of a machine can check the registry key that controls the blocklist and inventory every loaded third-party driver in one pass. The first tells you whether Code Integrity is enforcing the list. The second tells you exactly which non-Microsoft images are currently sitting in the kernel.

# Is Microsoft's signed third-party driver Blocklist active on this machine?
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\CI\Config' `
    -Name VulnerableDriverBlocklistEnable -ErrorAction SilentlyContinue

# Running kernel drivers whose signer is not Microsoft.
Get-CimInstance Win32_SystemDriver |
  Where-Object { $_.State -eq 'Running' -and $_.PathName } |
  ForEach-Object {
      $p = $_.PathName -replace '"',''
      $s = (Get-AuthenticodeSignature $p).SignerCertificate.Subject
      [pscustomobject]@{ Name=$_.Name; Signer=$s; Path=$p }
  } | Where-Object { $_.Signer -notmatch 'Microsoft' }

A value of 1 for VulnerableDriverBlocklistEnable means Code Integrity is refusing listed hashes. Missing or 0 on Windows 11 22H2 or later almost always means the enforcement was turned off by policy or a tampering tool, which is worth an incident ticket on its own.

Phase two: HVCI as the enforcement point

The blocklist is only teeth if something enforces it above the kernel's normal signature check. Hypervisor-Protected Code Integrity is that something. HVCI moves the signature and blocklist decision into the secure kernel, running under Hyper-V's VTL1. A malicious ring-0 module cannot patch out the check the way it could patch SepPrivilegeCheck back in the CodeIntegrity days, because the check runs somewhere the compromised kernel cannot reach. We cover the mechanics in our HVCI deep-dive.

The practical effect: on an HVCI-enabled machine, dropping a known-signed third-party driver and calling NtLoadDriver returns STATUS_INVALID_IMAGE_HASH. The attack does not even reach the IOCTL step.

Phase three: Windows 11 24H2 and MiShowBadMapper

24H2 introduced a change specifically aimed at the physical-memory-aliasing class of signed-driver-abuse chain. Previously, a signed driver could call MmMapIoSpace(pa, len, MmNonCached) on the physical backing of a kernel virtual page that Windows had mapped writeback, obtain a second alias of that page, and write through the alias without triggering the SLAT permissions on the original mapping. Software page-table walkers used this to write to any kernel structure they could name.

On 24H2, MiShowBadMapper refuses to grant a NonCached alias to physical pages currently mapped writeback in the kernel. The call returns NULL, the driver's IOCTL handler eats it, and the primitive evaporates. This single change killed an entire generation of client-side page-walking signed-driver-abuse chain tooling.

Comparing the layers

Defense is layered because the offense is layered. Kill one primitive and researchers find a driver that exposes a different one.

Why cheat providers loved signed-driver-abuse chain, and why the serious ones left

For a solid decade, signed-driver-abuse chain was the default vehicle for game cheat kernel components. The economics were unbeatable. There was no need to buy an EV cert. There was no WHQL submission process to fail. There was no revocation delay for a driver an attacker did not sign. If Microsoft revoked the cert of a vendor whose driver you were riding, the machines that had already accepted the driver kept accepting it, and there was always another vendor with another bug.

That calculus flipped for the more mature providers between 2023 and 2025 for three reasons.

1. Blocklist velocity. The list started updating weekly instead of yearly. A driver that worked on Tuesday could refuse to load on Thursday, and a cheat provider whose entire loader depended on that driver had to scramble.
2. HVCI default on new hardware. OEMs enable HVCI out of the box on any machine shipped with a Secured-core badge, and Windows 11 22H2 and later enable it by default on new installs on capable hardware. The addressable market for a signed-driver-abuse chain loader shrank every quarter.
3. Anti-cheat integration. Vanguard (which moved to TPM 2.0 attestation for League of Legends in 2024), Byfron (Roblox, post the 2022 acquisition), EAC's post-2018 kernel component (Epic acquisition), and RICOCHET all query the loaded driver list, cross-check against their own blocklists, and terminate on match. A signed-driver-abuse chain loader that survives Windows will still lose the process to the anti-cheat.

KyTech made this call at founding. Our kernel stack ships as a properly signed component. We do not manual-map. We do not ride vendor drivers. The tradeoff is a real signing pipeline and the certificate hygiene that goes with it; the payoff is that our loader does not die every time Microsoft's monthly cumulative update lands.

How KyTech handles this

KyTech was founded in 2025 by two engineers who had spent enough time on the offensive side of the kernel to know exactly which shortcuts age poorly. Every product we ship for Apex Legends, Counter-Strike 2, Overwatch 2, Black Ops 7, Forza Horizon 6, and Roblox uses a signed KyTech driver. Our kernel stack is built to survive HVCI-on machines and quarterly blocklist pushes without any dependency on third-party signed drivers we did not author.

The KyTech HWID spoofer is our newest kernel component, currently in Apex-only beta. If a Windows Defender blocklist update ships tomorrow and enumerates every driver hash on your machine, ours is a normal signed driver from a normal software vendor, not a rebadged copy of a 2017 RGB tool. That difference matters when the anti-cheat asks the same question the OS is now asking on its own. The signed-driver architecture in this post is the exact model behind KyTech Apex, which is where our stack has been in production the longest.

The signed-driver-abuse chain era gave attackers and cheat authors a decade of easy wins. Microsoft finally closed the ergonomics gap that made it easy. Anyone still building on that foundation is building on a beach.