Researchers Alejandro Hernando and Borja Martinez presented "Plug And Pwn: Weaponizing Windows PnP Auto-Install" at DEF CON 34. The result: SYSTEM-level code execution on a fully updated Windows 11 machine, using nothing that is broken.
Plug and Play works like this. Windows receives hardware and compatible IDs from a connected device, looks up a matching signed vendor driver, and installs it. That is the feature. Every part of it is doing what it is supposed to do.
The attack is to choose which drivers get installed.
The chain
- Emulate a Sierra Wireless device. Windows installs the vendor package, which includes
SwiService.exe— a service running as SYSTEM. - Use a DNS redirection primitive the service exposes.
- Emulate a Sony FeliCa reader. Its installer retrieves configuration over unencrypted HTTP, to predictable local filenames.
- Exploit path-traversal flaws in that retrieval to place a malicious DLL into System32.
- Reconnect the Sierra device. The SYSTEM service loads the DLL.
Five steps, two emulated devices, no exploit against Windows itself. The weaknesses live in third-party driver packages that Windows fetches and installs because they are signed and because the device asked.
That is also why the article carries no CVE identifiers. These are vendor-specific weaknesses in shipped driver software, not flaws in the operating system — which makes them harder to track and harder to declare fixed.
The Remote Desktop variant
The same chain works without anyone touching the machine.
The researchers forged synthetic USB traffic over Remote Desktop and presented a phantom Intel RealSense device, then exploited DLL search-order hijacking from user-writable installation directories.
Microsoft's position is that the required features — supported Plug and Play, or low-level USB redirection — are not allowed by default on Remote Desktop Services.
Read that carefully. "Not allowed by default" is accurate and is not the same as "off in your environment." RDS deployments that support hardware tokens, scanners, signature pads or card readers have turned redirection on deliberately. Those are exactly the deployments in healthcare, finance and logistics.
Preconditions, stated plainly
| Variant | Requires |
|---|---|
| Physical | Ability to present an emulated USB device to the machine |
| Remote | PnP or low-level USB redirection explicitly enabled on RDS |
Neither is a remote unauthenticated attack. Both are realistic for the environments they apply to: a kiosk, a shared workstation, a locked laptop in an office, or a remote desktop farm with redirection on for a business reason.
Microsoft's guidance is the mitigation
There is no patch to apply here, which is the awkward part. What exists is policy:
- Device installation policies let administrators block devices by hardware ID, compatible ID or setup class.
- On Remote Desktop servers, those same policies govern redirected devices.
- USB redirection can be disabled entirely where it is not needed.
That is a genuinely effective control and almost nobody has it configured, because configuring it requires knowing which device classes your estate actually needs — which is an inventory problem, not a security one.
Why this is worth attention now
The instinct is to file this under "physical access is game over anyway." That instinct is thirty years old and it was never quite right.
Modern endpoint hardening has spent a decade making physical access less decisive: full-disk encryption, Secure Boot, virtualisation-based security, credential guard. The threat model has moved toward "attacker briefly touches the machine" rather than "attacker takes the machine home." Plug And Pwn is squarely in that model — a few seconds at a locked workstation.
It also rhymes with the U-Boot FIT signature flaws Binarly documented earlier this year: signed does not mean safe, when the thing being signed is a component whose own behaviour is the weakness.
What to do
- Inventory the device classes you need, then block the rest with device installation policy. Start with setup classes, not individual hardware IDs.
- Audit RDS for USB redirection. If it is on, find out which business process needs it and scope the policy to that.
- Treat unattended workstations as reachable. Reception desks, meeting rooms, clinical carts, warehouse terminals.
- Do not wait for CVEs. There are none, and the affected code is vendor driver packages that may never get advisories.
