USB Rubber Ducky

The USB Rubber Ducky is a keystroke injection tool that looks like an ordinary flash drive. It is not storage. When plugged in it declares itself to the host as a keyboard and types a prepared payload at machine speed, which means nothing is written to disk during the initial compromise and there is no file for antivirus to scan.

It is also the most misunderstood device in its category, because the name is used for two different things: the Hak5 product, which has no radio at all, and a family of inexpensive Wi-Fi-enabled clones that do. Getting that distinction right determines which of your controls actually apply.

CTO Dr. Brett Walkenhorst discusses keystroke injection devices and the wireless variants of this attack class.

This information is provided for general awareness and defense purposes only.  This information also is not intended to be a complete description of the functionality or risks of the identified tools.

Quick Facts

• What it is: A purpose-built keystroke injection device that enumerates as a keyboard and types a prepared payload.
• Radio: The genuine Hak5 device has none. Wi-Fi-enabled clones built on ESP8266 and ESP32 hardware are a separate, cheaper product class.
• Access required: An unlocked, logged-in session and seconds of unattended physical access.
• Why antivirus misses it: The initial compromise writes no file and produces no signature. The input arrives through the same trusted path as a real keyboard.
• Best cheap detection signal: A second keyboard enumerating on a single-user workstation.
• Related category: HID spoofing, which also covers BadUSB, the O.MG Cable, and the Bash Bunny.

What Is a USB Rubber Ducky?

A USB Rubber Ducky is easy to conceal and looks, on first physical inspection, like an ordinary USB stick. What it actually contains is a microcontroller that declares itself to the host as a Human Interface Device. Operating systems extend implicit trust to keyboards, so the device is permitted to type immediately on enumeration, at a speed no human can match.

It is closely related to BadUSB, the 2014 research by Nohl and Lell that showed ordinary USB devices could be reprogrammed at the firmware level to lie about what they are. The distinction the security community draws is that BadUSB describes reprogrammed everyday hardware, while the Rubber Ducky class is purpose-built for the job. Both fall under HID spoofing.

Is the USB Rubber Ducky Wireless?

Not the Hak5 product. This is the single most common point of confusion about the device, and it matters because it determines whether wireless monitoring is a relevant control.

	Hak5 USB Rubber Ducky	Wi-Fi “Rubber Ducky” clones
Radio	None	Wi-Fi, typically ESP8266 or ESP32
Control	Pre-compiled payload, fires on insertion	Live browser-based control over the device’s own access point
Exfiltration	Physical retrieval, or a covert channel such as Keystroke Reflection	Over the air
Typical cost	Around $80 retail	Roughly $13 and up, widely available
Examples	Hak5 Gen 3 with DuckyScript 3.0	wifi_ducky, WiDucky, USB Nugget, Cactus WHID

Hak5’s own documentation describes DuckyScript 3.0 in terms of HID and storage attack modes, operating system detection, timing jitter, and Keystroke Reflection. It does not describe a radio, and practitioner reviews consistently list the absence of wireless exfiltration as a limitation of the genuine device.

The defensible way to talk about this threat is as a keystroke injection class, with the Hak5 Ducky as the wired archetype and the O.MG Cable, Bash Bunny Mark II, WHID, and ESP-based clones as its wireless members. Anyone who tells you the Hak5 Rubber Ducky communicates over Wi-Fi is describing a different device.

How Does It Work?

Once the device is plugged into an unlocked machine, it types. What it types is a payload written in DuckyScript, which on current Hak5 hardware is compiled to a binary the device replays. The capabilities that matter to defenders are these:

• HID and storage modes. The device can present as a keyboard, as storage, or both, so a payload can type commands that then read from the device itself.
• Operating system detection. Payloads can branch on the host they land on rather than assuming a target.
• Timing jitter. Randomized delays between keystrokes exist specifically to defeat detection based on inhumanly regular typing.
• Keystroke Reflection. A covert channel that reads lock-key LED state to carry data back to the device. It is slow and low-bandwidth, and it is the reason “no radio” does not mean “no exfiltration,” including in air-gapped environments.
• Keymaps. Payloads assume a keyboard layout. A mismatch mangles characters, which is one of the most common reasons a real-world attempt fails.

DuckyScript has also been licensed to other platforms, which is why it appears on devices that are not Hak5 products. On the Ducky it is compiled ahead of time; on the O.MG Cable, Bash Bunny, and Key Croc it runs interpreted, which allows conditional logic at execution time.

How It Compares to Other USB Attack Devices

Practitioners consistently ask for a capability matrix rather than marketing copy. The axes that matter are whether the device has a radio, whether it supports live control or fires and forgets, and which USB classes it can emulate.

