Windows PnP is the loader here.

Attacker-controlled device identities can make Windows fetch and run vendor code as SYSTEM—through emulated USB hardware or, in some environments, RDP USB redirection.

Full research by @0xedh and @Qm9yamFN: http://plugandpwn.com

https://x.com/0xedh/status/2085842285481062887/photo/1…

plugandpwn.com :: Plug and Pwn

Source: https://plugandpwn.com/

██▓███   ██▓     █    ██   ▄████     ▄▄▄       ███▄    █ ▓█████▄     ██▓███   █     █░███▄    █
▓██░  ██▒▓██▒     ██  ▓██▒ ██▒ ▀█▒   ▒████▄     ██ ▀█   █ ▒██▀ ██▌   ▓██░  ██▒▓█░ █ ░█░██ ▀█   █
▓██░ ██▓▒▒██░    ▓██  ▒██░▒██░▄▄▄░   ▒██  ▀█▄  ▓██  ▀█ ██▒░██   █▌   ▓██░ ██▓▒▒█░ █ ░█▓██  ▀█ ██▒
▒██▄█▓▒ ▒▒██░    ▓▓█  ░██░░▓█  ██▓   ░██▄▄▄▄██ ▓██▒  ▐▌██▒░▓█▄   ▌   ▒██▄█▓▒ ▒░█░ █ ░█▓██▒  ▐▌██▒
▒██▒ ░  ░░██████▒▒▒█████▓ ░▒▓███▀▒    ▓█   ▓██▒▒██░   ▓██░░▒████▓    ▒██▒ ░  ░░░██▒██▓▒██░   ▓██░
▒▓▒░ ░  ░░ ▒░▓  ░░▒▓▒ ▒ ▒  ░▒   ▒     ▒▒   ▓▒█░░ ▒░   ▒ ▒  ▒▒▓  ▒    ▒▓▒░ ░  ░░ ▓░▒ ▒ ░ ▒░   ▒ ▒
░▒ ░     ░ ░ ▒  ░░░▒░ ░ ░   ░   ░      ▒   ▒▒ ░░ ░░   ░ ▒░ ░ ▒  ▒    ░▒ ░       ▒ ░ ░ ░ ░░   ░ ▒░
░░         ░ ░    ░░░ ░ ░ ░ ░   ░      ░   ▒      ░   ░ ░  ░ ░  ░    ░░         ░   ░    ░   ░ ░
             ░  ░   ░           ░          ░  ░         ░    ░                    ░            ░
                                                           ░

plugandpwn.com::DEF CON 34::Weaponizing Windows PnP

00 abstract01 whoami02 vectors03 files04 media## Abstract

Every time a USB device is plugged into a Windows machine, the operating system may silently download a package from Microsoft and execute vendor code asNT AUTHORITY\\SYSTEM. That can happen without administrator privileges, without a logged-on user, and in some environments even remotely through RDP USB redirection.

This is the release kit for the DEF CON 34 talk. We are publishing everything, including the tooling, so you can reproduce the PnP part and check these primitives yourself.

• [00] Plug & Pwn: physical zero-click chain (Sierra + Sony)
• [01] NoPlug & Pwn: RDP USB redirection, no hardware
• [02] PnP internals & PNP simulate
• [03] vendor composition: Wacom + Atheros LPE
• [04] source, scripts

whoami

$cat ~/operators/0xedh

Alejandro Hernando0xedh

red_team_operator · vulnerability_researcher

Alejandro Hernando is a red team operator and security researcher with over a decade of hands-on experience in offensive cybersecurity. Throughout his career, he has assessed, exploited, and helped mitigate security vulnerabilities across commercial and proprietary systems, developing PoC exploits, offensive and defensive tooling, and conducting deep security research. His approach combines applied research with real world operational experience, driven by a focus on continuous learning and on sharpening both attack and defense strategies.

$cat ~/operators/borjmz

Borja Martinezborjmz

