Ducky Script Volume 15 — Defense & Detection — Ducky Script · Hacking

How keystroke injection is actually caught — USB device control, HID allow-listing, behavioural and timing detection, and the blue-team view

Section	Topic
1	About this volume
2	The defender’s problem — you can’t ask “is this a real keyboard”
3	USB device control — the primary defense
4	HID allow-listing — and why VID/PID isn’t enough
5	Behavioural and timing detection
6	Detecting the other vectors — storage, ethernet, serial
7	Detecting the implants — Key Croc and O.MG
8	Physical and procedural controls
9	The detection signature, per device
10	Why an offensive operator reads this volume
11	Resources

1. About this volume

Volumes 1-14 described keystroke injection from the operator’s side. This volume turns it around: how it is caught. It is the blue-team view — what defenses exist, how well each works, and where each fails.

It is here for two audiences. For a defender, it is the catalogue of controls. For an offensive operator — tjscientist’s primary stance — it is just as essential: you cannot reason about your own detection signature, your evasion choices (Vol 5’s jitter and identity spoofing), or your operational risk without understanding what the other side is actually doing. §10 makes that case explicitly. Either way: this is the volume about the limits of the technique, and a technique you only understand from the attacking side you do not fully understand.

2. The defender’s problem — you can’t ask “is this a real keyboard”

Start where Vol 1 §3 started, because the defender starts there too. The HID trust model has no authentication step — there is no protocol-level way to ask a USB device “are you a human’s keyboard or an injection device’s keyboard.” Both are, genuinely, HID keyboards.

   The defender's fundamental constraint
   ════════════════════════════════════════════════════════

   The defender CANNOT detect keystroke injection by asking
   the device what it is — the device tells the truth: "I am
   a keyboard." And it IS one.

   So every real defense works one of three other ways:

   1. CONTROL WHAT CONNECTS  — don't let unknown USB devices
      enumerate at all (§3) — the strongest, bluntest tool.

   2. CHECK WHAT IT CLAIMS   — allow-list known-good devices
      by identity (§4) — defeated by spoofing, but raises cost.

   3. WATCH WHAT IT DOES     — behavioural/timing detection:
      a "keyboard" that types 200 cps with zero variance is
      not a human (§5) — defeated by jitter, but raises cost.

   Every defense is one of these three. None of them is
   "detect that it's an injection device" — that question
   has no answer at the USB layer.

This framing is the whole volume. §§3-5 are the three approaches; §§6-8 extend them to the non-HID vectors and the physical implants; §9 sums it per device.

3. USB device control — the primary defense

The strongest defense is the bluntest: do not let unknown USB devices enumerate. USB device control (a feature of endpoint-protection suites, OS group policy, and dedicated tools) governs what is allowed to connect at all.

Modes, weakest to strongest:

