Can a Rubber Ducky do Plug & Pwn?

I really wanted the answer to be yes

I sat down with the DEF CON 34 release kit from Alejandro Hernando and Borja Martínez — plugandpwn.com — and a Hak5 USB Rubber Ducky that has lived in too many kit bags. The question was the one everyone asks in Slack, usually with a hopeful emoji:

Can I just… DuckyScript the Plug & Pwn thing?

Short answer: no.

Longer answer, which is why you are still here: Plug & Pwn is a USB-identity attack that rides Windows Plug and Play. A Hak5 USB Rubber Ducky is a keystroke injector. Those are different devices, different primitives, and different trust boundaries. Once you see it, you cannot unsee it. I am going to walk the same path I did, including the part where I thought ATTACKMODE HID VID_xxxx PID_yyyy might be a clever loophole. It is not. It is a costume.

This note does not include a working attack payload. If you came for inject.bin, you came to the wrong lab.

What Plug & Pwn actually is (and why I had to reread the abstract)

The release is not “plug in a USB and type commands.” That was my first wrong mental model, and it is a very Rubber Ducky mental model, which is how I got here.

Windows, when it sees a new USB hardware identity, may resolve a matching vendor package from Windows Update and run that vendor’s install code as NT AUTHORITY\SYSTEM. Documented behavior. No UAC. No administrator. In the physical demo, no user even logged on. PnP is the loader. The authors are explicit: this is not a Windows zero-day, and there is no CVE for “Windows installs drivers.” The novelty is reachability and composition of packages that already shipped signed.

They published four related vectors. I keep them on a card because people collapse them into “the USB thing.”

Physical zero-click. A Linux box with a FaceDancer emulates specific USB devices. Windows installs the matching signed packages. Then two vendor bugs get married: a privileged DNS change, a SYSTEM file write, a reload that executes attacker-controlled code. About five minutes. Lock screen still up. A keyboard has almost nothing useful to type at that screen. PnP does not need a desktop. That was the first “oh.”

NoPlug / RDP. No USB hardware at all. A standard-user RDP client forges descriptors over USB redirection. This only works where the server has fDisablePNPRedir = 0 — some VDI fleets, not the Windows default. I keep saying that because “it works over RDP” without the policy footnote is how rumors get born.

PNP simulate. A research tool that creates a ROOT-enumerated devnode with USB hardware IDs from user mode so you can study the install path without gadget hardware. Discovery aid. Not the field delivery mechanism. If someone tells you this is the exploit, they have not read section 02.

Vendor composition. After PnP has laid down signed vendor software, logical bugs in those packages — privileged registry writes, service debug paths, print monitors — get chained into an interactive SYSTEM shell. Still requires the packages to have arrived via the PnP path. The first hop is belief. Everything else is leftovers.

What a Rubber Ducky actually is (this is the sad part)

The USB Rubber Ducky is a Hak5 device. It enumerates as a Human Interface Device. A keyboard. Optionally a mouse or serial gadget depending on ATTACKMODE. DuckyScript is a language for HID reports: key-down, key-up, delays, strings. Newer firmware can spoof the keyboard’s USB vendor and product IDs.

It does not become a baseband modem. It does not become an NFC reader. It does not become a digitizer tablet. It does not become a Wi-Fi adapter. It becomes a very fast, very obedient keyboard with a fake name tag.

That single fact kills the method. I wrote it on a sticky note and put it on the Ducky so I would stop bargaining with it.

• Plug & Pwn’s loader is USB identity → hardware ID → Device Installation Service.

• A Ducky’s loader is HID report → focused window → whatever keystrokes the current session will accept.

• POC 0 on plugandpwn.com runs at the logon screen with nobody logged in. A keyboard has almost nothing useful to type there. PnP still installs. That is the whole point of the research, and also the whole reason the Ducky cannot come.

Primitive matrix

I made the table because arguments on this topic tend to wander. Stay on the primitive.

The misconception I almost shipped: ATTACKMODE HID VID_xxxx PID_yyyy is “close enough.” Windows may build a hardware ID from those numbers. The device is still a HID keyboard. Plug & Pwn depends on the Device Installation Service treating the identity as a specific vendor function and then running that function’s co-installer or service. Relabeling a keyboard is not FaceDancer emulation. It will not carry the published chains. I checked, then I checked again, then I closed the DuckyScript editor before I wrote something embarrassing.

The published physical chain — and where the Ducky dies

This is the public Sierra + Sony story, kept at the level of what happens, not how to weaponize it.

1. Present a Sierra identity. FaceDancer enumerates a specific Sierra Wireless device. Windows reads descriptors, builds hardware IDs, and may auto-install the matching signed package as SYSTEM. Ducky: presents as a keyboard. Wrong class, wrong descriptors, wrong package. Game over in step one, but we keep walking because the rest is educational.

2. Use a privileged vendor primitive to point DNS at the attacker. A Sierra service running as SYSTEM exposes an overly open control surface that can change the machine’s DNS. Ducky: cannot open that control surface. It can only type, and only if someone is logged in.

