HID Injection: Why Your Computer Trusts Any Keyboard You Plug In
Table of Contents
- The Trust Model
- Why It Was a Reasonable Design (And Why It Isn't Now)
- USB HID Injection
- Bluetooth HID Injection
- What HID Injection Can Do
- Speed: Faster Than You Can React
- Why Antivirus Doesn't Help
- Defenses That Actually Work
- Defenses That Don't Work
- How BLEShark Nano Implements This
- Bad-BT vs. Rubber Ducky vs. Flipper Zero HID
The Trust Model
When you plug a keyboard into a USB port, your OS asks the device one question: "What are you?" The device responds: "I'm a keyboard." The OS says "great," loads a driver, and from that point forward, everything that device sends is treated as keyboard input. No verification. No confirmation dialog. No authentication at any step.
This is the HID trust model. It's the same over Bluetooth: a device that advertises as a keyboard and completes pairing gets full, unsandboxed keyboard access. The protocol assumes that physical presence (plugging in) or pairing acceptance (Bluetooth) is sufficient authorization. Anything claiming to be a keyboard is trusted as a keyboard, immediately and completely.
HID injection attacks are entirely built on this assumption. There is no bug to patch in the traditional sense. The vulnerability is the design itself: the system works exactly as specified, and the specification has no authentication.
Why It Was a Reasonable Design (And Why It Isn't Now)
The USB HID specification was finalized in the late 1990s. At the time, the design philosophy was plug-and-play: devices should work immediately without requiring users to install drivers, enter codes, or configure anything. Keyboards especially - if your keyboard doesn't work, you can't type the configuration it needs to work.
There were also accessibility reasons. Screen readers, adaptive input devices, and assistive technologies all depend on being able to connect as HID devices and deliver input. Adding authentication requirements would create barriers for legitimate accessibility tools that often run without user interaction.
Hardware compatibility was another factor. In the late 1990s, the variety of USB-capable embedded systems was limited. Authentication protocols require computation; the microcontrollers used in keyboards at the time weren't built for it.
These were reasonable tradeoffs in 1998. The threat model didn't include cheap programmable microcontrollers that could enumerate as a keyboard and send arbitrary keystrokes. That hardware cost thousands of dollars and required significant expertise. Today, a microcontroller capable of acting as a USB HID keyboard costs under $3 and takes ten minutes to program.
The design decision hasn't changed. The threat environment has.
sequenceDiagram
participant DEV as HID Device
participant USB as USB Bus
participant OS as OS Kernel
participant UI as User Space
DEV->>USB: USB Connect (5V power)
USB->>OS: Device attached interrupt
OS->>DEV: GET_DESCRIPTOR (Device)
DEV->>OS: Device Descriptor: class=0x03 (HID)
OS->>DEV: GET_DESCRIPTOR (HID Report)
DEV->>OS: Report Descriptor: keyboard layout
Note over OS: Auto-loads HID driver
No authentication
No user prompt
OS->>UI: New keyboard ready
DEV->>OS: HID Report: Win+R
OS->>UI: Opens Run dialog
DEV->>OS: HID Report: "powershell -e ..."
OS->>UI: Typed at 1000+ chars/sec
DEV->>OS: HID Report: Enter
Note over UI: Payload executes with
current user privileges
USB HID injection attack sequence - the OS automatically trusts any device claiming to be a keyboard, with no authentication or user confirmation required
USB HID Injection
The USB Rubber Ducky (from Hak5) is the device most associated with USB HID injection. The concept is simple: a device the size of a USB thumb drive plugs into a computer and enumerates as a HID keyboard. The OS loads its class driver with no user interaction. The device then sends a pre-programmed sequence of keystrokes.
The OS sees an entirely normal keyboard connection. There's no pop-up asking if you trust this device. There's no warning that a new keyboard was connected. On Windows, you might see a brief taskbar notification about a new device, but it's easy to miss and contains no security information.
From the moment the Rubber Ducky is plugged in to the moment it finishes sending its payload is typically 2-10 seconds. The keystrokes execute at machine speed - far faster than a human typist. The operator doesn't need to be present during execution. They plug in the device, walk away, and retrieve it after the payload runs.
Payloads can do anything a keyboard can do. And a keyboard can do a lot: open a terminal with administrator privileges, type and execute shell commands, download files from the internet, disable security software, create persistent backdoors, exfiltrate data. The keyboard shortcut to open a command prompt is public knowledge. Everything after that is just typing.
Bluetooth HID Injection
Bad-BT is the Bluetooth version of the same attack. Instead of a USB device requiring physical contact with the port, a BLE-capable device advertises as a Bluetooth keyboard, completes pairing via Just Works (no PIN required), and then injects keystrokes over BLE at ranges of 10-30 meters.
Just Works is a Bluetooth pairing mode designed for devices with no user interface - speakers, headphones, accessories that can't display a PIN or prompt for confirmation. When two devices pair using Just Works, the connection completes without any PIN or passkey. From the target computer's perspective, a keyboard appeared and wanted to pair. From the OS's perspective, pairing happened and a keyboard is now connected. Trusting it is automatic.
The wireless range changes everything about the attack scenario. Physical access to the target machine is not required. An attacker on the other side of a glass wall, in an adjacent room, or at the far end of a conference room can execute a payload on an unlocked workstation. No device left behind. No physical trace.
What HID Injection Can Do
The right question is: what can't it do? If a keyboard can do it, HID injection can do it.
Practically speaking, common payload objectives include: opening a terminal (Win+R, cmd.exe, PowerShell, gnome-terminal), running commands (download a file, execute it, establish a reverse shell), elevating privileges (triggering UAC prompts on Windows, using sudo on Linux/macOS), disabling security software, installing persistence (startup entries, scheduled tasks, cron jobs), exfiltrating data (copy files to a web endpoint, upload credentials), and modifying system configuration.
More targeted payloads can be remarkably specific: extract saved browser passwords and POST them to a remote server, enumerate network shares and map them, install a keylogger, add an SSH key to authorized_keys, create a new admin user, or disable Windows Defender. All of this is "just typing" from the OS's perspective.
The only limit is what the OS allows at the current privilege level. An HID injection payload running against an unlocked, administrator-level session has essentially no limits. Against a standard user session, some actions require privilege escalation - but social engineering via HID (typing a UAC prompt response, for example) can sometimes bridge that gap.
Speed: Faster Than You Can React
A competent HID injection payload completes in 2-5 seconds. The bottleneck isn't the injection speed - it's waiting for applications to open.
Opening PowerShell: about 500-800ms on a warm machine. Running a download-and-execute one-liner: a few hundred milliseconds to type it, then whatever the download and execution time is. The entire input sequence might be 20-30 keystrokes. At machine speed, that's under 100ms of actual typing, with delays added to wait for the OS to catch up.
The human reaction time to visual input is around 200-250ms. By the time you notice something unusual, the payload has already started. By the time you reach for the mouse to close whatever opened, it's done. Auto-locking a screen doesn't help if the screen was unlocked when the attack started.
This speed also makes manual detection difficult. If someone glances at your screen during a 3-second payload execution, they might see a terminal window flash open and close. That's often the only visible indicator, and it's easy to dismiss as a system process.
Why Antivirus Doesn't Help
Antivirus works by scanning files and processes for known malicious signatures, or by monitoring process behavior for suspicious patterns. HID injection operates before any of that.
The keystrokes arrive at the OS through the normal input pipeline - the same path used by a legitimate keyboard. Antivirus doesn't monitor the HID input layer. The keystrokes look identical to user input. There's no binary file to scan, no network connection to inspect, no process anomaly to flag.
The first moment antivirus has anything to analyze is when the payload causes a process to run - opening PowerShell, for example, or downloading a file. At that point, if the payload downloads a known malware binary, AV might catch it. But the injection itself is invisible to AV. And a payload that only uses built-in OS tools (PowerShell, cmd, bash, certutil, curl) won't trigger signature-based detection at all. These are legitimate system tools doing legitimate-looking things.
Behavior-based detection is better but still limited. Antivirus and EDR tools are trained on human behavior. A human who opens PowerShell and types commands does so at human speed, with pauses and corrections. An HID injection payload types at machine speed in a perfect sequence with no corrections. Some EDR products now specifically watch for "superhuman typing speed" as an anomaly indicator, but this detection is narrow and easy to evade with deliberate timing delays.
Defenses That Actually Work
OS-level device installation restrictions: Windows Group Policy can restrict which USB device classes are allowed to install. Specifically, blocking HID keyboard devices via device installation class GUID prevents USB HID keyboards from being recognized - though this also blocks legitimate keyboards, so it's typically combined with an allowlist of known-good device identifiers.
MDM managed device policies: For Bluetooth, MDM platforms (Jamf, Intune, Mosyle, etc.) can enforce Bluetooth pairing policies that require secure authentication modes, block Just Works pairing, or disable Bluetooth entirely. These are the most practical controls for enterprise environments managing a fleet of devices.
Endpoint detection for anomalous keystroke patterns: Some EDR products detect HID injection via behavioral analysis - specifically looking for high-speed keystroke sequences, keyboard shortcut patterns that commonly precede command execution, or typing that occurs when no legitimate user is logged in.
Physical USB port blocking: Hardware port blockers physically prevent USB devices from being inserted. Unlike software restrictions, they can't be bypassed via software. Practical in fixed workstations in sensitive areas.
Bluetooth pairing policies: Requiring user confirmation and PIN authentication for all Bluetooth pairing events, and training users to decline unexpected pairing requests, significantly raises the bar for Bluetooth HID injection.
Aggressive auto-lock timers: HID injection requires an unlocked session. A 30-60 second auto-lock means the window of opportunity is narrow. An attacker needs to be ready to trigger the attack the moment they have line-of-sight to an unlocked machine.
Defenses That Don't Work
USB port covers: These are physical plastic covers that fit over USB ports. They're not locked - anyone can remove them in a few seconds. They provide a minor deterrent but not actual security against a motivated attacker.
Disabling USB in BIOS: This works for the USB injection threat, but it also breaks legitimate USB peripherals, which is why it's rarely deployable in practice. Organizations that try this approach typically end up with exceptions for keyboards and mice - which defeats the purpose, since HID keyboards are exactly what you're trying to block.
Trusting employees not to pair with unknown Bluetooth devices: People accept Bluetooth pairing requests. They do it without thinking. A popup that says "Would you like to pair with Keyboard 43A7?" during a busy workday looks routine. User-dependent security measures against social engineering require perfect behavior from everyone, always. That's not a realistic baseline.
Endpoint AV scanning HID input: Antivirus doesn't operate at the HID layer and cannot detect HID injection at the input stage. Expecting AV to catch this is misunderstanding where the attack surface is.
How BLEShark Nano Implements This
The BLEShark Nano's Bad-BT feature implements wireless HID injection using BLE. It advertises as a BLE keyboard using the HOGP (HID Over GATT Protocol), pairs with the target via Just Works pairing, and then delivers keystrokes encoded as HID reports over the BLE connection.
Payloads are written in DuckyScript - a scripting language designed for HID injection. Commands like GUI r (press Windows key + R), STRING powershell -ep bypass (type that string), and ENTER (press Enter) map to sequences of HID reports. The BLEShark Nano's firmware translates DuckyScript commands to HID report byte sequences and sends them over BLE.
The on-device DuckyScript editor is a significant operational advantage. With other HID injection tools, modifying a payload requires connecting the device to a computer, editing the script file, and reflashing or reloading it. With BLEShark Nano, the entire workflow happens on-device. Write the script, save it, trigger it - no laptop required. This matters when editing a payload on a laptop in a target environment would be conspicuous.
Variable keystroke timing is also configurable. Payloads that type at irregular intervals with randomized delays between keystrokes are harder for rate-based behavioral detection to identify as scripted input. The BLEShark Nano supports timing parameters in DuckyScript (via DELAY commands) to tune the payload's timing signature.
Bad-BT vs. Rubber Ducky vs. Flipper Zero HID
These three tools accomplish similar goals via different approaches. Understanding the tradeoffs matters for choosing the right tool for a given assessment scenario.
USB Rubber Ducky: The original HID injection tool. Requires physical USB port access - attacker must plug the device into the target machine. Payloads are loaded via SD card, requiring a separate workflow to modify scripts. No wireless capability. Extremely reliable on any USB-capable machine. Best for scenarios with guaranteed physical access.
Flipper Zero HID: The Flipper Zero can emulate a USB HID keyboard when connected via USB, and has limited Bluetooth HID capability. Payload editing requires the Flipper desktop software - you write scripts on a computer and transfer them to the Flipper. The Flipper has a physical interface for triggering payloads. Good as a multipurpose research tool; the HID module is one capability among many.
BLEShark Nano Bad-BT: Wireless BLE delivery means no physical port access required. Range of 10-30 meters. On-device DuckyScript editor eliminates the laptop-in-the-field workflow. The device is designed specifically for wireless HID injection research, so the interface and payload management are optimized for that use case. No cable, no direct contact with target machine, no upload cycle for script changes.
For assessments where physical access to USB ports is available and the target is known, a Rubber Ducky is simple and reliable. For wireless scenarios, for environments where physical contact with the machine would be noticed, or for fieldwork where on-the-fly script editing matters, the BLEShark Nano's Bad-BT implementation addresses those constraints directly.
BLEShark Nano is designed for authorized security research, penetration testing, and educational use. Always obtain proper authorization before testing HID injection techniques on systems or networks you do not own.