Tools that masquerade as trusted peripherals (keyboard, mouse, cable, USB NIC) to automate actions or capture data.
Think O.MG Cable, Rubber Ducky, Bash Bunny, and Key Croc—great for awareness training and blue-team hardening when used with permission.
Quick-start checklist
Authorization: Only test in your own lab or with explicit written permission.
Host OS: Know your target OS prompts/policies (Windows, macOS, Linux; mobile restrictions).
Payload hygiene: Use transparent, reversible demos (open a text editor, display a banner, etc.).
Isolation: Test on non-production machines or disposable VMs with snapshots.
Evidence: Log what you run, when, and on which host to support blue-team learning.
Primer: HID, USB descriptors & trust
A HID (Human Interface Device) like a keyboard or mouse is implicitly trusted by most OSs.
HID tools present themselves with USB descriptors that say “I am a keyboard,” then send keystrokes at machine speed.
Some implants also expose storage, serial, or a tiny network card to stage files or callbacks.
Examples:
O.MG Cable — looks like a normal cable; includes an implant that can run keystroke payloads and beacon/control over Wi-Fi.
Rubber Ducky — keystroke injection via DuckyScript; plug-and-type macros.
Bash Bunny — multi-mode (HID, storage, RNDIS/ECM) with on-device scripts.
Key Croc — inline keyboard implant for logging and triggers (authorized labs only).
Once a host accepts a “keyboard,” keystrokes are trusted like a human typed them.
Common lab workflows
1) Awareness demo (safe keystrokes)
Plug the implant into a lab machine; wait for the keyboard to enumerate.
Send a benign script: open a text editor and type a clear banner message.
Discuss how OSs trust keyboards and how policy can reduce risk.
2) Conditional payloads
Trigger only after user action (e.g., a specific keystroke) or time window to show control.
Demonstrate geofencing or SSID presence checks where supported (lab only).
3) Multi-mode staging (Bash Bunny-style)
Use storage or USB Ethernet modes to host benign files or serve a local page to the target host.
Keep everything self-contained and reversible; avoid outbound internet requirements for demos.
4) Blue-team validation
Turn on host policies (see Defenses below), then re-run demos to prove mitigations.
Document which controls blocked enumeration, keystrokes, or file staging.
Ethics: Never deploy implants on production endpoints, shared facilities, or personal devices without explicit authorization. Keep demonstrations transparent and reversible.
Defenses & hardening
USB device control: Enforce allowlists for HID/USB classes (MDM/EDR policies, Windows Device Control, macOS Endpoint Security, Linux udev rules).
Restricted modes: Disable new USB devices when locked; prefer “require unlock before new accessories” on supported OSs.
Authorize keyboards: Prompt before trusting new HID keyboards; log acceptance events.
Physical hygiene: Don’t use untrusted chargers/cables; deploy charge-only (“USB condom”) blocks where appropriate.
Network guards: Block unexpected USB NICs (RNDIS/ECM) and rogue DHCP; monitor for new interfaces.
User training: Short demos dramatically improve awareness around “evil cables” and gifted USB drives.
Troubleshooting
No enumeration: Try a different port; check adapters (USB-C vs A); some ports block data in charge-only mode.
Keystrokes garbled: Match keyboard layout and locale; add delays between commands; ensure the focused app is ready.
Blocked by policy: That’s good! Capture which control stopped it and update your blue-team docs.
FAQ
Do “data-blocker” charge adapters help?
Yes—by removing data lines, the host never enumerates a device. Great for public charging where you don’t need data.
Are modern OSs immune?
No. They have features to reduce risk (restricted modes, prompts, allowlists), but a trusted keyboard can still type. Policy + user awareness is key.
Is this the same as BadUSB over storage?
Related idea. HID implants focus on keystrokes; other tools abuse storage or USB networking. Multi-mode devices can combine them.