Mode	What it does	Defeats
Log/alert	record USB device connections; alert on new HID devices	nothing by itself — but it makes injection visible after the fact
Block new HID after enrollment	once a machine’s keyboard/mouse are known, refuse additional HID devices	a plug-in injection device — it is a new HID device
Allow-list	only enumerate devices on an explicit allow-list (§4)	unknown devices entirely — raises the bar to identity spoofing
Block all USB (or all but charging)	the nuclear option — no USB data devices at all	everything — at a large usability cost

   USB device control — the defense that actually works
   ════════════════════════════════════════════════════════

   The injection device's whole technique depends on
   ENUMERATING as a keyboard. If it never enumerates, the
   technique never starts.

   "Block new HID devices after the machine's real keyboard
    is enrolled" is the single highest-value control: a
    plug-in Rubber Ducky / Bash Bunny is, by definition, a
    NEW HID device. Block new HID and you have blocked the
    plug-and-pull devices outright.

   What it does NOT cleanly stop:
     • the O.MG that REPLACES the trusted keyboard's cable
       (it's inline on an ALREADY-enrolled keyboard)
     • the Key Croc inline on an already-enrolled keyboard
     → the implants are the device-control-hard cases (§7)

USB device control is the defense an offensive operator most needs to know about, because it is the one that can stop the operation before it starts — and it is the reason the covert implants (§7) exist as a category: they sidestep “block new HID” by being inline on something already trusted.

4. HID allow-listing — and why VID/PID isn’t enough

An allow-list (§3) needs a way to identify a device. The obvious key is the USB identity — VID/PID and the device strings. And the obvious problem is Vol 6 §3: a Ducky Script device can spoof all of those.

   The VID/PID allow-list arms race
   ════════════════════════════════════════════════════════

   Defender:  "allow-list only our standard Dell keyboards
              by VID/PID."
   Attacker:  ATTACKMODE HID VID_<Dell> PID_<Dell keyboard>
              (Vol 6 §3) — now the injection device IS, by
              identity, an allowed Dell keyboard.
   Defender:  needs MORE than VID/PID — because VID/PID is
              attacker-controlled.

   Stronger keys an allow-list can use:
     • the full device descriptor / serial (still spoofable,
       but raises the cost — the attacker must know the
       exact target device to clone)
     • PORT/topology binding — "the keyboard is allowed on
       THIS physical port" — harder to spoof, since it's
       about WHERE not WHAT
     • combining identity allow-listing with behavioural
       detection (§5) — spoofing identity doesn't change
       behaviour

The takeaway for both sides: VID/PID allow-listing alone is weak — it is defeated by a single ATTACKMODE line. It still has value (it stops the un-spoofed device, and forces the attacker to do reconnaissance to know what to spoof), but a defender relying on VID/PID alone has a paper wall, and an offensive operator who knows the target’s standard keyboard has a paper-wall-sized hole. The robust defensive posture is allow-listing plus behavioural detection — spoofing the what does not change the how.

5. Behavioural and timing detection

The third approach (§2): watch what the “keyboard” does. The signature it is looking for:

   What an injection device's keystrokes look like
   ════════════════════════════════════════════════════════

   A HUMAN typing:
     irregular intervals, 40-120 cps bursts, pauses to think,
     typos and corrections, never a sustained machine rate

   AN INJECTION DEVICE typing (naively):
     • machine-perfect even intervals (a fixed DELAY)
     • sustained rates no human reaches (hundreds of cps)
     • appears MILLISECONDS after a new HID device enumerates
       (a human takes seconds to start typing on a new kbd)
     • types complex command-line strings flawlessly, fast,
       with no corrections — into a shell, immediately

   Behavioural detection flags THAT profile. It is the
   defense that does not care what the device CLAIMS to be —
   only what it DOES.

This is the defense Vol 5’s jitter and randomization exist to counter:

Jitter (Vol 5 §7) breaks the “machine-perfect even intervals” tell — irregular timing looks more human.
Randomization (Vol 5 §8) breaks naive content-signature matching.
An opening DELAY (Vol 3 §5) — generous — softens the “typed milliseconds after enumeration” tell.
Operator-gated execution (Vol 13 §7) softens it further — a human pressed the button, so the timing of when injection starts is human.

But behavioural detection is the defense that most resists evasion, because the deeper tells are hard to fake: a payload still types fast (slowing to true human speed defeats the point of the device), still types flawlessly (no human enters a 200-character PowerShell one-liner with zero corrections), and still does unusual things (a keyboard that opens a shell and pastes a script is behaviourally anomalous regardless of timing). Jitter raises the cost; it does not make injection look like a human. An offensive operator should assume a mature behavioural detector can catch a Ducky Script payload and plan the engagement’s risk accordingly (§10).

6. Detecting the other vectors — storage, ethernet, serial

The Bash Bunny and Key Croc go beyond HID (ATTACKMODE STORAGE / SERIAL / ETHERNET — Vol 9 §5, Vol 10 §7), and those vectors have their own detection stories — generally better for the defender:

Vector	Detection
Mass storage	USB device control covers storage devices too — often more aggressively than HID, since “block USB storage” is a long-standing, well-understood DLP control. A device presenting as storage is more likely to be controlled, not less.
USB ethernet	a new network adapter appearing is highly anomalous and very detectable — endpoint software, NAC, and even alert users notice “why did a new network interface just appear.” The Bash Bunny’s signature capability is also its loudest.
Serial	a new USB serial device is unusual on most endpoints and logged by USB device control.

The pattern: HID is the stealthiest vector precisely because keyboards are so trusted and so common. The moment a device steps outside HID — to be storage, a NIC, a serial port — it enters territory where defenders have mature, specific controls. This is a real consideration in device selection (Vol 17): the Bash Bunny is more capable, but its extra vectors are also more detectable than the Rubber Ducky’s pure-HID approach.

7. Detecting the implants — Key Croc and O.MG

The install-and-leave devices (Key Croc, O.MG) are the device-control-hard cases (§3) — they are inline on, or are, already-trusted hardware. So their detection shifts to other axes:

Key Croc:

Physical inspection. It is an inline adapter — a physical-audit of keyboard cabling finds it. “Is there a small box between this keyboard and the computer that should not be there?” is a real, effective control.
Wi-Fi signal. The Croc has Wi-Fi (Vol 10 §3); an unexpected 2.4 GHz device/AP in a sensitive area is detectable by RF survey.
Behavioural — when it injects. Its keylogging is passive and quiet, but the moment a payload fires (the match triggers), the injection has the same behavioural signature as any other (§5).

O.MG:

Physical inspection / supply-chain control. The O.MG’s whole point is being indistinguishable from a normal cable/plug/adapter (Vol 11) — so the defense is procedural: control the supply of cables and chargers, do not use found/gifted cables, physically inspect (though inspection is hard — that is the O.MG’s design goal).
Wi-Fi signal. The O.MG is an ESP-based Wi-Fi implant (Vol 11 §4). Its Wi-Fi — an AP it hosts, or its traffic to a network — is a detectable RF signature. An RF survey of a sensitive space can find an O.MG that the eye cannot.
Behavioural — when triggered. Same as everything else: dormant it is invisible, but when it injects, it injects, and §5 applies.

   The implant detection shift
   ════════════════════════════════════════════════════════

   Plug-and-pull devices ──► caught by USB DEVICE CONTROL
                             (block new HID — §3)

   Install-and-leave implants ──► USB device control is weak
                             (they're inline on trusted gear)
                             so detection shifts to:
                               • PHYSICAL inspection
                               • RF / Wi-Fi survey
                               • SUPPLY-CHAIN procedure
                               • behavioural — only when they fire

   This is WHY the implants exist as a category, and why
   defending against them is a different discipline than
   defending against a Rubber Ducky.

8. Physical and procedural controls

Underlying all of the above — the controls that are not technical at all:

Port control. Physically blocked/disabled USB ports. Crude, effective, common in high-security environments.
Don’t use found/unknown USB devices. The “found a USB stick in the parking lot” awareness training — and its extension to cables and chargers, which is less well-trained and exactly what the O.MG exploits.
Supply-chain hygiene for cables and chargers. Procurement controls, tamper-evident packaging, “use only IT-issued peripherals.” The O.MG’s defense is mostly here, because its technical detection is hard by design.
Physical security and escorting. Keystroke injection (plug-and-pull) needs physical access to the machine. The implants need physical access to install. Controlling who is near the hardware controls the whole technique class at its root.
Lock the screen. A locked machine is a much smaller target (Vol 1 §6) — “lock when you walk away” training is a real control against opportunistic plug-and-pull.
User awareness. A user who notices “my screen is doing things by itself” and pulls the device, or who reports “this cable isn’t mine,” is a sensor the attacker cannot spoof.

These are unglamorous and they are also, collectively, the most reliable defense — because they attack the technique at the physical-access prerequisite that every Ducky Script device shares.

9. The detection signature, per device

Summing it up — what each owned device looks like to a defender:

Device	Primary detection	Stealth posture
USB Rubber Ducky	USB device control (“new HID device”); behavioural/timing on injection	loud on plug-in (new HID), brief exposure; pure-HID so no extra-vector tells; jitter helps the timing tell
Bash Bunny	USB device control; new network adapter is very loud; ~7s boot is its own window	the multi-vector capability is also a multi-vector signature — louder than the Ducky
Key Croc	physical inspection (inline adapter); Wi-Fi RF survey; behavioural only when it fires	very quiet while logging; the install is the exposure; firing a payload is loud
O.MG family	physical/supply-chain (hard by design); Wi-Fi RF survey; behavioural when triggered	the stealthiest physically; the Wi-Fi is the residual signal; dormant = invisible

No device in the family is undetectable. Each has a different detection profile, and device selection is partly a detection-profile decision (Vol 17). The Rubber Ducky trades a brief loud moment for simplicity; the O.MG trades a persistent faint Wi-Fi signal for physical invisibility; the Bash Bunny’s power costs it stealth; the Key Croc is quiet until it acts.

10. Why an offensive operator reads this volume

tjscientist’s stance is offensive — so why a whole defensive volume? Four reasons, and they are not soft:

You cannot estimate your own risk without it. “Will this work / will I be caught” is the first operational question, and it is this volume’s subject matter. An operator who does not know what USB device control or behavioural detection does is guessing at their own exposure.
Your evasion choices only make sense against the defenses. Jitter (Vol 5 §7), identity spoofing (Vol 6 §3), the opening DELAY — every one of them is a counter to a specific defense in this volume. Apply them without knowing what they counter and you are cargo-culting.
Device selection is partly a detection decision (§9). Choosing the Rubber Ducky vs the O.MG for a job is, in part, choosing a detection profile. That is a Vol 17 decision that depends on this volume.
The best offensive engineers think like defenders. A pentest’s value to the client is the defensive insight it produces. An operator who understands §§3-8 does not just run payloads — they can tell the client which control would have stopped this, which is the actual product. And for tjscientist specifically, owning the full device family means the most useful thing this manual can produce is the ability to test a defense, which requires understanding it.

The defensive and offensive views are not opposites here. They are the same knowledge, used by two roles — and an operator who only learned the offensive half learned half a technique.

11. Resources

Industry writeups on USB keystroke-injection defense (e.g. endpoint-vendor and security-blog analyses of USB Rubber Ducky detection/evasion)
USB device control documentation for the relevant endpoint-protection / OS-policy tooling in the target environment
Vol 1 §3 — the HID trust model the defender is stuck with
Vol 5 — jitter and randomization: the evasion this volume is the counterpart to
Vol 6 §3 — VID/PID spoofing: the §4 arms race, from the other side
Vol 16 — the legal/posture framing (defensive testing is still authorized-only)
Vol 17 — device selection as, partly, a detection-profile decision

This is Volume 15 of an 18-volume series. Next: Vol 16 — Operational Posture: the legal, ethical, and OPSEC framing for a technique that is intrusive by definition, the authorization artifact, the special weight of the install-and-leave implants, and the discipline that keeps the whole device family on the right side of the line.

Ducky Script Volume 15 — Defense & Detection

Contents