2.4 External Drives, USB Drives, and Media Risks
Enumeration: The Host Believes the Device's Own Résumé
The moment you insert a USB device, the host reads its descriptors: vendor and product IDs (for example 0781:5567), device class, and endpoint list. The kernel then loads whatever driver matches those claims. Nothing signs those claims. A device can declare itself a USB Human Interface Device keyboard, or a composite device exposing both a mass-storage interface and a CDC-ACM serial port, and the host will load hid-generic and trust it. That single design gap is the root cause of nearly every USB threat, because a keyboard is treated as an unprivileged but fully trusted input source.
BadUSB and HID Keystroke Injection
BadUSB attacks modify the flash controller's own firmware rather than the file system, so a scan of the visible storage shows clean files while the device behaves differently. Mass-production controller tools let an attacker rewrite the firmware of a stock thumb drive, changing its reported class from mass storage to HID keyboard. Once inserted, the device is polled every 8 ms and can inject tens of keystrokes per second, far faster than any human reaction. A typical payload chain on Windows is Win+R, then powershell -enc <base64>, which decodes and runs a launcher without a file ever touching disk; the macOS equivalent types into Spotlight to open a Terminal and run a one-liner. Because the input looks exactly like a legitimate keyboard, the only reliable defense is a policy that names known devices: usbguard list-devices and usbguard block-device <id>, or a Group Policy rule denying new removable devices.
Auto-Run Trees, Keyloggers, and Electrical Attacks
The lower-tech branch still works. Legacy autorun.inf execution is disabled by default on modern Windows for most media, but mounting still lets a user click a decoy, and macOS quarantines (yet still opens) disk images from downloads. Folder-structure malware abuses icon handling: the 2010 .LNK parsing flaw (CVE-2010-2568) let a malicious icon run code just by Explorer rendering a folder, a technique Stuxnet paired with a print-spooler exploit over USB. Hardware variants sit inline: an intermediary logged-keyboard dongle captures keystrokes between a real keyboard and the host, and public USB charging ports expose the data lines ("juice jacking"), which is why data-only USB cables or a blocking adapter matter on the go. At the extreme, a "USB Killer" presents charged capacitors to the VBUS line and destroys the port, so treat unknown ports as physically unsafe, not just logically unsafe.
Architecture Diagram
Key Takeaways
- USB enumeration trusts device-declared descriptors, so any device can claim to be a keyboard or a composite device.
- BadUSB lives in the controller firmware, meaning file scans see a clean drive while behavior is hostile.
- HID injection types payloads in seconds; counter it with USBGuard or policy-based device allow-lists, not attention.
- Auto-run defaults are safer today, but mounted media, DMGs, and icon-parsing bugs still need clicking hygiene and patching.
- Assume physical hostility: inline keyloggers, data-line sniffing at public chargers, and voltage attacks justify data-only cables and port policy.