A BadUSB attack starts with a device that lies about what it is. It looks like an ordinary flash drive, but the tiny controller chip inside has been reprogrammed to tell your computer it is a keyboard. The moment you plug it in, it starts typing commands on its own, far faster than any person could, and the machine obeys because keyboards are trusted by design. There is no virus file to find, because the trick is not a file at all. It is the device claiming an identity it should never have.
What does HID mean, and why does your computer trust keyboards?
HID stands for Human Interface Device. It is the standard category the USB specification uses for the things a person operates directly: keyboards, mice, game controllers, and similar input hardware. When you plug one in, the device introduces itself with a small description of what it is and what it can send. Your operating system reads that description, sees the word keyboard, and loads a generic driver that is already built into the system. No installation, no prompt, no scan. You expect a keyboard to send keystrokes, so a keyboard is allowed to send keystrokes the instant it arrives.
That trust is deliberate and it is also the whole problem. A keyboard is the one peripheral that is assumed to speak for the human sitting at the desk. Whatever it types, the computer treats as your intent. There is no meaningful check on whether a keyboard is real, whether a human is actually pressing keys, or whether the typing speed makes any sense for a person. The identity a USB device announces is taken at face value, and the identity is exactly what a BadUSB attack forges.
How a BadUSB attack forges an identity at the firmware level
Every USB device runs a small piece of software of its own, called firmware, on its controller chip. That firmware decides the descriptor the device shows the host: this is a mass storage device, or this is a keyboard, or both. On many cheap controllers that firmware can be rewritten. Once it is rewritten, the same physical stick that used to say flash drive can instead say keyboard, and it will hold that story every time it is plugged into any machine.
Picture a made up example. An attacker leaves a plain looking USB stick in the parking lot of an office we will call Acme. A curious employee finds it, plugs it into a work laptop to see who it belongs to, and expects a folder of files. Instead the stick has been reprogrammed. Its firmware announces a keyboard, the laptop loads the trusted keyboard driver without asking, and the device fires off a short burst of keystrokes it had stored on board. To the laptop, a person just sat down and typed very quickly. Nothing about the traffic looks wrong, because as far as the operating system knows, a keyboard did what keyboards do.
There is no malware to scan for. The attack is the device claiming to be a keyboard, and your computer has no habit of doubting a keyboard.
Why antivirus does not see it
Antivirus works by inspecting files and processes for known bad patterns. A BadUSB attack hands it nothing to inspect. The malicious part lives in the device firmware, not on disk, and the firmware never copies a suspect file onto your machine. What reaches the computer is a stream of keystrokes, which is the most normal input a computer can receive. You cannot quarantine a key press. You cannot flag a keyboard as malware without flagging every keyboard.
This is why the defense cannot be a scanner. The failure is a trust decision made before any file exists: the decision to believe a device’s claim about its own identity. Fixing it means changing who is allowed to become a trusted keyboard, and under what conditions, rather than hunting for something to delete.
How is this different from juice jacking?
It is easy to lump every USB threat together, but these are two different problems and the fix for one does not fix the other. Juice jacking is about a charging port or cable that carries data as well as power, so a public charging station could try to pull files off your phone or push something onto it while it charges. It abuses the fact that one USB connector moves both power and data. We cover that risk on its own in juice jacking explained.
A BadUSB attack is not about power or file transfer. It is about identity. The device is not reading your data or sneaking a file across, it is pretending to be a class of hardware your computer trusts and then acting as that hardware. One is a data over power problem. The other is an identity problem. A data blocker that strips the data pins can help against juice jacking, but a device you deliberately plug in as a keyboard still gets to be a keyboard.
How do you defend against it?
- Never plug in a device you did not buy. A found stick, a giveaway drive, a cable of unknown origin. The single most reliable defense is refusing the physical introduction in the first place.
- Use USB device control and allowlisting. Tools such as USBGuard on Linux let you approve devices by their properties and block everything else by default, so a brand new keyboard appearing out of nowhere is refused rather than trusted.
- Require confirmation before a new keyboard is trusted. A policy where a freshly connected input device has to be approved by the person at the machine removes the whole point of a device that types the instant it is plugged in.
- Disable unused USB ports or fit port blockers. If a port does not need to accept input hardware, close it. Fewer open ports means fewer places a forged keyboard can introduce itself.
- Lock your screen and use short timeouts. A device that types into a locked machine reaches almost nothing. Short idle timeouts shrink the window in which a burst of typed commands can land on a desktop left open.
- Treat trust as physical, not just digital. The same mindset that governs an evil maid attack applies here: once someone can touch your hardware, software controls alone are not enough.
Peripherals earn trust by claiming an identity, and that claim is rarely checked. The same theme runs through how Bluetooth LE pairing breaks, where a trusted wireless channel can be set up more loosely than people assume. The lesson under all of it is one worth carrying into software too: an identity a system merely announces is not the same as an identity a system has verified. That gap between assumed trust and proven trust is exactly the kind of assumption we care about testing, and you can read more about how we think on our about page.
Frequently asked questions
What is a BadUSB attack?
It is an attack where the firmware inside a USB device is reprogrammed so the device lies about what it is. A stick that looks like a flash drive tells your computer it is a keyboard, and the moment you plug it in it types a burst of commands the computer trusts, because keyboards are trusted by design.
What does HID mean and why does it matter here?
HID stands for Human Interface Device, the USB category for input hardware like keyboards and mice. Your operating system loads a built in driver for a keyboard automatically and lets it send keystrokes right away. A BadUSB attack abuses that trust by announcing itself as a keyboard when it is really something else.
Why does antivirus not catch a BadUSB attack?
Because there is no malicious file to scan. The trick lives in the device firmware, and what reaches your computer is a stream of keystrokes, which is the most normal input a machine can receive. You cannot flag a keyboard as malware without flagging every keyboard, so the defense has to be about controlling which devices are trusted, not scanning for files.
How is a BadUSB attack different from juice jacking?
Juice jacking is about a charging port or cable that moves data as well as power, so it might read or plant files while your phone charges. A BadUSB attack is not about power or file transfer at all. It is an identity problem, where the device pretends to be a class of hardware the computer trusts and then acts as that hardware.
How do you defend against a BadUSB attack?
Never plug in a device you did not buy, especially a found or giveaway stick. Use USB device control and allowlisting such as USBGuard, require confirmation before a new input device is trusted, disable unused ports or fit port blockers, and keep your screen locked with short idle timeouts so typed commands reach almost nothing.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.