Device	Radio	Control model	Emulated classes
Hak5 USB Rubber Ducky	None	Fire on insertion	HID, storage
Wi-Fi Ducky clones (ESP8266/ESP32)	Wi-Fi	Live browser control	HID
Bash Bunny Mark II	BLE	Switch-selected payloads, remote trigger	HID, Ethernet, serial, storage
O.MG Cable	Wi-Fi	Live browser control, network C2 on Elite	HID, plus passive keylogging
WHID / Cactus WHID	Wi-Fi	Live control	HID
Flipper Zero	Sub-GHz, NFC, BLE	On-device and app control	HID, plus multi-protocol RF
Digispark and similar	None	Fire on insertion	HID

How Much Access Does an Attacker Need?

Seconds, and an unlocked session. Demonstrations typically assume a window of ten to thirty seconds at an unattended machine.

The locked-screen caveat is the community’s most-repeated and most important qualifier: keystroke injection into a locked workstation does nothing, because there is no session to type into. Everything else about the attack is social engineering aimed at manufacturing that unlocked moment, which is why lock-screen discipline is a more valuable control than its cost suggests.

Two related questions come up often. Published injection speeds are manufacturer claims rather than measured results, and effective speed is constrained by the target’s input buffer, application focus, and the deliberate delays payloads need to stay reliable. And these devices do work against phones and tablets where USB host negotiation permits it, which is why cable-form implants ship with USB-C active ends.

What Detection Actually Catches

Naming the gaps is more useful than claiming coverage. Here is what each layer does and does not catch for this device class.

Layer	Catches	Misses
Antivirus	Nothing at injection time	The entire vector; no file, no signature
EDR	Post-execution artifacts: process spawn, encoded command lines, outbound connections, persistence writes	The injection itself, and anything that completes inside the response window
USB device control	A second keyboard enumerating; unknown VID/PID or serial; device count anomalies	Spoofed identifiers, and the case where the malicious device is the only keyboard
Keystroke timing heuristics	Naive machine-speed injection	Payloads using jitter or throttled speed; also prone to false positives from macro keyboards and password managers
Physical inspection	Obvious knock-offs	Cable-form implants, which are built to be visually identical
RF monitoring	Wireless class members: Wi-Fi clones, O.MG cables, BLE-triggered implants	The wired Hak5 Ducky, which has no radio, and any implant while it is dormant

The highest-value cheap signal remains a second HID enumerating on a machine that already has a keyboard. It survives identifier spoofing, most device-control tooling can alert on it, and it does not depend on timing analysis.

Practical Controls That Work

• Screen lock policy. Aggressive inactivity locking plus a culture of locking on standing up removes the precondition the attack requires. Cheapest high-value control available.
• Windows device installation restrictions. Group Policy can block device setup classes such as keyboard, mouse, and network adapter, with an administrator override retained for legitimate changes.
• USBGuard on Linux. Allow-list by device identity, understanding its documented limits: it cannot protect a machine where the malicious device is the only keyboard, and it cannot filter keystrokes from a device it has accepted.
• MDM and EDR device control. Enforce by class, VID/PID, serial, and device count across managed fleets, starting in monitor mode to inventory what is legitimately in use.
• Elevation hardening. Requiring credentials for privilege elevation blocks payloads that need administrative rights. It does not stop user-context actions such as browser credential theft or Wi-Fi profile dumping.
• Supply chain hygiene. Issue and label corporate cables and drives, and treat conference swag, hotel-room cables, and found hardware as hostile by default.

Disabling USB ports entirely is occasionally proposed and rarely viable outside SCIF and OT contexts, because it takes keyboards, mice, docks, headsets, and badge readers with it.

Where Wireless Monitoring Fits

Bastille monitors the RF spectrum from 100 MHz to 7.125 GHz passively, detecting, classifying, and localizing transmitting devices. Applied to this device class, that means:

• Yes for devices with an active radio. A Wi-Fi Ducky clone standing up its own access point, an O.MG Cable’s Wi-Fi, or a Bash Bunny Mark II’s BLE trigger are all observable in the spectrum and can be located within a facility, including in buildings with no wireless network of their own.
• No for the wired Hak5 Rubber Ducky. It has no radio, so there is nothing to observe. Device control and endpoint telemetry own that case.
• Partial for dormant implants. Detection depends on transmission. An implant sitting idle is not an RF event, which is a real limitation and the sharpest objection practitioners raise.

That is the honest scope. RF monitoring closes a blind spot that endpoint tooling cannot reach, and it is the only layer that sees an implant operating outside the network. It is a layer, not a replacement for device control and policy. In SCIF and SAPF environments the regime is different again: device prohibition plus in-place wireless intrusion detection rather than endpoint controls.