red_team_operator · vulnerability_researcher

Borja Martínez is a red team operator and security researcher focused on offensive security, advanced adversary simulation and hardware exploitation. A self-taught hacker with a deeply hands-on approach, he specializes in red team operations, penetration testing and low level attack research including DMA attacks, BIOS/UEFI exploitation, and TPM security.

Vectors

Every time a USB device is plugged into a Windows machine, the OS may silently download a package from Microsoft and run vendor code asNT AUTHORITY\\SYSTEM. It can happen with no administrator privileges and no logged-on user. Under the right conditions it also works remotely, with nothing plugged into the machine at all. The vectors below walk each path to that install flow, and the vendor primitives it ends up delivering.

[00] Plug & Pwn: physical zero-click chain (Sierra + Sony)

The setup: on the left, a fully updated Windows 11 box, no user logged in, nothing pre-installed. On the right, a Linux machine with a FaceDancer, emulating USB devices. It goes from nothing to SYSTEM with zero clicks. The real run takes about five minutes. At the end we drop a marker file and pop a SYSTEM shell, just to show it is the real thing.

POC 0 // zero-click physical chain: Windows 11 (no logon) to SYSTEM shell, ~5 min sped up. Left: target. Right: FaceDancer attacker box.This is one example of what the install path allows. We chain low-severity vulnerabilities from different vendors (some vendors don’t even consider them vulnerabilities) so that together they make a higher impact. The physical chain runs like this:

1. Emulate a specificSierradevice with a FaceDancer, then poll an unrestricted named pipe created by the vulnerable component itself.
2. Once the pipe exists, use it to change the machine’s default DNS. We serve a DNS that redirects everything to Google DNS except for our target.
3. Emulate aSonydevice. Once its service installs, it downloads components over HTTP from Sony servers. We control the DNS, so we are those Sony servers.
4. Serve specific files to exploit it: an arbitrary write as SYSTEM. We write a DLL intoSystem32.
5. Emulate the Sierra device again to get our planted DLL loaded. That is arbitrary code execution asNT AUTHORITY\\SYSTEM, before any user logs in.

Physical chain, steps 1 to 7: Sierra sets the DNS, Sony writes the DLL into System32, Sierra reloads it, SYSTEM.#### Sierra Wireless: SwiService.exe

The Sierra Wireless service runs as SYSTEM and exposes a named pipe with anEveryoneread/write ACL. Any local user, or any domain user, can connect and call theSetDNSfunction, locally or even over SMB. We point this DNS at the attacker address and replace the Sony lookups with our own server. The executable is hardcoded tonetshand the interface name comes from a system lookup and is not injectable. That doesn’t matter: the effect we want, pointing DNS at any IP, is exactly what the attack needs.

Sony FeliCa: felica_coinst.dll

The root cause is a signed catalog file with a co-installer DLL that runs as SYSTEM. During plug and play it fetches configuration files over plaintext HTTP, trusting everything it receives. The orchestrator pulls three text files over HTTP (an installation list, a URL list, and application info) and decides what to install.

When it downloads those files, it derives the on-disk filename by taking everything after the last forward slash in the URL. There is no filtering of dots or backslashes: the parser scans for/only, so a URL can use forward slashes up to the last one, then switch to backslashes for the traversal. The extracted string is concatenated intoTEMPand used as the write target. That is an arbitrary file write anywhere on disk, as SYSTEM, with fully attacker-controlled content, and we aim it straight intoSystem32. We don’t control Sony’s server, so we use the Sierra DNS bug to become it.

Two low-severity vendor bugs, from two different vendors, chained into arbitrary code execution as SYSTEM.

[01] NoPlug & Pwn: RDP USB redirection, no hardware

Everything above needed one thing: a USB device, emulated with a FaceDancer. The obvious objection is that you need physical access, you have to plug something in. What if we didn’t? What if we could reach the same PnP install path over the network, from a normal RDP session, with nothing plugged into the machine at all? The goal: take a standard user with RDP access, no admin rights, and turn it into SYSTEM. Remotely.

