USB Rubber Ducky Detection Patterns

USB Rubber Ducky detection cannot rely on blocking USB storage, because the device is not storage — it registers as a HID keyboard and types. Antivirus sees nothing, because there is no malicious file, only keystrokes. The detectable pattern is behavioral: a new keyboard enumerates and, within a second or two, a Run dialog or PowerShell launches and types faster than any human. This guide ships the Sigma rules for that pattern and the layered hardening that blocks the payload even when the keystrokes land.

A Rubber Ducky (or any BadUSB device — Bash Bunny, a malicious cable, a Flipper Zero in BadUSB mode) is a hardware addition: MITRE ATT&CK T1200 — Hardware Additions, with the injected commands mapping to T1059.001 — PowerShell.

What is a USB Rubber Ducky attack?

A USB Rubber Ducky is a keystroke-injection tool shaped like a flash drive. When plugged in, it announces itself to the operating system as a keyboard and “types” a pre-programmed payload at machine speed — opening a Run dialog, launching PowerShell, and executing commands in the few seconds it takes to walk past an unlocked machine. Because the OS trusts keyboards implicitly, there is no permission prompt.

This is why it defeats the obvious controls. Blocking USB storage does nothing to a keyboard. Antivirus has no file to scan. The attack is the typing, so the defense has to model the typing — and what it spawns, the same way command injection detection watches what a process spawns rather than the input string alone.

What does a HID-injection attack look like in telemetry?

The defining fingerprint is timing and sequence: a keyboard appears and a scripting host runs almost immediately. No human plugs in a keyboard and launches PowerShell in under two seconds.

How to detect USB Rubber Ducky / HID injection

The detection chains a new HID keyboard to the process activity that follows it within seconds.

title: New HID Keyboard Attached Then Rapid Script-Host Launch
id: 2b8f4d61-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  category: process_creation
detection:
  trigger:
    ParentImage|endswith: '\explorer.exe'
    Image|endswith: ['\powershell.exe','\cmd.exe','\wscript.exe','\mshta.exe']
  timeframe: 5s
  condition: trigger
falsepositives:
  - Power users launching shells from Explorer (correlate with a HID device-add event)
level: medium

Correlate that with the device-arrival event for high fidelity — a HID keyboard enumerating (Windows Event ID 6416 / DriverFrameworks-UserMode, or your EDR’s device-add telemetry) seconds before the shell launch.

title: Suspicious Run-Dialog Activity After HID Device Add
id: 9e3a1c75-darkpwn-illustrative
status: experimental
logsource:
  product: windows
  service: security
detection:
  device_add:
    EventID: 6416
    ClassName: 'Keyboard'
  condition: device_add
falsepositives:
  - Genuinely new keyboards/KVMs (allowlist known device instance IDs)
level: low

How to test your HID-injection detection

On a lab machine you own:

1. Use an authorized keystroke-injection device (or a scripted HID emulator) to run a benign payload that just opens a Run dialog and echoes text.
2. Confirm the device-add and rapid-script-host rules both fire and correlate.
3. Confirm application allowlisting blocks an actual payload (e.g., a script the keystrokes try to run).
4. Replay a real human plugging in a keyboard and using PowerShell to confirm the timing window keeps false positives low.

How to prevent HID injection

• Block new HID devices by default on high-value endpoints; allowlist known keyboard instance IDs.
• Auto-lock on idle and enforce short lock timeouts — most Ducky attacks need an unlocked, unattended machine.
• Restrict mshta, wscript, and unsigned scripts so common payloads fail.

Common HID-injection detection mistakes

• Relying on USB storage blocks. The Ducky is a keyboard; storage policy is irrelevant.
• Expecting antivirus to catch it. There is no file — only keystrokes.
• No device-add telemetry. Without it, you lose the highest-fidelity correlation.
• Ignoring screen-lock policy. The attack usually needs an unattended unlocked session.

USB Rubber Ducky detection checklist

1. Collect HID device-add telemetry (Event ID 6416 / EDR device events).
2. Deploy the new-keyboard-then-rapid-script-host correlation in the SIEM.
3. Allowlist known keyboard/KVM device instance IDs; alert on new HID keyboards.
4. Enforce USB device control that blocks new HID devices by default on key endpoints.
5. Deploy application allowlisting (AppLocker/WDAC) to block payload execution.
6. Use constrained-language PowerShell; disable the Run dialog via GPO.
7. Restrict mshta/wscript/unsigned scripts.
8. Enforce short auto-lock timeouts; test the detection in a lab.

The takeaway

USB Rubber Ducky detection is behavioral, not signature-based: a HID keyboard enumerates and a script host launches faster than a human could type. Detect that correlation, and layer USB device control with application allowlisting so the payload fails even when the keystrokes succeed. The same HID-injection threat at firmware scale is BadUSB — controls for engineering teams. Continue with Flipper Zero NFC risk and WiFi deauthentication detection, or browse the full Hardware Security pillar.