Is This a Real Risk or a Demo Threat?

The objection worth engaging is that anyone with physical access to an unlocked machine has already won, making the device a party trick. There is something to that, and the counterargument is specific: this class collapses the required dwell time from minutes to seconds and drops the skill floor to nearly zero. That changes who can execute the attack and in which settings, which is a different risk profile even if the underlying access requirement is unchanged.

It is also fair to note that this vector is heavily represented in conference talks and training material and lightly represented in public breach disclosures. Defenders asking for incident data are asking a reasonable question. The scenario where the class is most compelling is insider and cleared-facility use: a device planted by someone with legitimate access, and, for the wireless members, operated from outside the building.

Policy, Legality, and Red Team Scoping

These devices are sold openly as penetration testing tools and are legal to own in most jurisdictions. The line is authorization: use only against systems you own or have written permission to test. Physical and social engineering engagements need explicit authorization language, named personnel, and abort procedures in the statement of work.

For governance mapping, this threat sits in the physical access control and removable media control families rather than in network security. Acceptable-use policy language that recurs in practitioner guidance is to prohibit unknown USB devices, HID composite devices, and USB-to-Ethernet adapters without written approval, and to require incident response on violation.

Frequently Asked Questions

What is a USB Rubber Ducky?

It is a keystroke injection device that looks like a flash drive but enumerates as a keyboard and types a prepared payload at machine speed. Because the operating system trusts keyboards implicitly, the payload runs without any user action beyond the device being plugged in.

Is the USB Rubber Ducky wireless?

The Hak5 USB Rubber Ducky has no radio. Inexpensive clones built on ESP8266 and ESP32 hardware do have Wi-Fi and offer live browser-based control, and they are frequently called Wi-Fi Rubber Duckies. They are a different product class, and the distinction determines whether wireless monitoring applies.

Is a Rubber Ducky the same as BadUSB?

They overlap without being identical. BadUSB refers to ordinary USB devices whose firmware has been reprogrammed to lie about what they are, while the Rubber Ducky is purpose-built hardware. Both are forms of HID spoofing and both defeat storage-focused USB policy.

Does a USB Rubber Ducky work on a locked computer?

No. Keystroke injection requires an unlocked, logged-in session. This is the most important limitation of the attack and the reason aggressive screen-lock policy is such an effective control.

Will antivirus or EDR detect keystroke injection?

Antivirus will not, because nothing is written to disk at injection time. EDR may catch what happens afterward, such as a process spawning seconds after a new HID enumerates, but detection is post-execution and the payload often finishes before anyone responds.

Why is USB device allow-listing not enough?

Because firmware can lie during enumeration, including about VID, PID, and serial number. Allow-listing raises the attacker’s cost and is worth deploying, but it does not close the vector, and it cannot help on a machine where the malicious device is the only keyboard attached.

Can a device with no radio still exfiltrate data?

Yes, slowly. Keystroke Reflection abuses lock-key LED state as a covert channel back to the device, which means data can leave an air-gapped host without any network or radio involvement. Capacity is small, but credentials are small.

How do I detect a Wi-Fi Rubber Ducky?

Through continuous passive RF monitoring. A Wi-Fi clone hosts its own access point or beacons for control, and that transmission can be detected and localized inside a facility regardless of what the host sees, including in buildings with no wireless network of their own.

Can I just disable USB ports?

Rarely, outside SCIF and OT environments. Blocking USB wholesale removes keyboards, mice, docks, headsets, and badge readers. Class-level restrictions with administrator override are the practical middle ground for general-purpose fleets.

Is it legal to own a USB Rubber Ducky?

Yes in most jurisdictions. They are sold openly as penetration testing tools, and the legal line is use without authorization. Engagements should carry written scope, named personnel, and abort procedures.

What Can I Do to Defend Against This Threat?

Bastille recommends a layered approach, because no single control covers this class:

• Lock sessions aggressively: the attack needs an unlocked machine, so short inactivity timeouts remove its precondition.
• Enforce USB device control: restrict device classes, allow-list where practical, and alert on a second keyboard enumerating.
• Implement wireless monitoring in your space: continuous passive RF monitoring detects and localizes the wireless members of this class, which endpoint controls cannot see.
• Buy from trusted vendors and issue your own hardware: label corporate cables and drives, and treat found or gifted USB hardware as hostile.
• Update and enforce your security policy: give staff one concrete instruction rather than general vigilance, and require reporting of unknown devices.
• Stay up to date: the wireless threat landscape changes quickly, and the wireless variants of this attack are where it is changing fastest.

Endpoint controls handle the wired archetype. The wireless members of this class operate outside your network entirely, and seeing them means watching the airspace. See a demo to understand what that looks like in your environment.