Bring Your Own Vulnerable Driver Just Became Have Windows Fetch It For You. A Forged USB Descriptor Makes a Patched Windows 11 Install Signed Vendor Software as SYSTEM.
- Patrick Duggan
- 1 hour ago
- 5 min read
Alejandro Hernando and Borja Martínez presented "Plug & Pwn" at DEF CON 34. The PoC is now public. The short version is that you can plug a device into a fully patched Windows 11 machine with nobody logged in, and end up with code running as NT AUTHORITY\SYSTEM — without a single click, and without exploiting a vulnerability in Windows.
We are covering it because it belongs to a class we have been tracking all day, and because the framing in most of the coverage undersells what actually changed.
What happens
Windows Plug and Play does what it has done since the nineties. You connect hardware, Windows reads the device descriptors, identifies the hardware, finds the matching driver package, and installs the vendor's software. That installation runs as SYSTEM, because installing a driver requires it.
Every part of that is intended behaviour.
The researchers used a Linux box running FaceDancer — a USB device-emulation platform — to impersonate chosen USB hardware identities. Windows believed the descriptors, matched them to vendor driver packages, and installed signed vendor software containing components with known weaknesses. From there, SYSTEM.
Target: a fully patched Windows 11 system. No active user session. Some variants need no user interaction at all.
The reframe that matters
For years the technique here has been BYOVD — bring your own vulnerable driver. The attacker carries a legitimately signed but exploitable driver onto the box, loads it, and abuses it to get kernel privileges. Every defensive control built for this assumes the same thing: the attacker has to deliver the driver. So we built driver blocklists, we watch for unusual driver writes, we alert on unexpected kernel module loads from user-writable paths.
Plug and Pwn inverts the delivery. The attacker does not bring the driver. The attacker brings an identity, and Windows fetches the driver.
That is a different problem. The vulnerable component arrives through the sanctioned driver-installation path, signed, matched to hardware the OS believes is present, installed by a trusted system process. It is not dropped in a temp directory by a suspicious binary. It is not sideloaded. It looks exactly like a laptop getting a dock.
The trust decision that decides which signed package gets installed as SYSTEM is made on a string the attacker fully controls — the USB descriptor. There is no authentication of a USB device's claimed identity. There never has been. That was fine when claiming to be a Logitech mouse required being a physical object someone plugged in.
And it works without the physical object
The variant that should worry anyone running virtual desktops is the one they call NoPlug and Pwn.
It targets environments where RDP USB redirection is deliberately enabled — which is a large share of VDI deployments, because users want their headsets, badge readers and scanners to work in the remote session. A standard RDP user can send forged USB descriptors over the URBDRC channel, and the remote host will enumerate a device that does not physically exist anywhere.
So: no hardware, no physical access, no evil maid, no dropped-USB-in-the-parking-lot. An ordinary remote user with a normal RDP session, on a feature the administrator turned on for good reasons, triggering a signed vendor driver install as SYSTEM on the host.
For a VDI estate, that reads as a privilege escalation available to every user with a session, delivered over a channel most monitoring treats as peripheral noise.
The pattern of the day
This is the third time today we have written about the same shape, and we want to name it because it keeps producing the expensive surprises.
This morning it was afd.sys — a kernel driver from the Windows NT 3.51 era, servicing a socket API specified in January 1993, producing its fifth actively-exploited privilege escalation. Then it was City-Forum, reading Salesforce and ServiceNow portals worldwide for seventeen months through guest access, with no CVE, because nothing was broken. Now Plug and Play, a feature that shipped with Windows 95, handing out SYSTEM to a forged descriptor.
None of these three is a vulnerability in the ordinary sense. There is no patch that fixes "Windows installs drivers for hardware you connect," any more than there is a patch for "Salesforce shows guest users what you marked public." These are design decisions from an era with different assumptions, still load-bearing, still trusted, and now being enumerated by people with tooling the original designers could not have imagined.
Your vulnerability management programme has nothing to say about any of them. That is not a criticism of vulnerability management. It is a statement about its scope, and about the size of what sits outside it.
What to actually do
Turn off RDP USB redirection where you do not need it. This is the single highest-leverage control here, it is a policy setting, and in most VDI estates the redirection is on because it shipped on rather than because anyone requires it. If you do need it, restrict which device classes may redirect.
Use device installation restrictions. Windows has had Group Policy controls for years that allow driver installation only for approved device IDs, or block by device class. Almost nobody deploys them because they generate helpdesk tickets. The tradeoff has changed.
Inventory what your driver store will happily install. The attack depends on vendor packages already deemed installable containing exploitable components. Microsoft's vulnerable driver blocklist is necessary and not sufficient — it is a list of known-bad, and this technique is a search for anything-weak-enough among the signed-and-allowed.
Watch for driver installs on machines with no logged-in user. A workstation installing new vendor software at 3am with nobody at the keyboard is a high-signal event, and it is one of the few places this chain is loud.
Credit and what we held
The research is Hernando and Martínez's, presented at DEF CON 34, and the PoC is public — which means the window between demonstration and commodity use is open now rather than later, the same window we wrote about with yesterday's KEV additions.
We hold nothing on this. There are no network indicators to hold — the entire chain is local or intra-session, and produces no C2, no domain, no hash we would have caught. That is worth saying plainly, because a feed is not a universal instrument, and a threat-intel outfit that pretends otherwise is selling you something. This one is defended with configuration, not with a blocklist.
Ninety-five percent. If you run VDI with USB redirection enabled and you check your driver-install logs after reading this, we would like to hear what you find either way.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=bring-your-own-vulnerable-driver-just-became-have-windows-fetch-it-for-you-a-forged-usb-descriptor
Comments