Draft:USB Rubber Ducky
Submission declined on 4 June 2026 by Helpful Raccoon (talk).
Where to get help
How to improve a draft
You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Editor resources
|  |
Comment: Please rewrite from scratch without the use of LLMs. Helpful Raccoon (talk) 05:12, 4 June 2026 (UTC)
 | |
| Type | Computer security hardware, USB HID keystroke-injection tool |
|---|---|
| Manufacturer | Hak5 |
| Website | shop |
The USB Rubber Ducky is a programmable USB keystroke-injection device developed by Hak5, a company known for producing cybersecurity and penetration-testing hardware. Although the device is designed to resemble a common USB flash drive, a computer typically identifies it as a Human Interface Device keyboard. Once connected, it can automatically send prewritten keyboard input to the host system at high speed.
Hak5 describes the USB Rubber Ducky as a device that appears to humans like an ordinary USB flash drive but appears to computers as a keyboard.[1] The product is widely associated with the concept of keystroke injection, in which a device or program automatically enters keyboard input rather than relying on a human typist. Hak5 states that it introduced keystroke injection with the USB Rubber Ducky in 2010 and that the original concept was developed by Darren Kitchen for automating routine information-technology tasks.[2]
The device uses a scripting language known as DuckyScript, which allows users to define keyboard actions, pauses, and other automation behavior. Earlier versions of DuckyScript focused on simple keystrokes and delays, while later versions added more advanced programming features.[3] The current generation of the USB Rubber Ducky is marketed by Hak5 as supporting DuckyScript 3.0.[1]
The USB Rubber Ducky is considered a dual-use cybersecurity tool. It is used by penetration testers, red teams, educators, and security researchers to demonstrate weaknesses in endpoint security and physical-access controls. It can also be misused if deployed without authorization. Because the device emulates trusted keyboard input, it is often discussed alongside BadUSB and other attacks involving deceptive or malicious USB devices.[4]
Overview
[edit]A USB Rubber Ducky is not primarily a conventional removable-storage device. Its main function is to emulate a keyboard and send scripted input to a computer. When the device is inserted into a USB port, the host operating system may enumerate it as a USB keyboard. Most operating systems trust keyboards by default because keyboard input is necessary for ordinary computer use.
This trust relationship is central to the device's security significance. A computer that would normally block unknown executable files from a USB drive may still accept input from a newly connected keyboard. As a result, a keystroke-injection device can interact with the operating system, applications, and graphical user interface as though a person were typing.
In authorized testing, the USB Rubber Ducky may be used to evaluate whether computers are vulnerable to attacks involving unknown USB peripherals. It may also be used to demonstrate the importance of locking unattended workstations, limiting local administrative privileges, monitoring new device connections, and controlling physical access to systems.
History
[edit]Hak5 traces the origin of the USB Rubber Ducky to 2010, when Darren Kitchen developed the technique as a way to automate repetitive IT tasks, including configuration actions that would otherwise require manual keyboard input.[2] The first generation of the device became popular in hacker and penetration-testing communities because it made keystroke-injection attacks easy to demonstrate.
The USB Rubber Ducky gained additional attention during wider public discussion of USB security in the early 2010s. In 2014, researchers Karsten Nohl, Sascha Krißler, and Jakob Lell presented research on what became known as BadUSB. Their work showed that USB device firmware and device identity could be abused in ways that were difficult for ordinary users and antivirus tools to detect.[4] Wired reported that BadUSB-style attacks could allow a USB device to impersonate a keyboard and type commands on a victim's machine.[5]
Although the USB Rubber Ducky is a specific commercial product rather than the same thing as all BadUSB attacks, it is commonly discussed in relation to BadUSB because both involve USB devices presenting themselves to computers in ways that can be abused. In the Rubber Ducky's case, the relevant behavior is keyboard emulation. In broader BadUSB research, the issue may involve reprogrammed firmware, deceptive device classes, or other forms of malicious USB behavior.
Hak5 later released a newer generation of the USB Rubber Ducky with support for DuckyScript 3.0. Hak5's documentation states that DuckyScript 1.0 payloads remain compatible with DuckyScript 3.0 on supported devices, excluding device-specific functionality.[3]
Design
[edit]The USB Rubber Ducky is designed to exploit the normal way computers interact with USB Human Interface Devices. USB keyboards are generally permitted to send input soon after being connected. This behavior is useful for legitimate peripherals, but it can also be abused by devices that send automated keystrokes.
The device stores or receives instructions written in DuckyScript. These instructions describe the sequence of keyboard events to be generated. Depending on the device generation and script features, the payload may include delays, key combinations, text entry, conditional logic, and other automation features.[3]
From the user's perspective, the device may resemble a flash drive. From the computer's perspective, it may appear as a keyboard or as a composite USB device, depending on configuration and model. This mismatch between physical appearance and logical behavior is a recurring theme in USB security research.
DuckyScript
[edit]DuckyScript is the scripting language used to define USB Rubber Ducky payloads. Hak5 describes DuckyScript as both the programming language and source-code format for USB Rubber Ducky payloads.[6]
The first version of DuckyScript was designed to be simple and readable. It primarily represented keystrokes and delays. This made it accessible to users who wanted to automate keyboard input without writing low-level firmware code.
Later versions expanded the language. Hak5's documentation for DuckyScript 3.0 describes features including variables, logic, extensions, and multiple attack modes.[7][8] These additions made the language more flexible for authorized testing and automation.
DuckyScript also influenced other USB HID-emulation tools. Some projects and devices support DuckyScript or DuckyScript-like syntax because it became a common format for describing keystroke-injection behavior. The Spacehuhn BadUSB documentation, for example, describes its scripting as compatible with Ducky Script.[9]
Relationship to BadUSB
[edit]The USB Rubber Ducky is often associated with BadUSB, but the two terms are not identical. BadUSB refers more generally to attacks in which USB devices behave maliciously or deceptively, often by abusing firmware, USB device classes, or host trust assumptions. The USB Rubber Ducky is a specific keystroke-injection device that intentionally presents as a keyboard for automation and testing.
The common connection is the USB trust model. USB devices can present themselves as many different types of devices, including keyboards, mice, storage devices, network adapters, and other composite devices. A device that appears physically to the computer as one thing can actually act logically as another. This flexibility is useful, but it creates risks when a host computer accepts the device's declared identity without verification of its actual function.
BadUSB research brought wider attention to the fact that malicious behavior may exist below the file-system level. Wired reported in 2014 that BadUSB malware could exist in USB device firmware, making it difficult for traditional antivirus tools to detect or remove.[4] Later reporting noted that researchers found the problem affected many, but not all, USB controller chips, and that ordinary consumers could not easily determine whether a given device was vulnerable.[5]
Uses
[edit]The USB Rubber Ducky is used in several areas of cybersecurity.
Penetration testing
[edit]In penetration testing, the device may be used to assess whether an organization's endpoint controls can resist unauthorized USB peripherals. A tester may use the device to demonstrate the risks of unlocked workstations, overly permissive user privileges, weak endpoint monitoring, or inadequate physical security. Such testing should occur only with explicit authorization and within a defined scope.
Red teaming
[edit]In red-team exercises, the USB Rubber Ducky can be used to simulate adversarial behavior involving physical access or social engineering. For example, a red team may test whether employees plug in unknown USB devices or whether systems detect newly connected HID peripherals. Red-team use is generally intended to evaluate people, processes, and technology under realistic conditions.
Security education
[edit]The device is also used as a teaching tool. It provides a simple demonstration that a computer can be attacked through trusted input channels rather than through a conventional malicious file. This makes it useful for explaining the importance of workstation locking, user awareness, device control, and least-privilege access.
Research
[edit]Researchers have used Rubber Ducky-style devices and other HID-emulation tools to study detection and forensic methods. A 2021 paper in Forensic Science International: Digital Investigation examined memory forensics of USB attack platforms, including the Rubber Ducky and Bash Bunny, and presented methods for detecting such devices in Windows 10 memory dumps.[10]
A 2023 arXiv paper proposed detecting BadUSB keystroke-injection attacks by correlating speed-related indicators, plug-and-play device events, driver loading, and suspicious process activity.[11] A 2026 arXiv paper studied keystroke dynamics for distinguishing human typing from automated HID injection while using timing features rather than the content of the typed input.[12]
Security risks
[edit]The main security risk of a Rubber Ducky-style device is that it can cause a computer to perform actions using the privileges of the currently active user. If a workstation is unlocked, the device can interact with the system as though the user were typing. If the user has administrative privileges or access to sensitive applications, the potential impact is greater.
Another risk is speed. A scripted device can enter keyboard input much faster than a human typist. This may make it difficult for a user to notice and interrupt the action after the device has been connected. Researchers and security vendors commonly describe HID-injection attacks as relying on the fact that computers accept keyboard input as trusted human interaction.[12]
Traditional file-based defenses may not be sufficient against keystroke injection. Antivirus tools and removable-media scanning focus primarily on files, but a HID-injection device may not need to store or execute a malicious file from the USB device. Instead, it uses the host's normal input path.
The risk is increased by social engineering. Attackers may disguise malicious USB devices as ordinary flash drives, leave them in public locations, or otherwise encourage users to plug them into computers. Even when a device is not technically advanced, curiosity and weak physical-security practices can make USB-based attacks effective.
Defensive measures
[edit]Defenses against USB Rubber Ducky-style attacks usually combine policy, technical controls, and user training. Common measures include locking unattended workstations, limiting local administrative privileges, disabling or restricting unauthorized USB devices, monitoring new HID device connections, and training users not to connect unknown USB hardware.
Endpoint device-control software can restrict which USB device classes or device identifiers are allowed. Some organizations block new USB keyboards by default or require approval before a newly connected HID device can send input. These controls can reduce risk but may also affect usability, especially in environments where legitimate peripherals are frequently changed.
Monitoring can also help. Security teams may watch for events such as a new keyboard connection followed immediately by rapid command execution, unusual process launches, or suspicious use of administrative tools. Forensic research has proposed correlating USB plug-and-play events with process activity and typing-speed anomalies.[11]
NIST has warned that portable USB media can introduce cybersecurity risks, especially in operational technology environments, and recommends reducing those risks through physical and logical controls over the access, storage, and use of USB devices.[13] Although this guidance is broader than the USB Rubber Ducky, it reflects the same general concern that portable USB hardware can bypass assumptions made by ordinary endpoint security.
Limitations
[edit]The USB Rubber Ducky is not effective in every environment. It often depends on the target computer being unlocked, accepting new USB keyboards, using an expected keyboard layout, and responding predictably to scripted input. Different operating systems, language settings, security prompts, application states, and endpoint controls can interfere with a scripted sequence.
Security controls can also reduce the device's effectiveness. Application allowlisting, restricted user privileges, device-control policies, endpoint detection and response tools, and physical-access controls can all limit the impact of keystroke-injection attempts.
Automated input may also be detectable. Keystroke timing, device-enumeration events, and rapid process creation can provide indicators that a host is receiving machine-generated keyboard input rather than ordinary human typing.[12]
Legal and ethical issues
[edit]The USB Rubber Ducky is a dual-use tool. It can be used for legitimate security testing, but unauthorized use may violate computer-crime laws, workplace rules, privacy obligations, and contractual agreements. Professional use normally requires written permission, a defined scope, and clear rules of engagement.
Responsible use generally avoids testing on systems without consent. Even a demonstration intended to be harmless can cause disruption, data exposure, or policy violations if performed on a system without authorization. For this reason, security educators and researchers often emphasize the principles of USB trust, endpoint defense, and physical security rather than publishing instructions for unauthorized compromise.
Cultural impact
[edit]The USB Rubber Ducky became a recognizable object in hacker culture because it illustrates a complex security issue in a simple form. A device that looks like a flash drive but behaves as a keyboard demonstrates the problem of trusting peripherals based on appearance. The product's name also made it memorable, although it is separate from the programming practice known as rubber duck debugging.
Hak5 maintains an official community payload repository for the USB Rubber Ducky. The repository contains payloads, extensions, and language files for the device.[14] This community ecosystem contributed to the wider adoption of DuckyScript-like syntax in other HID-emulation projects.
Terminology
[edit]The term USB Rubber Ducky properly refers to Hak5's commercial product. The phrase Rubber Ducky attack is often used more generally to describe keystroke-injection attacks performed by USB devices that imitate keyboards. BadUSB is a broader term for attacks involving malicious or deceptive USB device behavior, including but not limited to keyboard emulation.
Keystroke injection refers to automated keyboard input generated by a device or script. HID refers to the Human Interface Device class of USB peripherals, which includes keyboards and mice. DuckyScript is the scripting language associated with USB Rubber Ducky payloads.
See also
[edit]References
[edit]- 1 2 "USB Rubber Ducky". Hak5. Retrieved 3 June 2026.
- 1 2 "USB Rubber Ducky by Hak5". Hak5 Docs. Retrieved 3 June 2026.
- 1 2 3 "DuckyScript Quick Reference". Hak5 Docs. Retrieved 3 June 2026.
- 1 2 3 Greenberg, Andy (31 July 2014). "Why the Security of USB Is Fundamentally Broken". Wired. Retrieved 3 June 2026.
- 1 2 Greenberg, Andy (12 November 2014). "Only Half of USB Devices Have an Unpatchable Flaw, But No One Knows Which Half". Wired. Retrieved 3 June 2026.
- ↑ "Hello, World!". Hak5 Docs. Retrieved 3 June 2026.
- ↑ "Variables". Hak5 Docs. Retrieved 3 June 2026.
- ↑ "Extensions". Hak5 Docs. Retrieved 3 June 2026.
- ↑ "BadUSB scripting". Spacehuhn Docs. Retrieved 3 June 2026.
- ↑ Thomas, T. (2021). "Duck Hunt: Memory forensics of USB attack platforms". Forensic Science International: Digital Investigation. 39. doi:10.1016/j.fsidi.2021.301306. Retrieved 3 June 2026.
- 1 2 Karantzas, George (2023). "Forensic Log Based Detection For Keystroke Injection "BadUsb" Attacks". arXiv:2302.04541 [cs.CR].
- 1 2 3 Lotto, Alessandro; Marchiori, Francesco; Conti, Mauro (2026). "QUACK! Making the (Rubber) Ducky Talk: A Systematic Study of Keystroke Dynamics for HID Injection Detection". arXiv:2604.15845 [cs.CR].
- ↑ "Cyber Risks of Portable Storage Media in OT Environments". NIST Computer Security Resource Center. 2025. Retrieved 3 June 2026.
- ↑ "Payload Library for the USB Rubber Ducky by Hak5". GitHub. Hak5. Retrieved 3 June 2026.
External links
[edit]Category:Computer security hardware
Category:Computer security exploits
Please delete the portions which were LLM-generated, and summarize in your own words a range of independent, reliable, published sources that discuss the subject. If you have used an LLM but you believe that your use is covered by one of the two exceptions (basic copyediting and translation between two languages in which you are fully fluent), please provide a transcript of the prompt(s) you used while writing your draft (see the how-to guide). Reviewers can make mistakes. If you have not received any LLM assistance, you may seek a second opinion at the AfC Help Desk.
See the advice page on large language models for more information.