USB Ninja Cable

The USB Ninja Cable is a commercially available BadUSB implant hidden inside a fully functional USB cable. It charges and transfers data normally. Concealed in the connector housing are a Bluetooth Low Energy radio and a microcontroller that, on receiving a wireless trigger, re-enumerates as a keyboard and injects a pre-programmed payload into the host.

What makes it a wireless threat rather than a USB threat is that trigger channel. The operator does not need to touch the keyboard, does not need network access to the target, and never has to come back for the device. They need to be within BLE range at a moment of their own choosing, which is usually the moment the workstation is unlocked and unattended.

This information is provided for general awareness and defense purposes only.  This information also is not intended to be a complete description of the functionality or risks of the identified tools.

CTO Dr. Brett Walkenhorst demonstrates the capabilities of the USB Ninja Cable.

Quick Facts

• What it is: A keystroke injection implant built into a working USB cable, produced by RFID Research Group and sold openly since a 2018 crowdfunding campaign.
• Trigger: Bluetooth Low Energy, from a paired remote or a mobile app, at a time the operator chooses.
• Three defensive problems: it is dormant until triggered, the timing is attacker-chosen, and visual inspection does not work.
• Where detection is possible: the radio. Host HID telemetry catches injection after the fact, and physical inspection catches very little.
• The control that matters most: aggressive session lock. Keystroke injection into a locked session accomplishes nothing.
• Public incident record: empty. The capability is real and cheap, and there is no confirmed public attack attributed to one of these cables. Both halves of that sentence matter.

What Is the USB Ninja Cable?

It is the commodity version of a nation-state capability. The lineage is worth knowing, because it explains why this category is not going away.

Year	Milestone
~2008	NSA ANT catalog COTTONMOUTH: USB connector implants with RF exfiltration, declassified in 2013
2010	USB Rubber Ducky popularizes commodity HID keystroke injection
2014	Nohl and Lell present BadUSB at Black Hat, establishing firmware-level USB identity spoofing
2018	USBNinja crowdfunds on Crowd Supply, 478% funded across 228 backers
2019	The O.MG Cable ships, adding a Wi-Fi control channel and a keylogger
2020 onward	USBNinja Professional adds eight payload slots, over-the-air updates, mass storage emulation, and self-destruct

Treat this as a category rather than a product. USB Ninja, the O.MG Cable, the USB Rubber Ducky, and the Bash Bunny all place the same primitive, trusted HID input, behind different form factors and control channels.

Hardware and Specifications

Original USBNinja, 2018

Property	Value
Connector variants	Micro-USB, USB-C, Lightning; 1 m length
Electrical	4 to 25 V, supporting fast charging; roughly 10 mA typical draw
Data	Full-rate USB pass-through
Payload storage	About 6 KB of flash across two slots, A and B
Radio	BLE 4.0
Programming	Non-contact magnetic ring for bootloader access; Arduino IDE toolchain
Launch pricing	$89 basic through $420 for the pentester kit

The remote control unit runs on a 3.6 V, 40 mAh cell, drawing 80 µA on standby and 30 mA while transmitting. Vendor-published range figures are roughly 30 m with the small 2 dBi antenna, 50 m with an 11 cm 3 dBi antenna, and about 100 m with an 18 dBi directional panel. Those are line-of-sight ceilings. Plan against tens of meters through interior construction, which still puts an operator in an adjacent office, a lobby, a stairwell, or a vehicle at the curb.

USBNinja Professional

• Eight payload slots of 20 KB each, selectable from the remote.
• Over-the-air payload editing through the mobile app, so the cable never has to be physically recovered to change what it does.
• Configurable USB descriptors. VID, PID, and manufacturer string can be changed from the app, which defeats naive identifier blocklists.
• A 120 KB emulated mass-storage volume that can coexist with the HID interface as a composite device.
• Self-destruct, clearing firmware and leaving nothing recoverable for forensics.
• Roughly 0.4 mA operating current, an order of magnitude below the original, which directly degrades power side-channel detection.
• Selectable BLE 5.0 mode alongside the default BLE 4.0 behavior.

Two of those changes matter more than the rest. The current draw weakens the detector hardware people buy for this problem, and the combination of over-the-air editing with self-destruct weakens post-incident forensics.

The Attack Chain