The key is a feature calledRDP USB redirection. Its legitimate purpose is simple: you plug a USB device into your laptop and it gets forwarded into your remote session. Here’s the catch. The server builds the PnP device node out of the USB descriptors the client sends. The client describes the hardware, and the server just believes it. There doesn’t have to be a real device on the other end.

The policy gate: umrdp.dll / termsrv.dll

When our device arrives, the server opens the Terminal Services policy key, checksfDisableUSBRedir, and only then reaches theADD\_DEVICEcall. That is the exact line that announces our phantom device to the PnP manager, the moment Windows commits to installing the driver as SYSTEM. It is fenced by one Group Policy setting:fDisablePNPRedir. We reverse-engineered the server side.termsrv\.dllpacks a single bit (bit 11) of the session config word, which is thefDisablePNPRedirpolicy, andumrdp\.dllchecks that bit before it ever announces our device. It defaults to disabled and only lets the device through when the value is exactly 0. No inputs come from us; it is pure server-side state. So the offensive question is: where is this gate already open? Environments where USB redirection is enabled on purpose, like managed VDI deployments.

Intel RealSense PoC

Instead of a real device, we forge one. We wrote a pure-Python RDP client on top of a library calledaardwolf, with no hardware at all. We authenticate as a normal user, open the URBDRC channel, and send anADD\_DEVICEmessage for any VID or PID we want. When the server asks for the descriptors, we synthesize them on the fly. The server’s USB hub driver enumerates our phantom device, and Windows PnP does exactly what it did in the physical demo: it matches the hardware ID and installs the driver, as SYSTEM.

For this demo we chose a different vendor, an Intel RealSense camera, to show this isn’t a one-off. It is a lovely local privilege escalation by itself. The driver is signed by Microsoft and installed from Windows Update, and during installation its co-installer drops an executable into a writable user directory and runs it as SYSTEM. That executable looks for a DLL in its own folder before it checksSystem32, and that folder can be written by normal users. A SYSTEM process, searching for a DLL, in a directory we control. That is classic DLL hijacking, except now we can pull the trigger remotely. As a standard user we drop our maliciousCRYPTBASE\.dllintoC:\\Intel\\RSDCM, fire the exploit with nothing plugged in, and end up writing intoC:\\Windows, which only SYSTEM can do.

POC 1 // standard-user RDP, forge Intel RealSense over URBDRC, signed driver installs as SYSTEM, co-installer sideloads CRYPTBASE.dll, SYSTEM. No hardware plugged in.

[02] PnP internals & PNP simulate

Zoom out. What we’ve really been abusing is the install path itself. Windows PnP will happily fetch and load hundreds of vulnerable signed packages for you, straight from Windows Update, fully trusted, without elevated privileges.**PnP becomes the loader.**The classic precondition, where you need admin to drop something and start it, just evaporates. We reached that same path two ways: physically with a FaceDancer, and remotely over RDP. During the research we used a third path to open the black box:PNP simulate, a tool we developed.

PNP simulate was not the final exploitation path. It was our way to reproduce the plug and play installation flow in a controlled way, without depending on real hardware in every test. It does more than print a VID and a PID. It creates aROOT-enumerated device with USB hardware IDsusing the Setup DI APIs, registers the device withDIF\_REGISTER\_DEVICE, looks for matches in the local Driver Store withDIInstallDevice, queries Windows Update COM usingIUpdateSearcher, and registers Plug and Play notifications withCM\_Register\_Notification.

Two modes matter. The default isquery-only: it creates the temporary devnode, queries, observes events, and cleans up. It does not download packages or leave persistent changes. Useful for discovery. With theinstall flagit callsCM\_Setup\_DevNodewithCM\_SETUP\_DEVNODE\_READY, which forces the devnode into the real installation path. That gave us a controlled way to compare discovery with real installation.

