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

Which USB telemetry actually exists?

The correlation above depends on a device-arrival event, and on a default Windows install that event is not being recorded. This is the step that quietly makes the whole detection theoretical.

Enable Audit PnP Activity first. Without Event ID 6416 you have the second half of the correlation and not the first, which reduces a high-fidelity chained detection to a generic “a shell launched from Explorer” rule that fires constantly on developer workstations. That is the version most teams end up disabling, and they conclude the detection does not work when what failed was the telemetry.

The registry and SetupAPI sources are worth knowing separately. They are not alerting sources — they are what you interrogate on a host after the fact, and they persist long after the event log has rolled. During an investigation they answer “what has ever been plugged into this machine,” which is frequently the question that matters.

What a correct correlation actually looks like

Read the first rule above carefully and you will notice it carries a timeframe: 5s while selecting on a single condition. That is not a correlation — a timeframe is only meaningful alongside a count or a second event to join against, and a Sigma rule with one selection and a timeframe fires exactly as though the timeframe were absent.

The correlation has to happen somewhere, and there are two honest options:

• Join in the SIEM. Treat the two rules as feeding a search that pairs a 6416 keyboard-class device arrival with a script-host process creation on the same host inside a two-second window. This is the practical route and it means the value lives in your SIEM logic, not in the Sigma files.
• Use Sigma correlation rules. Modern Sigma supports correlation constructs — temporal proximity across rule references — expressed in the rule format itself. If your pipeline supports them, the join is portable rather than reimplemented per backend.

Either way, the thing to internalise is that the detection is the join, and each half on its own is noise. A new keyboard is noise; a shell from Explorer is noise; a new keyboard followed by a shell in under two seconds is an attack. Publishing the halves separately and calling it a detection is a common way to ship coverage that does not exist.

Why VID/PID allowlisting is not a boundary

Device control is worth deploying and it is worth being clear about what it does.

A USB device reports its own vendor ID and product ID. There is no attestation and no verification — the device says what it is, and the host believes it. A keystroke-injection device can therefore present the VID and PID of whatever keyboard your allowlist permits, and many purpose-built tools support exactly this because it is trivially achievable.

Serial numbers, exposed via the device instance ID, are somewhat better and are also self-reported. A device that clones the identity of a keyboard already enrolled in your allowlist is indistinguishable from that keyboard at the enumeration layer.

So the honest framing:

• Device control raises the cost from “plug it in” to “know what to impersonate.” Against an opportunistic attacker that is often enough, and against a targeted one it is a speed bump.
• Alerting on new device instance IDs is the durable value, more so than blocking. A keyboard that has never been seen on this host is worth an event even if it is permitted.
• Blocking new HID devices by default genuinely helps on high-value endpoints — servers, kiosks, executive laptops — because those machines legitimately never get new keyboards. Applying it fleet-wide generates support tickets every time somebody buys a mouse.
• The layer that actually stops the payload is application allowlisting, not device control, and it is worth spending effort there first. Keystrokes that successfully type a PowerShell download into a WDAC-enforced host accomplish nothing.

Keystroke timing: the signal you probably cannot collect

The theoretically ideal detection is the typing itself. Human keystrokes arrive with substantial and irregular gaps; injected input is frequently orders of magnitude faster and unnaturally regular. Distinguishing them is straightforward when you have the data.

The problem is that you almost certainly do not. Inter-keystroke timing is not in any Windows event log — capturing it requires input-level instrumentation, which is what a keylogger is, with all the privacy, legal, and works-council consequences that implies. Some EDR products expose a derived version of this signal; most environments have no access to it at all.

It is also evadable. Adding randomised delays between keystrokes is a one-line change in most injection tooling, and it costs the attacker a few seconds of dwell time.

This is why the process-and-timing correlation remains the practical detection. It uses telemetry you can actually collect, it does not require input surveillance, and it keys on the sequence the attack needs rather than on a characteristic the attacker can tune away.

What about macOS and Linux?

Windows dominates this discussion and the other platforms are not equivalent.

macOS has a genuine built-in mitigation. When an unrecognised keyboard is attached, macOS prompts to identify it before accepting input, which interrupts a walk-past attack directly. It is not absolute — a device impersonating an already-trusted keyboard, or a machine where somebody dismisses the prompt reflexively, gets through — but it is meaningfully more than Windows offers out of the box, and it is one of the few places the default configuration is on the defender’s side.