1. Delivery. Supply chain substitution, a swapped or dropped cable, a conference giveaway, an insider, or replacement of an existing peripheral cable. Keyboard and monitor cables are the intended long-term home, because nobody ever inspects them.
2. Dormancy. The cable behaves normally. No data-line anomaly, no enumeration event, potentially for months.
3. Trigger. An operator within BLE range presses the remote or uses the app. Plug-in-activated and magnet-activated modes also exist.
4. Enumeration. The cable presents a keyboard and mouse interface, optionally alongside mass storage on the Professional.
5. Injection. The payload types at machine speed into the active session: spawning a shell, staging a second payload, writing persistence, opening a file, or disabling a control.
6. Post-exploitation. Usually handed off to a conventional implant or C2 channel. The Professional’s mass storage and typing-feedback capture allow limited direct staging where the target is air-gapped.

The dependency that runs through the whole chain: HID injection is only useful against an unlocked, interactive session. This is the single most important control point and the one most often left out of discussion about the device.

The Wireless Layer

This is where the implant is weakest, and where detection engineering has something to work with. Independent reverse engineering published by Embedded Lab Vienna in 2021, examining a Professional kit with a BLE 4.0 remote, documented the following. Treat these as fingerprints for the units examined rather than universal constants.

• Discoverable by ordinary BLE scanning while the remote is powered off.
• Identity strings observed as an advertised local name of Ninja, a GAP device name of USBNinja+, manufacturer Proxgrind, and model Ninja, with a device address in the E1:F1:22: random-static range.
• GATT structure comprising standard GAP, GATT, and Device Information services plus four vendor characteristics: 0000FFF1, 0000FFF2, 0000FFF3, and a 128-bit 8EC90003-F315-4F60-9FB8-838830DAEA50. All readable without pairing or authentication.
• Trigger mechanics confined to two handles: a CCCD enable write followed by command writes to the vendor characteristic, with values derived from the remote’s A and B buttons.
• The shared secret transmitted in plaintext as ASCII-encoded hex, with a factory default of 8888.

The security consequences are worth stating plainly, because they cut both ways. There is no pairing, bonding, or link-layer encryption, so any nearby scanner can enumerate the device. The default secret is static and memorable, so most deployed units are probably still on it. And because the secret crosses the air in plaintext on every trigger, a third party who observes one trigger can fire the payload afterward. A deployed USB Ninja implant is therefore an uncontrolled asset, which red teams should treat as an operational risk and a scoping disclosure rather than a footnote.

Detection caveats. The 8EC90003 UUID base is associated with Nordic Semiconductor bootloader services and appears in many unrelated products, so it is not a signature on its own. Identity strings are user-configurable on the Professional, so name-based rules catch careless operators only. BLE 5.0 mode changes on-air behavior, leaving a gap in monitoring tuned only to BLE 4.0. And the radio is observable only while advertising or connected, so point-in-time surveys can miss a deeply dormant cable entirely.

Detection

RF monitoring, primary

Continuous passive monitoring of the 2.4 GHz band is the only method that finds a dormant implant in place without physically handling every cable in the building. The opportunities are BLE advertisements while the remote is off, connection establishment at trigger time, the vendor-characteristic write pattern, and any BLE peripheral appearing in a zone where none is inventoried, such as a SCIF, data hall, executive floor, or lab.

Localization is what converts that into a response. A platform that trilaterates gives you the desk rather than the building, which is the difference between an alert queue and an incident someone can close. The honest framing is that RF monitoring turns “we cannot find it” into “we can find it,” and it requires sensors that are deployed, tuned, and actually watched.

Host telemetry, strong secondary

Whatever the cable claims to be, injection produces an HID enumeration event followed by typing. Rules worth deploying:

• A new HID keyboard enumerating where one is already present, or on an endpoint that should have none.
• A composite device exposing an HID interface alongside a non-HID class.
• Plug-and-type latency, meaning typing within seconds of enumeration.
• Keystroke timing entropy: machine-speed, low-variance inter-key intervals.
• A process spawning from the shell with encoded arguments within 60 seconds of a new USB HID event.
• Run or RunOnce registry writes within 60 seconds of USB insertion, or encoded PowerShell from a non-administrative context.

A passive Linux kernel HID-scoring driver implementing timing entropy, plug-and-type latency, and descriptor fingerprinting was proposed on the kernel mailing list in April 2026; it logs and recommends userspace action rather than blocking, and is worth tracking. The limitation across all of these is the same: they fire at injection time. They provide incident response, not prevention, and they never see a dormant cable.

Electrical and physical inspection, limited

