USB attack hardware rides a port the switch already authorized. NAC and switch-derived identity will both miss it. The agent is the answer.

Adversary action. Computer accessories or networking hardware are introduced into the environment to gain initial access or persistence. USB attack hardware is the canonical example: a USB device that pretends to be a keyboard, a covert USB-Ethernet adapter, a malicious USB mass-storage with an autorun-class payload.

Where we detect. Agent: at the USB stack, the moment the device enumerates and presents a descriptor. Network: at the switch, the moment a USB-Ethernet adapter creates a new MAC/OUI on a port that previously had a known workstation.

Adversary action. HID-spoofing devices type pre-programmed scripts into a workstation as if a human were typing them. The payload typically includes credential prompts, command-prompt automation, payload-fetch commands, or LOLBin execution.

Where we detect. The device presents itself as a USB HID (keyboard) device but its VID/PID/serial signature matches a curated attack-tool database (Hak5 Ducky family, Flipper Zero HID profiles, O.MG cable signatures, common BadUSB-class re-flashed-firmware patterns).

USB mass-storage devices with autorun-class or social-engineered payloads. The agent emits descriptor data on every mass-storage insertion; downstream EDR or DLP supplies the file-content analysis. We do not scan file contents.

Outbound data on USB storage. The agent surfaces the insertion event and descriptor; whether the storage was used for exfiltration is determined by downstream DLP and file-access telemetry. We are the device-presence signal, not the data-flow signal.

Footprint.

Single Windows service (signed, MSI-installable, RMM-friendly) or Linux systemd daemon (deb and rpm packages, also pinnable via configuration management). No kernel module. No driver shim. Idle CPU well under 1%. Memory footprint typically 30–50 MB resident.

What the agent reads.

The standard USB device tree exposed by the OS — equivalent of libusb enumeration on Linux, the Setup API and Configuration Manager on Windows. Vendor ID (VID), Product ID (PID), device class, subclass, protocol, manufacturer string, product string, serial, configuration descriptors, interface descriptors. The data is the same data lsusb -v would show; we just match it on every change event.

Match logic.

A curated signature database (call it the USB-Threat DB) carries attack-tool device signatures grouped by family. Each signature is a tuple of (VID, PID, descriptor pattern, optional behavioral hint) plus a family label and a confidence bucket. The agent runs the local enumeration result against the DB on every USB enumeration change. Database updates are pulled on a configurable interval; default 6 hours.

Allow-list.

Per-host, per-user, scoped by VID/PID/serial. Justification field is mandatory and logged. Allow-list entries do not suppress the event; they reclassify it from usb-threat-detected to usb-attack-tool-authorized so an auditor can verify the exception process.

Where the agent does not run.

The agent is opt-in per host. The deployment pattern most programs adopt: cover privileged-access workstations first (administrators, IT, finance, engineering, executives), then the rest of the corporate fleet on a scheduled rollout. The agent is never deployed to medical devices, OT controllers, or any embedded device — that is not what this is for.

{
  "event":         "usb-threat-detected",
  "t":             "2026-05-11T14:32:11.482Z",
  "host":          "WS-FIN-014",
  "host_role":     "finance",
  "user":          "DOMAIN\\jruiz",
  "usb": {
    "vid":         "05ac",
    "pid":         "0220",
    "class":       "03",        // HID
    "subclass":    "01",
    "protocol":    "01",        // keyboard
    "mfg":         "Hak5",
    "product":     "Rubber Ducky",
    "serial":      "RD-9D4F-A218"
  },
  "match": {
    "family":      "hak5-ducky",
    "confidence":  "high",
    "db_version":  "2026-05-09"
  },
  "agent_version": "1.8.4",
  "action":        "alerted-no-block",
  "allow_listed":  false
}

Why descriptor-and-DB rather than behavioral inference.

Behavioral inference for "is this device acting like a keyboard or like an attack tool" is an ML-classifier problem with a non-trivial false-positive surface and adversarial-input exposure. Descriptor-and-DB is deterministic: the device announces a VID/PID/class on enumeration, those values are compared against a curated database, the match is or is not. An adversarial-input attack against this design would require modifying the attack hardware's actual USB descriptor — which is a hardware engineering project, not a software evasion. See AI threats for the parallel reasoning behind the broader Device DNA path.

Signature classes and their false-positive profile.

Known attack hardware (Rubber Ducky family, Flipper Zero HID profiles, O.MG cable signatures). Effectively zero false-positive rate. The VID/PID space is narrow and the devices are sold by identifiable vendors. Match = true positive unless allow-listed.

BadUSB-class re-flashed firmware on commodity USB mass-storage. Lower-confidence match. The signature is a descriptor pattern (unusual HID descriptor on a device that also presents a mass-storage interface). False-positive rate observed in pilot environments: 1–2 per 1,000 host-days. Investigation typically resolves to a legitimate multi-interface device the program had not classified.

Generic mass-storage with autorun-class payload heuristics. Out of scope for this detection. Falls to DLP and EDR file-content analysis.

Suppression and reclassification.

Allow-list entries reclassify the event to usb-attack-tool-authorized rather than suppressing it. The auditor sees both the alert and its reclassification, with the justification text. Suppression of an entire family is supported (for environments that legitimately use the Flipper, for example) but logged at the suppression configuration level for the same auditor visibility.

P1 — Confirmed-family match on a non-allow-listed host.

Treat as initial access. Pull the host out of the production VLAN via your NAC. Image the workstation; preserve volatile state. Interview the logged-in user; cross-reference with the red-team test schedule. Rubber Ducky and Flipper Zero are not legitimate productivity devices on a corporate endpoint. Verify whether the device is still attached (descriptor-disconnect event in the agent log will tell you).

P2 — Low-confidence BadUSB-pattern match.

Investigate before escalating. Compare the descriptor against the program's known-hardware inventory. Multi-interface USB devices (composite devices like docking stations, KVM hardware, programmable peripherals) can match the pattern legitimately. Add to allow-list with justification if the device is known and authorized.

USB-Ethernet adapter via switch-side detection.

The signal is a device-attached event on a port that previously hosted a known workstation. Investigate identical to a port-substitution event: walk the host, confirm whether the adapter is sanctioned (some programs allow USB-Ethernet for legitimate reasons; most do not). The pre-existing workstation is typically still attached and intact; the new adapter is the new device.

Cross-reference with red-team schedule.

If your program runs internal red teams or contracts with external penetration testers, maintain a calendar of authorized testing windows and accepted tooling. The agent's event includes a timestamp; correlate against the test schedule before walking the floor.