Linux has USBGuard, a policy framework that authorises devices by attribute before the kernel binds a driver. It is capable, it is genuinely effective, and it requires deliberate policy authoring — which means it protects servers and hardened workstations where somebody did that work and nothing else.

For both, the endpoint telemetry story is weaker than Windows: fewer standard events, more reliance on your EDR’s device visibility. If your estate is mixed, verify what device-arrival telemetry you actually receive per platform rather than assuming the Windows pipeline generalises.

How do you respond to a suspected HID injection?

1. Get the device off the machine and keep it. It is the evidence, and its stored payload answers what was attempted far faster than reconstructing it from logs.
2. Establish the window. The device-arrival timestamp bounds everything; the session that was unlocked at that moment identifies the affected user context.
3. Reconstruct what was typed from what ran. Process creation, PowerShell script-block logging, and command lines within the window are the transcript. Script-block logging is the single most valuable source here and, like PnP auditing, is off by default.
4. Assume the user’s session is compromised, not the machine as a whole, until you know otherwise. Injection runs as the logged-in user, so the blast radius starts with that account’s access.
5. Check for persistence established in those few seconds — a scheduled task, a run key, an added SSH key. Payloads are written to survive the plug being pulled.
6. Rotate the user’s credentials and any tokens cached in that session.
7. Ask how the device got there. A dropped drive in a car park, a delivered peripheral, or a visitor with unescorted access are different problems with different fixes, and the physical answer usually matters more than the technical one.

Point 7 is worth dwelling on. The 2016 study “Users Really Do Plug In USB Drives They Find” demonstrated that dropped-drive attacks work at scale — the overwhelming majority of drives left in a public area were picked up, and files were opened on a large fraction of them. The control that addresses that is not a Sigma rule. It is telling people, plainly and repeatedly, that found hardware goes to the security team unplugged, and making that the path of least resistance rather than a policy nobody has read.

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. Servers, kiosks, and shared terminals legitimately never receive a new keyboard, which makes the policy free of support cost on exactly the machines that most need it — a rare case where the strictest setting is also the cheapest to operate.
• Auto-lock on idle and enforce short lock timeouts — most Ducky attacks need an unlocked, unattended machine, which makes the lock timeout one of the few settings that defeats the entire technique rather than one variant of it. A machine that locks in sixty seconds is not a target for a walk-past attack at all, and the setting costs nothing to deploy fleet-wide.
• Restrict mshta, wscript, and unsigned scripts so common payloads fail.
• Fill the ports you are not using. Port blockers are unglamorous and they meaningfully raise the cost on kiosks, shared terminals, and reception machines — the endpoints most likely to be unattended and most rarely audited.
• Treat a walk-past attack as a physical-security finding too. Every successful injection implies somebody reached an unlocked machine. The lock timeout, the visitor escort policy, and the desk layout are all part of this control set, and they are frequently cheaper to change than the endpoint configuration.

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.
• Leaving Audit PnP Activity disabled. Event ID 6416 is off by default, so the device half of the correlation does not exist and the rule degrades to a noisy process alert.
• Publishing the two halves as separate rules and calling it coverage. The detection is the join between them; each half alone is noise.
• A timeframe with nothing to correlate against. It reads as a time-bounded rule and behaves as though it were not there.
• Trusting VID/PID allowlists as a boundary. Devices self-report their identity, and impersonating an allowlisted keyboard is a configuration change.
• No PowerShell script-block logging. It is the transcript of what the keystrokes actually did, and like PnP auditing it is off by default.
• Assuming the Windows pipeline covers macOS and Linux. The events differ, and so do the built-in mitigations — macOS prompts on a new keyboard; Linux needs USBGuard policy someone wrote.
• Treating it as purely a technical problem. Dropped-hardware attacks work because people plug things in. Make handing found hardware to the security team the easy path.

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.
9. Enable Audit PnP Activity so Event ID 6416 exists, and confirm it by attaching a keyboard.
10. Enable PowerShell script-block logging — it is the transcript of whatever the keystrokes ran, and reconstructing that from process command lines alone is much harder.
11. Build the join in the SIEM (or as a Sigma correlation rule) rather than shipping the two halves separately.
12. Verify device-arrival telemetry exists per platform, not just on Windows.
13. Make handing in found hardware the easy, blameless path, and say so more than once.

Items 9 and 10 are prerequisites rather than improvements: without them the detection cannot fire and the investigation has no transcript, and both are single Group Policy settings. If you do nothing else from this list, turn those two on and confirm the events appear — a detection built on telemetry you never enabled looks identical to one that simply never matched.

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.