Five Minutes and an Empty Port Part 3: Bash Bunny, Key Croc, and O.MG Cable, or Why 802.1X Never Sees This Coming

Everything in Part 2 attacked the network. This part attacks the endpoint directly, through a class of USB device that every operating system trusts by design: the keyboard.

Why this vector is structurally different

The USB HID (Human Interface Device) class was standardized in the 1990s to cover keyboards, mice, and similar input devices, and it was built with one implicit assumption baked in: a device that identifies itself as a keyboard is a keyboard, and a keyboard is something a human is typing on. There is no authentication step, no certificate, no prompt asking whether this specific keyboard should be trusted. Windows, macOS, and Linux all still work this way. Plug in anything that speaks the HID keyboard protocol and the OS starts accepting keystrokes from it immediately, exactly as if a person sat down and typed them.

That single design decision is the entire basis for every device in this part. None of them exploit a bug. They exploit the fact that “typing” isn’t a thing any endpoint security product, antivirus, or EDR agent has ever meaningfully needed to distinguish as human or not, because until this category of hardware existed, only humans typed.

It also means every defensive control this series covers on the network side, port security, 802.1X, NAC, is completely blind to this vector. None of them inspect USB traffic. A device plugged into a workstation’s USB port never touches a switch port at all.

USB Rubber Ducky: where it started, and DuckyScript 3.0

The original USB Rubber Ducky, first sold around 2010, is the simplest device in this part: it looks like a USB flash drive, and it types. The payload language, DuckyScript, has grown considerably since the early versions. DuckyScript 3.0 adds real programming constructs on top of the original line-by-line keystroke commands: IF/ELSE conditionals, WHILE loops, function definitions, and variables, along with built-in OS detection so a single payload can branch its behavior between Windows, macOS, and Linux rather than needing a separate script per platform. It also adds jitter and randomization to keystroke timing specifically to defeat the simplest kind of detection, a script that types at an inhumanly perfect, constant rate. DuckyScript 3.0 stays backward compatible with the original 1.0 syntax, so the enormous existing library of community payloads still runs unmodified.

Bash Bunny: the platform that combines HID with network emulation

The Bash Bunny is a genuine multi-mode platform rather than a single-purpose device, and its ATTACKMODE command is the mechanism: a payload declares which USB device classes to emulate, from HID (keyboard), STORAGE (a mounted flash drive), SERIAL, ECM_ETHERNET, and RNDIS_ETHERNET (the two USB-Ethernet emulation modes, one for macOS/Linux/Android, one for Windows). Critically, these modes combine. A single payload can present itself as a keyboard and a gigabit Ethernet adapter simultaneously: inject a few keystrokes to open a terminal, then have the freshly-emulated network adapter, offered to the OS with a deliberately low routing metric, quietly become the target’s preferred route for a chosen slice of traffic. That’s the Bash Bunny’s real trick: it isn’t just Part 2’s network attacks or this part’s keystroke injection, it’s both, chained together, from a single USB port.

A physical three-position switch controls the Bash Bunny the same way it does the Shark Jack. Position 3, closest to the USB plug, is arming mode, with Serial and Mass Storage both enabled so payloads can be edited directly. The other two positions each run a stored payload slot on plug-in, letting one Bash Bunny carry two independent attacks and pick between them with the switch alone.

Key Croc: the keylogger that talks back

The Key Croc inverts the direction: instead of injecting keystrokes, it sits inline between a real keyboard and the target machine, silently logging every keystroke that passes through, in both directions. Where it goes further than a plain keylogger is the trigger system: a Key Croc payload can watch the logged keystream for a pattern, anything from a fixed keyword to a full regular expression, and fire an action the moment it matches, even accounting for the target typing a mistake and backspacing over it. A trigger match can save the surrounding keystrokes for later exfiltration, push a real-time notification through Hak5’s Cloud C2, or switch the Key Croc into an active mode that injects its own keystrokes back at the target, turning a passive logger into an automated response the instant a chosen password, URL, or command shows up in what’s being typed.

O.MG Cable: the one that looks like nothing at all

The O.MG Cable is the most quietly dangerous device in this part precisely because it doesn’t look like a device. It’s a genuine, functional USB charge-and-data cable with a full implant built into the connector housing, indistinguishable by sight from the cable it’s replacing. Once plugged in, it runs a Wi-Fi access point and web interface of its own, letting an operator connect from across a room, or from outside the building entirely with the right range, to trigger keystroke injection (rated at close to 890 keys per second, well beyond anything a human could type or plausibly notice happening) or retrieve logged keystrokes, with storage rated up to 650,000 keystrokes on the Keylogger edition. The Elite models add geofencing, so a payload only arms itself once the cable’s Wi-Fi radio detects it’s genuinely on-site rather than, say, sitting in a shipping warehouse or an evidence locker, and a self-destruct feature that wipes payloads and logged data on command or trigger, leaving an inert, ordinary-looking cable behind.

The realistic deployment path for an O.MG Cable is supply chain, not a drop-and-run visit: a swapped charging cable at a shared desk, a “spare” left in a meeting room drawer, or a cable substituted somewhere between a legitimate order and a desk. That’s a fundamentally different threat model than anything in Part 2, because there’s no device to notice at all. There’s just a cable, and every desk has several.

Where this leaves the network-side defenses

Every device in this part bypasses the entire Layer 2 and NAC toolkit this series builds toward in Parts 7 and 8, because none of them are network devices from the endpoint’s point of view. The defense for this vector lives somewhere else entirely: endpoint-side USB device control, which Part 9 covers alongside the wireless defenses, since both are the vectors that switch-side hardening simply can’t reach.

Part 4 moves to the third family: tools that don’t need a cable, a port, or physical contact with anything at all, just proximity to the air.