USB Baiting (Malicious Removable Media)
Also known as: USB drop attack, Found USB, Malicious USB, Removable media attack, Keystroke-injection device
A dropped or planted USB device that relies on curiosity: once plugged in, it either auto-runs code or pretends to be a keyboard and types commands, bypassing the network perimeter entirely.
Watch it in 60 seconds
How it works
USB baiting is the use of removable media left where a target will find it: a car park, a lobby, a conference bag, a parcel labelled with something tempting. It depends on curiosity or helpfulness, since the finder plugs the device in to see what it holds or to find its owner.
Two behaviours matter to a defender. A storage device may carry files or an autorun-style trigger that tries to launch code when mounted. A device that identifies itself as a human interface device, such as a keyboard, may be trusted by the operating system and send keystrokes with no prompt, which is why a drive that looks like storage can still act like a person typing.
The attack skips the network perimeter because the delivery is physical. Email filters, web proxies and firewalls never see it. The first evidence appears on the endpoint: a new device class enumerated, a shell or scripting process started within seconds of the plug-in, and outbound connections that follow.
Defence is mostly policy plus telemetry. Organisations restrict which device classes and vendors may connect, disable autorun, block removable storage where there is no business need, and alert on unexpected keyboard-class devices. Users are taught to hand found media to security rather than plug it in.
Walk through it
- 1A found USB, plugged in
- 2Read the device enumeration
- 3Confirm the verdict
- Scope other plug-ins
- Contain and harden
An employee tells the help desk they found a USB stick in the loading-bay car park and plugged it in to find the owner. Nothing opened for them, and the EDR raised an alert a few seconds later. Read the ticket and the alert before touching the device.
Unexpected device and script activity on WS-BAY-14
User: s.okafor (warehouse supervisor). Host: WS-BAY-14.
09:12:03 USB device connected (vendor 0x1209, product 0x0001, serial blank).
09:12:05 Command shell started with an encoded command line, parent is the Windows shell.
User statement: 'It was just a plain silver stick. Nothing showed up in Explorer.'
Spot it
- A new keyboard-class or other input device appearing on a host that has no business need for one, especially with a blank serial number.
- A command shell or scripting engine starting within seconds of a device connection, with an encoded or hidden-window command line.
- A removable-storage device mounting and an executable or script launching from the new drive letter.
- Outbound connections to a never-seen host from a process that began right after the device event.
- Several machines recording the same vendor and product id, or the same device moving between hosts.
EDR device telemetry
ts=2026-10-11T09:12:03Z host=WS-BAY-14 event=device_connect class=HID subclass=keyboard vid=0x1209 pid=0x0001 serial=none interfaces=1 storage=0EDR process telemetry
ts=2026-10-11T09:12:05Z host=WS-BAY-14 event=proc_start parent=explorer.exe image=cmd.exe cmdline_len=212 encoded=true
ts=2026-10-11T09:12:08Z host=WS-BAY-14 event=net_connect image=powershell.exe dst=203.0.113.50:443 reputation=unknownkqlMicrosoft Defender — shell launched shortly after a USB device connection
let usb = DeviceEvents
| where ActionType == "PnpDeviceConnected"
| project DeviceId, UsbTime = Timestamp, AdditionalFields;
DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe")
| join kind=inner usb on DeviceId
| where Timestamp between (UsbTime .. UsbTime + 15s)
| project Timestamp, DeviceName, FileName, ProcessCommandLineA fifteen second window is a starting point. Expect hits from docking stations and admin tooling; tune by allow-listing known device ids.
sigmaSigma — new keyboard-class device from an unapproved vendor id
detection:
selection:
EventType: 'DeviceConnected'
DeviceClass: 'Keyboard'
filter_approved:
VendorId|startswith: 'approved_vendor_list'
condition: selection and not filter_approved
level: mediumField names depend on your telemetry source; treat this as detection intent and map it to your schema.
Stop it
Control which devices may connect
Apply device-control policy that allows only approved device classes and vendor or product ids, and blocks removable storage and unknown input devices by default. This removes the attack path instead of trying to spot each device.
Disable autorun and automatic execution
Turn off autorun and autoplay for removable media on every endpoint, and prevent execution from removable drives. A mounted drive then holds files and nothing more.
Give users a safe path for found media
Teach staff never to plug in found devices and to hand them to security. Provide a clearly signposted drop-off and a sacrificial, isolated workstation or sandbox where analysts can inspect media.
Device-control policy intent
Hardened
DEFAULT removable-storage = block
DEFAULT new-input-device = alert
ALLOW device-class in (approved list) AND vendor-id in (approved list)
PREVENT execution from removable drives
SET autorun = disabledExpressed as policy intent; translate to your EDR or endpoint-management syntax.
- Disable autorun and autoplay for all removable media through group policy or endpoint management.
- Block removable storage by default and allow approved, encrypted devices by vendor and serial.
- Alert when an unapproved keyboard-class device appears on a managed endpoint.
- Physically disable or cap unused USB ports on kiosks, reception machines and shared workstations.
- Provide an isolated inspection workstation and a clear process for handing in found media.
If it already happened
Isolate the affected host from the network, keep the device untouched and bagged for evidence, and block the contacted address at DNS, proxy and firewall.
Review what the host executed after the plug-in, check for persistence and new accounts, and reimage the machine when you cannot prove it is clean. Reset credentials used on it.
Return the rebuilt host to service, confirm no related activity elsewhere, and restore normal device policy only after the controls below are in place.
Record the device ids as indicators, report any dropped devices found on site, and use the real incident in awareness training. Track how many found-media reports staff file.
Check yourself
1. A user plugs in a found USB stick and no drive appears, yet a shell runs seconds later. What does this most strongly suggest?
2. Which control most directly removes the risk from dropped USB devices across an organisation?
3. An employee hands you a USB stick they found in the car park. What is the safest next step?