A trap in the research: it is tempting to say “Windows Update returned a package, so Windows will install it.” That is not true. The Windows Update COM API returns a lot of metadata: automatic, manual, old, and catalog-only packages. For discovery,IUpdateSearcheris very useful. For exploitation, what matters is theDevice Installation ServiceusingServer Side Resolve, a much more filtered path. Many candidates had a hit through Windows Update COM. Far fewer ended up in a real auto-download through the PnP path.

The real flow, in four phases

**Phase 1, identity.**With FaceDancer we present an emulated USB device. Windows reads the device descriptor, obtains the VID, PID and device class, then reads the configuration and interface descriptors. With that it builds hardware IDs, the strings it will later compare against the INFs. If we control the descriptors, we control the hardware IDs Windows tries to resolve.

Phase 1 // USB descriptors (VID / PID / class / interfaces) become the hardware ID strings Windows matches against the INFs.**Phase 2, identity to devnode.**In the real USB path the hub sees the emulated device, reads the descriptors, creates a Physical Device Object, and invalidates bus relations to tell the PnP Manager it has a new child device. The PnP Manager creates a devnode. In PNP simulate we reproduce, from user mode, only the part we care about: create a device info set (SetupDiCreateDeviceInfo), set the hardware IDs (SetupDiSetDeviceRegistryProperty), and register the device (SetupDiCallClassInstaller+DIF\_REGISTER\_DEVICE).

**Phase 3, CM_Setup_DevNode.**We did not want to rely only on documentation, so we looked at it with WinDbg. The call entersLocalCMSetupDevNodeand eventually reachesDeviceIoControlwith IOCTL0x47084F, which enters the Configuration Manager and PnP side in kernel. The user-mode call does not do all the work: it pushes an action into PnP, the action is queued, and the real work continues asynchronously. This capture confirmed the install flag was entering the path that activates real installation.

**Phase 4, PnP worker and Device Installation Service.**The PnP worker queries device IDs, resolves compatibility, adds and starts the devnode, and needs a compatible package. That is where the Device Installation Service appears:DSMSVC, insidesvchost, running as SYSTEM. It looks in the local Driver Store; if there is no match it can use Server Side Resolve; if the package can be installed automatically, Windows downloads the CAB from Windows Update, stages it in the Driver Store, and launches the install sequence, whereDRVINSTappears. If the package brings a co-installer, a support executable, a service or extra logic, that software enters a privileged path the user never approved through a UAC prompt.

POC 2 // PNP simulate: query-only vs install flag on an emulated Wacom device. SetupAPI log on the right; WinDbg breakpoints on CM_Setup_DevNode and IOCTL 0x47084F; Device Installation Service kicks in.

[03] Vendor composition: Wacom + Atheros LPE

Windows has accepted a hardware identity, resolved it against signed or known packages, and entered a privileged installation path. But there is a difference betweencryptographic trustandlogical security. A signed package does not mean every service, co-installer, debug flag or registry value has been audited from an offensive point of view. And no UAC does not mean no privileged action. This is also why vendor conversations get complicated. Often there is no overflow, no use-after-free, no crash. There is privileged logic that accepts input controllable by the user or another component. Separately, each piece looks defensible as functionality. Put together, the result has security impact.

Wacom: the SYSTEM shell

In the Wacom service binary (signed and distributed as part of the package) we found a comparison against a hardcoded value. In registry bytes it appears as7F 4C 6B 34. When the service sees that value in the correct key, it follows a path that ends with CMD running as SYSTEM. We won’t claim it is a backdoor. It could be a debug stub, support functionality, or an internal path that should never have been exposed. From an offensive point of view it is a very clean bug. The value name isPowerT, written asREG\_BINARYunderHKLM\\SYSTEM\\CurrentControlSet\\\.\.\., with a gate aroundAutoAdminLogon(it must be zero or absent). When the check passes,WTabletServiceISD, running as LocalSystem, reachesCreateProcessAsUserWon thedefaultdesktop and spawns CMD. This is not a hidden session-0 process. It is an interactive SYSTEM shell on the user’s desktop. By itself, though, it needs one thing a standard user does not have: write access toHKLM.