Method	Effectiveness
Visual inspection	None. The product is explicitly designed to defeat it.
Weight and feel comparison	Unreliable on modern units.
Side-channel power analysis	Effective against the original. The Professional’s ~0.4 mA draw narrows the margin, so treat “detects all known malicious cables” claims as historical rather than forward-looking.
Current-threshold detectors	Useful cheap triage, but a device that latches above 1.6 mA will never see a 0.4 mA implant. Know your detector’s floor.
2D X-ray	Reveals antenna and primary microcontroller. Lumafield’s industrial CT analysis of an O.MG cable showed 2D imaging misses stacked and bonded secondary dies.
3D industrial CT	Definitive, resolving bond wires and stacked silicon, and impractical outside supply-chain assurance or specialist analysis.
Destructive teardown	Definitive, destroys the evidence, and tips off the operator.

What does not work

• Antivirus and signature scanning, because there is no file until a payload lands.
• Firewalls, because the trigger channel is entirely out of band.
• Blocklists by VID and PID alone, because descriptors are configurable on the Professional.
• Point-in-time RF sweeps, because a dormant cable between triggers may show nothing.
• Asking users to check their own cables.

Mitigation

1. Aggressive session lock. A 60-second inactivity lock through Group Policy machine inactivity limits or the MDM equivalent is the cheapest control with the largest effect, because it defeats the trigger-after-they-walk-away model the wireless remote exists to enable.
2. USB allow-listing at the interface level. Device-level allow-listing is insufficient, since a composite device authorized as storage brings its hidden keyboard along. Use USBGuard with a default-block policy on Linux, Device Installation Restrictions on Windows managed through Intune at scale, and accessory approval set to ask every time on macOS in high-security contexts.
3. Continuous RF monitoring with localization in sensitive spaces.
4. Cable supply chain control. Buy from authorized distributors, serialize and inventory peripherals in sensitive areas, and treat an unexplained new cable as an incident rather than a convenience.
5. Physical port control in the highest-assurance zones: port blockers, permanently attached and inventoried I/O devices, and disabled or filled unused ports.

Supporting controls worth having: PowerShell Constrained Language Mode enforced through AppLocker or WDAC, screen privacy filters in open-plan space to limit an operator’s ability to time a trigger by watching the screen, a written prohibition on foreign cables, conference giveaway peripherals, and public charging cables in scope environments, data blockers for travel, and malicious-cable scenarios written into red team scoping and tabletop exercises.

On mobile, the picture is better. iOS USB Restricted Mode has disabled data connections on locked devices by default since 11.4.1, macOS on Apple Silicon requires approval for new accessories, and both iOS 18.4 and Android 15 hardened against the accessory-consent bypass class. Those controls are strong but not axiomatic: CVE-2025-24200 was a lock-screen bypass patched in iOS 18.3.1.

How It Compares to Other Implants

	USB Ninja / Pro	O.MG Cable Elite	Rubber Ducky	Bash Bunny
Form factor	Cable	Cable	USB stick	USB stick
Wireless channel	BLE 4.0 / 5.0	Wi-Fi	None	BLE on Mark II
Trigger	Remote, app, plug-in, magnet	Web UI over Wi-Fi, geofence	Plug-in	Plug-in, remote trigger
Payload slots	8 × 20 KB on Pro	Multiple	One	Switch-selected
Keylogging	Typing-feedback capture on Pro	Yes	No	No
Self-destruct	Yes on Pro	Yes	No	No
Mass storage	120 KB emulated on Pro	Yes	microSD	Yes
Toolchain	Arduino IDE / C	DuckyScript, web IDE	DuckyScript	Bunny Script
Approximate price	$99 to $420	$120 to $200	~$49	~$100

The defensive distinction that matters: the O.MG family’s Wi-Fi channel is loud and lands within reach of conventional wireless intrusion detection, while the USB Ninja’s BLE channel is quiet and requires deliberate Bluetooth monitoring. Most enterprise wireless monitoring is Wi-Fi-centric, and that gap is precisely the point of the design.

MITRE ATT&CK Mapping

Technique	ID	Application
Hardware Additions	T1200	Initial access through the implanted cable
Command and Scripting Interpreter	T1059	Injected shell or PowerShell payload
Boot or Logon Autostart Execution	T1547	Registry persistence written by the payload
Input Capture: Keylogging	T1056.001	Typing-feedback capture on the Professional
Exfiltration Over Other Network Medium: Bluetooth	T1011.001	BLE channel between cable and operator
Indicator Removal	T1070	Self-destruct firmware wipe

Open Research Questions

• Empirical characterization of the Professional’s BLE 5.0 mode, including whether the plaintext-secret weakness persists.
• RF signatures that survive user-configured device names and descriptors.
• Measured, rather than claimed, detection floors for current side-channel detectors against a 0.4 mA implant.
• What, if anything, survives a self-destruct firmware wipe for forensic recovery.
• Practical false-positive rates for HID timing-entropy scoring in environments with macro keyboards, barcode scanners, KVMs, and accessibility devices.
• Whether nation-state or criminal use of commodity implant cables exists in non-public incident data.

