When the Hardware Isn't There: Coaxing Vulnerable Drivers Into Range
BYOVD research keeps colliding with a stubborn problem, many kernel drivers refuse to talk unless their device is plugged in. New work shows how to make them talk anyway.
Key points
- Windows kernel drivers can be made to expose their full attack surface without the physical hardware they were designed for.
- The technique patches or emulates the bus-handshake checks that normally gate a driver's dispatch routines.
- A discontinued RAID driver from 2014 can become a working privilege-escalation tool on a fully patched Windows 11 machine.
- The approach expands the population of exploitable signed drivers sharply, increasing pressure on Microsoft's blocklist team.
- Threat actors have already weaponised signed drivers to disable endpoint sensors; faster discovery makes that tactic more accessible.
What is the hardware gate, and why did researchers treat it as a barrier?
Most Windows kernel drivers check that expected hardware is present before they answer any request from user mode. A fresh IOCTL fuzzer, fired at a signed driver pulled from a GPU vendor's installer, comes back with STATUS_NO_SUCH_DEVICE again and again because the driver calls something like IoGetDeviceProperty, gets nothing back, and exits early. The vulnerable code sits right there in the disassembler, reachable on paper, unreachable in practice without a specific PCI device on the bus.
New technical work circulating this week lays out how researchers sidestep that gate entirely, with implications for offensive tooling and for defenders trying to predict which signed drivers land on Microsoft's vulnerable driver blocklist next.
How does the bypass actually work?
The core trick is unglamorous and effective. Patch the PCI enumeration handshake out of the driver, or emulate the bus response in a thin shim sitting above it, and the rest of the driver's attack surface opens up. IOCTLs that returned early now reach the MmMapIoSpace calls, the arbitrary MSR writes, the physical memory primitives that make Bring Your Own Vulnerable Driver attacks attractive in the first place.
A driver shipped for a discontinued RAID card can carry a textbook arbitrary-write primitive. Without hardware it looked unreachable. With a fifty-line emulation layer it becomes a loaded weapon any attacker holding admin rights can carry onto a fully patched Windows 11 box and use to disable endpoint detection software.
Should you worry if your organisation already blocks untrusted drivers?
The technique is not new in spirit. Threat actors have reached for signed drivers to blind endpoint sensors before, and Scattered Spider has been observed loading an anti-malware driver for the same purpose. What is shifting is the speed of discovery. Threat Vectr has covered EDR evasion tactics four times, including three stories in the last 90 days, because the tooling keeps evolving faster than blocklists do.
If the hardware gate is no longer a filter, the population of interesting signed drivers grows by an order of magnitude, and so does the workload for whoever maintains the blocklist. Organisations relying on driver allowlisting should treat any signed driver from a discontinued product line as a potential gap until it has been reviewed against current blocklist entries.
One researcher familiar with the work put it plainly: "We were treating 'needs hardware' as a mitigation. Never a mitigation. A speed bump, and we just removed it."
The driver that refused to answer eventually did. Fourth IOCTL, kernel crash.