POC 3 // Wacom isolated: write PowerT (REG_BINARY, 7F 4C 6B 34) under the WTabletServiceISD key, restart the service, interactive CMD, whoami, NT AUTHORITY\SYSTEM.#### Atheros: the privileged registry write

So, do we have another component, also installed by PnP, that can write that privileged part for us? Atheros. After reviewing it, it matched a CVE from seven years ago (2019). We assumed Microsoft would have revoked the certificate and the package would no longer install. Spoiler: it still does. The package installsAtherosSVC(Admin Service), running as LocalSystem. It readsC:\\ProgramData\\Atheros\\AtherosServiceConfig\.iniand reacts to service control code133. On that control code it reads the INI and performs registry operations: create key, open key, delete key, set value. The user controls the input, the service provides the privilege, and the result is a privileged registry modification.

Print Monitor: the bridge, and the final chain

The direct chain we wanted (Atheros writesPowerTasREG\_BINARY, restart Wacom, SYSTEM shell) did not quite work. The Admin Service parser reads character by character, so it generates bytes that are not the ones Wacom expects. Real chains are rarely as clean as you want. The path that worked: we use Atheros to create a Print Monitor entry underHKLM\\SYSTEM\\CurrentControlSet\\Control\\Print\\Monitors\\PocPortMon, pointing atC:\\ProgramData\\Atheros\\PocPortMon\.dll. The Spooler runs as SYSTEM; whenspoolsvstarts it enumerates the registered Print Monitors and loads that DLL. A standard user can placePocPortMon\.dllin ProgramData; Atheros writes the privileged key for us; after a reboot the Spooler loads our DLL as SYSTEM. Now our DLL callsRegSetValueExdirectly to writePowerTwith the correct bytes, then restarts the Wacom service, which spawns the interactive SYSTEM shell.

1. PnP installs vendor software (Wacom + Atheros) from emulated USB identities.
2. Atheros gives us a privileged registry write.
3. Print Monitor gives us SYSTEM execution (Spooler loads our DLL).
4. Wacom gives us the shell.

POC 4 // full chain as unprivileged user: emulate Wacom + Atheros via Cynthion, drop PocPortMon.dll, Atheros writes HKLM, reboot, Spooler loads DLL as SYSTEM, writes PowerT, restart Wacom, interactive SYSTEM shell.We did not start as admin. We did not use real vendor hardware. We did not install our own vulnerable service. We composed functionality and logical bugs from software that arrives on the machine through the PnP path. For a physical red team operation, this is a local privilege escalation with plenty of room to operate. You do not always need to bring a kernel exploit.

Release Files

The code and PoCs are up. Click any file to download it and reproduce the PnP part or check the primitives yourself.

FileWhat it isVectorStatususb\_trigger\.pyFaceDancer script that emulates the USB identities (VID/PID, descriptors) used in the demos.[00] physicalreadyrdp\_usb\_pnp\.pyPure-Python RDP client that forges a USB device over URBDRC (no hardware) to trigger the PnP driver install remotely as a standard user.[01] rdpreadypnp\_simulate\.cSource for the PNP simulate tool: devnode creation, Setup DI, Windows Update COM, query-only vs install flag.[02] internalsreadybuild\.batMSVC build script forpnp\_simulate\.c: loads the VS toolset via vswhere and compiles the tool.[02] internalsreadywacom\_powert\.regWacom PoC: the PowerT registry value and steps that turn the service into an interactive SYSTEM shell.[03] vendorready

Official Media

ItemLocationStatusTalk recordingDEF CON mediapendingSlides PDFDEF CON mediapendingDemo videosDEF CON mediapending