3. Present a Sony identity. A Sony FeliCa-related package installs. Its co-installer fetches configuration over plaintext HTTP and trusts what it receives. Ducky: cannot become that Sony device, and cannot be the HTTP server the co-installer calls. Two jobs. Zero of them are “STRING.”

4. Turn a path-handling bug into a SYSTEM file write. The installer derives an on-disk path from a URL and writes attacker-controlled content into a privileged location. Ducky: has no role in that write. This is vendor install logic, not keystrokes.

5. Re-present the Sierra identity so the planted code is loaded. Code execution as SYSTEM before logon. Ducky: cannot do the reload trigger as published. Also still a keyboard.

The Wacom + Atheros composition is the same shape: PnP lays down signed vendor software, then logical bugs in that software get composed. The first hop is still “Windows must install those packages because it believed a USB identity.” A Rubber Ducky does not supply that identity. It supplies asdfasdfasdf at 1000 words per minute if you let it.

DuckyScript — a note you can keep next to the hardware

There is no DuckyScript that implements Plug & Pwn. The listing below is a non-operational brief. It does not spoof vendor function IDs, does not drop files, and does not invoke any install or privilege-escalation primitive.

Working exploit DuckyScript — VID/PID swaps aimed at those packages, commands that talk to vendor services, DLL writes, registry writes that pop a SYSTEM shell — is not included here on purpose.

REM ============================================================
REM  FILE: plug-and-pwn-cannot-run.txt
REM  ROLE: operator note, not a payload
REM  TARGET METHOD: plugandpwn.com (DEF CON 34)
REM ============================================================

REM Rubber Ducky language surface is HID reports plus a few
REM device modes (HID, STORAGE, SERIAL). None of those modes
REM is "emulate an arbitrary USB function so PnP fetches a
REM vendor CAB from Windows Update and runs its co-installer."

ATTACKMODE HID

REM What people think might work, and why it does not:
REM
REM   ATTACKMODE HID VID_XXXX PID_YYYY
REM
REM That only relabels the keyboard. Device class, interface
REM descriptors, and endpoints stay HID. Plug & Pwn's physical
REM chain needs a gadget that can:
REM   1. enumerate as vendor function A
REM   2. disconnect
REM   3. enumerate as vendor function B
REM   4. while an attacker resolver answers the DNS the first
REM      package just pointed at the attacker
REM
REM DuckyScript has DELAY, STRING, GUI, ENTER, DEFINE, FUNCTIONS,
REM and extensions. It does not have:
REM   - SET_USB_CLASS / SET_INTERFACE_DESCRIPTOR
REM   - EMULATE_DEVICE sierra | sony | wacom | atheros
REM   - SERVE_DNS / SERVE_HTTP as a vendor origin
REM   - SPEAK_NAMED_PIPE / SERVICE_CONTROL
REM
REM POC 0 on the site is the tell. The target is sitting at
REM the logon screen. A keyboard has nowhere to type. PnP
REM still installs. That is the whole point of the research.
REM
REM If the goal is authorized research of the PnP path, use
REM the tooling the authors shipped for that purpose:
REM FaceDancer / Cynthion gadget scripts, or their PNP
REM simulate helper — on machines you own or have written
REM permission to test. Do not try to compress that stack
REM into inject.bin.

REM Intentionally no STRING, no GUI r, no powershell.
REM This script injects nothing.

If you are doing authorized research of the PnP path, use the tooling the authors shipped: FaceDancer / Cynthion gadget scripts, or their PNP simulate helper, on machines you own or have written permission to test. Do not try to compress that stack into inject.bin. I already tried the thought experiment. The compiler in my head returned a polite 415.

What actually reduces this class of risk

If you opened this because a Rubber Ducky felt like a convenient stand-in for the research, flip the question. How do you stop any unsolicited USB identity from becoming a SYSTEM installer?

• Device installation restrictions / hardware-ID allow lists. This is the control that matches the problem. PnP should not be free to fetch arbitrary vendor packages. Everything else is coping.

• Disable co-installers where you can live with the breakage. The authors say this stops some of their demos (Sony, RealSense) and does not stop every package that can still run privileged install logic. Necessary. Not sufficient. I have that tattooed on the inside of my eyelids now.

• Keep fDisablePNPRedir at the default (redirection off) on RDP / VDI hosts that do not need USB redirection. The remote chain is gated by that one policy bit. One bit. I love a one-bit gate. I also love people remembering it exists.

• Treat “signed by Microsoft / in Windows Update” as cryptographic trust, not logical safety. A catalog signature does not audit every service ACL, debug flag, or HTTP fetch inside the package. Signed means the bits match a signer. It does not mean someone hostile sat with the co-installer for a week.

• Do not confuse HID hardening with PnP hardening. Blocking Rubber Duckies — USB HID allow lists, endpoint protection that flags rapid keystroke injection — does not block FaceDancer identities. And vice versa. Two different animals. Two different fences.

Compiled from the public abstract at plugandpwn.com. No exploit reproduction. No vendor hardware IDs. No payload binaries. Just me, a Hak5 USB Rubber Ducky that cannot become a modem, and a slightly better question than the one I started with.