Founded in 2005, Hak5's mission is to advance the InfoSec industry. We do this through our award winning podcasts, leading pentest gear, and inclusive community – where all hackers belong.
January 31, 2023 5 min read
Since the beginning of Keystroke Injection attacks, dating back to the origins of DuckyScript 1.0 over a decade ago, conventional wisdom has been to always begin a payload with the simple line: DELAY 3000.
TL;DR: If you've ever plugged in a keyboard and started pressing keys until you saw them appear - this is the nearly arbitrary delay we are trying to solve for.
Simply put, the USB Rubber Ducky is capable of injecting keystrokes faster than the target is ready to accept them in a usable fashion. While the USB Rubber Ducky boots, processes, and starts running its payload almost instantly, the target must enumerate and set up the new USB HID device as necessary.
On very old computers, USB device setup could be as much as 1 to 2 seconds. Therefore, a 3000 ms delay would in the majority of cases ensure that your payload would execute more reliably across varying targets.
But what about modern, fast computers? Why wait so long? Further complicating the problem; many systems will offer up the communication channel with the USB Rubber Ducky at the protocol level before the operating system itself starts accepting usable input.
While faster, omitting a "better safe than sorry" (better slow than broken) DELAY at the beginning of the your payload can often result in an "ello, World!" rather than a "Hello, World!". For a payload as simple as the above example it may not be the end of the world; but for your 5 second Mr Robot Style hack while on an engagement — it very well could be the difference between success and a very alarm bell ringing failure.
Even going as far as to custom tailor a finely tuned boot DELAY for your payload and the exact target system you'll find that the variance between USB Rubber Ducky "boots" (or payload runs) is enough to put you right back into the ballpark of +/- 1000ms. Considering many actual flash drives take significantly longer to enumerate on some systems, we're full circle back to "Just add a DELAY 3000
" for any hope of near 100% reliability and call it a day. Until...
Because DuckyScript 3.0 includes the logic necessary to make programmatic decisions, as well as awareness of the Lock Key states (that we abuse in our Keystroke Reflection attack) we can instruct our payload to DELAY
only for as long as is necessary before reliably injecting meaningful keystrokes. That's exactly what we've done with the EXTENSION DETECT_READY
.
Simply by being added to the top of your payload, this extension waits for the defined response delay until either the state of CAPSLOCK
has been confirmed on, or the defined iteration limit has been reached. The minimum response DELAY
is set to a default of 25 ms; a value we have found to be optimized. In our testing across a broad range of systems, this is the lowest value which produces the fastest results without additional unnecessary iteration.
This means one of three things has happened before the rest of your payload runs;
CAPSLOCK
turned on - $_CAPSLOCK_ON
== TRUE being a side effect of the operating system syncing the current CAPSLOCK
state to the newly connected keyboard: the USB Rubber Ducky. While this is not a full circle confirmation like the first possible outcome, it is sufficient enough indication that the host will accept further keystrokes from the USB Rubber Ducky.DELAY 3000
We put the DETECT_READY extension to the test by adding some debugging instrumentation. In this case, by importing the TRANSLATE extension, we are able to type out how long after connection and enumeration the target took to be ready for reliable keystroke injection.
This bare metal Dell XPS 13 machine is running on modern Intel i7 hardware.
Result: 25 milliseconds! 99.17% reduction
Similarly, our Linux example is also running on the same hardware in a VM
Result: 100ms; a 96.67% reduction
How about something ancient? For this test we dusted off an old ASUS Eee PC 701 — a 2007 era netbook with a Intel Celeron CPU underclocked to 630 MHz!
Result: ~400ms; a 86.67% reduction
Mobile targets such as iOS and Android need extra attention. While the DETECT_READY
extension will only DELAY
so long as the target is not prepared to accept keystrokes, in our experience mobile devices still require extra time to close their on-screen keyboards once a physical keyboard has been recognized by the OS.
Additionally MacOS traditionally does not sync or reflect lock key states; The iteration limit built into the extension by default ensures that the payload continues after a maximum DELAY
of 3000 ms, the previously held conventional wisdom, which in experience is sufficient for most targets. The value may be increased to achieve the highest possible compatibility in the case that the target requires a very slow driver download and installation — something that may be possible when brute forcing VID and PID values. That said, this is very unlikely for most known keyboard identifiers in our experience.
By using the extension architecture of DuckyScript 3.0, all payload authors benefit from the DETECT_READY
capabilities while having the flexibility to modify it to their specific requirements.
The DETECT_READY
extension can be found from the USB Rubber Ducky payload repository at https://github.com/hak5/usbrubberducky-payloads/tree/master/payloads/extensions
To implement DETECT_READY
in your own payload, simply begin typing EXTENSION DELAY_READY
and select the auto-complete suggestion from within PayloadStudio; it will automatically include the latest version.
Placing this at the top of your payload in lieu of the traditional DELAY 3000
will produce the results mentioned above. Get ready to enjoy both faster and more reliable payload execution!
Considering that Apple operating systems are the main flavor of target that won't take advantage of the enhanced functionality provided by DETECT_READY
, why not continue to improve within the scope where it is already applicable? If you've followed along so far you might have taken note that many operating systems that do reflect lock keys also (generally) sync lock states on connection of a new keyboard. This being part of what we can consider to be the setup process, it should be both faster and entirely passive to detect ready on these systems simply by detecting the initial update of the lock states. Thus PASSIVE_DETECT_READY
is born.
We're already detecting either the first usable input, or the end of the setup process...
Conveniently, the USB Rubber Ducky also happens to implement a novel, entirely passive, driver level, Windows detection - instantly during the setup process; not only can this process reliably become EVEN FASTER on Windows targets - we can also make a very simple yet powerful OS determination at the exact same time... PASSIVE_WINDOWS_DETECT
does exactly this for you.
Authors: Dallas Winger, Darren Kitchen
Sign up to get the latest on sales, new releases and more …
Notify me when available
We will send you a notification as soon as this product is available again.
We don't share your email with anybody
Facts Only
Hak5 was founded in 2005 with a mission to advance the InfoSec industry.
The USB Rubber Ducky is a tool used for keystroke injection attacks in penetration testing.
Historically, payloads began with a `DELAY 3000` command to ensure the target system was ready to accept keystrokes.
The delay accounted for USB device enumeration times, which could take 1-2 seconds on older systems.
Modern systems often require less time, making the 3000ms delay unnecessary and inefficient.
DuckyScript 3.0 introduced the `DETECTREADY` extension to dynamically determine when the target system is ready.
The extension monitors the CAPSLOCK key state to confirm system readiness.
Testing showed delays reduced to 25ms on a Dell XPS 13, 100ms on a Linux VM, and 400ms on an ASUS Eee PC.
The extension defaults to a 3000ms delay if the system does not sync lock key states, such as macOS.
`PASSIVEDETECTREADY` and `PASSIVEWINDOWSDETECT` were developed to further optimize detection and identify the target OS.
The extensions are available in Hak5’s GitHub repository for public use.
The authors of the article are Dallas Winger and Darren Kitchen.
Executive Summary
Hak5, an InfoSec company founded in 2005, has developed a new approach to keystroke injection attacks using the USB Rubber Ducky, a tool designed to automate keyboard inputs for penetration testing. Historically, payloads required a 3000-millisecond delay to ensure the target system was ready to accept keystrokes, accounting for variability in USB device enumeration times across different hardware. However, this delay was often excessive for modern systems, leading to inefficiencies. With the introduction of DuckyScript 3.0, Hak5 has created the `DETECTREADY` extension, which dynamically waits for the target system to be ready by monitoring the CAPSLOCK key state, reducing delays by up to 99% on fast systems while maintaining reliability. Testing across various platforms—including a modern Dell XPS 13 (25ms), a Linux VM (100ms), and an older ASUS Eee PC (400ms)—demonstrated significant performance improvements. The extension also includes a fallback to the traditional 3000ms delay for systems like macOS, which do not sync lock key states. Additionally, Hak5 introduced `PASSIVEDETECTREADY` and `PASSIVEWINDOWSDETECT` to further optimize detection and even identify the target operating system during setup. These advancements aim to balance speed and reliability in keystroke injection attacks, benefiting penetration testers and security researchers.
The solution addresses a long-standing challenge in the field, offering a more adaptive and efficient method for payload execution. While the improvements are substantial, the approach still relies on certain assumptions about system behavior, particularly regarding lock key synchronization, which may not hold true for all devices. The extensions are available in Hak5’s public repository, allowing payload authors to integrate them into their workflows.
Full Take
This analysis from Hak5 presents a technical advancement in keystroke injection attacks, addressing a long-standing inefficiency in the field. The strongest version of this narrative is that it offers a data-driven solution to a real-world problem: the arbitrary 3000ms delay in USB Rubber Ducky payloads. By leveraging the CAPSLOCK key state as a proxy for system readiness, the `DETECTREADY` extension reduces unnecessary waiting while maintaining reliability. The testing results across different hardware platforms provide credible evidence of its effectiveness, and the inclusion of fallback mechanisms for non-compliant systems (like macOS) demonstrates thoughtful engineering. The narrative aligns with Hak5’s mission of advancing InfoSec through innovation and community collaboration.
However, the analysis assumes that lock key synchronization is a universal indicator of system readiness, which may not hold true for all devices or configurations. The reliance on CAPSLOCK as a signal could introduce edge cases where the detection fails, particularly on systems with non-standard USB HID implementations or custom security policies. Additionally, while the solution is framed as a significant improvement, it still operates within the constraints of keystroke injection attacks—a method that inherently relies on exploiting trust in USB HID devices. The broader implication is that as defensive measures evolve, so too must offensive tools, creating an ongoing arms race in cybersecurity.
The paradigm driving this narrative is one of optimization within a well-established attack vector. The unstated assumption is that faster, more reliable payload execution is inherently valuable for penetration testers, but this could also lower the barrier for malicious actors. The historical pattern here echoes the cyclical nature of cybersecurity: as defenses improve, attackers refine their methods, and vice versa. For human agency, this means that while tools like the USB Rubber Ducky can be used for legitimate security testing, they also pose risks if misused. The second-order consequences include potential increases in the speed and stealth of attacks, which could outpace defensive adaptations.
Bridge questions to consider: How might defensive systems adapt to detect or mitigate dynamic delay techniques like `DETECTREADY`? What alternative indicators of system readiness could be explored to reduce false negatives? Would the adoption of this method shift the balance of power in favor of attackers or defenders in real-world scenarios?
Counterstrike scan: If this narrative were part of a coordinated influence campaign, the playbook might involve framing the advancement as a "game-changer" to encourage widespread adoption among both ethical and unethical actors, potentially increasing the attack surface for organizations. However, the content itself is technical and transparent, focusing on solving a specific problem rather than sensationalizing its impact. The inclusion of limitations (e.g., macOS compatibility) and the open-source availability of the tool suggest a genuine effort to improve the field rather than manipulate it. No structural alignment with a malicious playbook is detected.