Frequently Asked Questions

Has a USB Ninja Cable ever been used in a real attack?

There is no public, confirmed incident attributable to one. The broader juice-jacking category has drawn repeated FBI, FCC, and TSA warnings that journalists later found were not tied to specific incident intelligence: a 2023 Ars Technica investigation found no documented cases against modern iOS or Android, Apple said it was unaware of any in the wild, the FCC’s 2019 advisory could not be traced to specific cases, and the Los Angeles County District Attorney’s office had none on its books. The capability is real, cheap, and commercially available, the public record is empty, and absence of public incidents is weak evidence in a category where use is targeted, quiet, and self-destructing. The realistic threat model is espionage, insider action, and red teaming, not mass exploitation at airport charging stations.

Can I identify one by looking at it or feeling it?

No, and this is not a question of care or expertise. Build quality on the Lightning and USB-C variants is comparable to OEM cables, and at least one public reviewer found the implant cable better built than the original it imitated.

Will EDR catch the payload?

It may catch what the payload does, if the payload is noisy and your rules are tuned for post-HID-insertion behavior. It will not catch the cable. A payload that opens a document, changes a setting, or types a short living-off-the-land command may generate no detection at all.

Is this just a Rubber Ducky in a different shape?

The injection is functionally similar; the operation is not. The cable form factor survives inspection and stays deployed long-term, the trigger is remote and time-selectable so it fires when a session is unlocked, and the operator never needs repeat physical access. That combination is the entire difference, and it is a large one.

Does a USB data blocker solve this?

Only for foreign cables and ports you plug your own device into. A blocker does nothing about an implanted cable already connected to your workstation’s keyboard. It is a travel control, not an enterprise control.

Is the 100 meter range figure realistic?

That is a line-of-sight number using an 18 dBi directional antenna. Plan against tens of meters through interior walls, which still allows an operator to sit in an adjacent office, a lobby, a parking structure, or a vehicle at the curb.

Can someone other than the operator trigger the cable?

Yes, under the documented BLE 4.0 behavior. The shared secret crosses the air in plaintext, defaults are common, and no pairing is required, so anyone who observes a trigger can repeat it. A deployed implant is an uncontrolled asset, which red teams should scope and disclose accordingly.

Does it work against a locked machine?

Keystroke injection into a locked session accomplishes nothing directly, which is why aggressive lock timeouts are the highest-value mitigation. The caveat is that an operator can trigger repeatedly and simply wait for an unlocked window, which is exactly what the wireless remote is for.

Will USBGuard or Group Policy actually stop it?

Yes, if configured for per-interface authorization with a default-block posture. The structural failure is device-level allow-listing, where authorizing a device as mass storage admits its hidden keyboard interface too. Note also that USBGuard controls admission, not content: it cannot filter keystrokes from a keyboard it has already allowed.

Can we block it by VID and PID?

Not on the Professional, where those values and the manufacturer string are configurable from the mobile app. Descriptor blocklists are a speed bump. Allow-listing known-good devices by VID, PID, and serial against a maintained hardware inventory is the version that works.

How do I find one that is already in the building?

Continuous passive RF monitoring with localization is the only method that finds a dormant implant without handling every cable. Failing that: physical inventory and serialization, side-channel detectors as triage while understanding their current-draw floor, and CT scanning for the highest-assurance cases.

Should we CT scan cables routinely?

No. It is appropriate for supply-chain assurance sampling, for incident response on a specific suspect device, and for the highest-assurance procurement programs. It is not a screening control at scale.

What Can I Do to Defend Against This Threat?

• Lock sessions aggressively, since the payload needs an unlocked session and the remote trigger exists to catch one.
• Enforce interface-level USB authorization rather than device-level allow-listing, and alert on a second keyboard enumerating.
• Monitor Bluetooth and BLE continuously, not just Wi-Fi, because this implant is deliberately quiet in the band most enterprise monitoring ignores.
• Purchase from trusted sources and inventory peripherals in sensitive areas, serializing cables where the assurance requirement justifies it.
• Update and enforce your security policy to prohibit foreign cables, giveaway peripherals, and public charging cables in scope environments.
• Write the detection rules before you need them, covering plug-and-type latency, keystroke timing entropy, and post-insertion process and registry activity.

A cable is the one object in an office nobody audits, and a BLE trigger is the one channel most wireless monitoring never listens to. Closing that gap means watching the airspace continuously and knowing where a transmitter physically sits. See a demo to understand what that looks like in your environment, or explore more Bastille wireless security research.