USB Device Forensics: Tracing Drives, Users and Files

This guide takes you from "a USB drive was plugged in" to a defensible statement about which device it was, when it was connected, which user was logged on, and which files were opened from it. It covers the registry, text logs and event logs Windows 10 and 11 leave behind, what changed between versions, and a step-by-step workflow you can run on any case.

The identifiers you pivot on

USB investigations are an exercise in joining records that each hold a different identifier. Know these four before you start:

The device serial identifies the hardware. The VSN identifies the file system on it, and it is the only identifier that LNK files and Jump Lists record. Most of the work is linking the two.

Device identification in the SYSTEM hive

All paths below are under SYSTEM\ControlSet00x\; check Select\Current to know which control set was active.

Enum\USBSTOR

Mass storage devices appear under Enum\USBSTOR\Disk&Ven_<vendor>&Prod_<product>&Rev_<revision>\<serial>. For example:

Enum\USBSTOR\Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00\4C530001230518115455&0

The &0 suffix is a logical unit number added by Windows, not part of the hardware serial. Useful values in the serial key include FriendlyName and ContainerID.

If the second character of the serial is & (for example 7&2a1b3c4d&0), the device did not expose a unique serial number and Windows generated one. That ID is not stable across hosts, so you cannot use it to say "the same stick was plugged into both machines".

Enum\USB

Enum\USB\VID_xxxx&PID_yyyy\<serial> holds every USB device, not only storage: keyboards, phones, hubs. The serial here matches the USBSTOR serial (without the &0), which gives you the VID/PID for a storage device. ContainerID links related entries across Enum subtrees.

Connection timestamps (Windows 8 and later)

Under each device instance key, the Properties\{83da6326-97a6-4088-9453-a1923f573b29} subkey holds numbered subkeys whose value is a FILETIME in UTC:

These keep only the first and most recent events. On a live system the Properties key is readable only with SYSTEM privileges, which is one reason to work from a collected hive. On Windows 7, fall back to key LastWrite times and the setupapi log, and treat them as approximations.

MountedDevices

SYSTEM\MountedDevices maps drive letters (\DosDevices\E:) and volume GUIDs (\??\Volume{GUID}) to devices. For removable media the value data is a UTF-16 string containing the USBSTOR device path and serial, which lets you tie a serial to a drive letter and, crucially, to a volume GUID. Drive letters are reassigned over time, so the current letter says nothing about which letter the device had during the incident.

SOFTWARE hive: Portable Devices and EMDMgmt

SOFTWARE\Microsoft\Windows Portable Devices\Devices lists devices with a FriendlyName, which for storage is often the volume label the user saw, and for phones the device name ("Galaxy S23"). The subkey name embeds the device serial.

SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt is maintained by ReadyBoost. Its subkey names contain the device path, the volume label and a trailing number that is the VSN in decimal; convert it to hex to compare with LNK files. Availability varies: EMDMgmt is typically not populated when the system drive is an SSD, which covers most modern machines, so do not rely on it.

# Convert an EMDMgmt decimal volume serial to the XXXX-XXXX form used by LNK parsers
$vsn = 2767329728
'{0:X8}' -f $vsn -replace '(.{4})(.{4})', '$1-$2'

User attribution with MountPoints2

The SYSTEM and SOFTWARE hives are machine-wide. To tie a device to a person, open each user's NTUSER.DAT and look at:

NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{volume GUID}

If the volume GUID from MountedDevices appears here, the volume was mounted while that user was logged on interactively. The subkey LastWrite approximates the last time it was mounted in that user's session. Map the profile to its SID through ProfileList and confirm the logon with Security events. MountPoints2 also records network shares as ##server#share, which helps when data left by another route.

setupapi.dev.log: first installation

C:\Windows\INF\setupapi.dev.log (on XP, C:\Windows\setupapi.log) records driver installation. The first time a device is seen, you get a block like:

>>>  [Device Install (Hardware initiated) - USBSTOR\Disk&Ven_SanDisk&Prod_Cruzer_Blade&Rev_1.00\4C530001230518115455&0]
>>>  Section start 2026/09/14 09:12:33.412

The section start time is in the host's local time, unlike the registry, so convert it (see UTC and local time). The log rolls over into setupapi.dev.<date>.log files on some systems and is recreated by feature updates, so collect every setupapi*.log in the folder.

Select-String -Path C:\Windows\INF\setupapi.dev*.log -Pattern 'USBSTOR' -Context 0,1

Event logs: every connection, not just first and last

The registry keeps first and last. Event logs give you individual connections, as long as they have not rolled over.

Partition/Diagnostic 1006 is the most valuable of these because it can include the volume boot record of each partition. The VSN sits at a fixed offset in the VBR (0x43 for FAT32, 0x48 for NTFS, 0x64 for exFAT), so you can recover the VSN from the event and link a hardware serial directly to LNK files, even when EMDMgmt is empty. The channel is small and rolls over quickly, so check its oldest record before drawing conclusions from absence. Exact field names vary by build, so verify against the event XML rather than trusting a single parser's column names.

# Parse only the USB-relevant events from a collected log folder
EvtxECmd.exe -d E:\case\C\Windows\System32\winevt\Logs --csv E:\out\evtx --inc 1006,400,410,2003,2100,2102,6416

# Quick look on a live system
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-Partition/Diagnostic'; Id = 1006 } |
  Select-Object TimeCreated, Id, Message -First 20

The EVTX Parser is handy for inspecting a single exported channel in the browser.

From device to files: VSN, LNK, Jump Lists and ShellBags

Once you have the VSN, pivot into the user activity artifacts (covered in depth in ShellBags, LNK files and Jump Lists):

• LNK files: filter LECmd output on DriveSerialNumber equal to the VSN and DriveType removable. Each hit is a file opened from that volume, with the path, the target's timestamps and the shortcut's own created/modified times.
• Jump Lists: the same fields in JLECmd output, plus the application used and the DestList last access time.
• ShellBags: folders browsed on the drive letter the device had during the connection window. ShellBags do not store the VSN, so link them by drive letter and time.
• OpenSavePidlMRU and LastVisitedPidlMRU: files saved to, or selected from, the drive letter in open/save dialogs.

# LNK and Jump List entries on a given volume serial
LECmd.exe -d E:\case\C\Users --csv E:\out\lnk
JLECmd.exe -d E:\case\C\Users --csv E:\out\jl
Import-Csv (Get-ChildItem E:\out\lnk\*.csv).FullName | Where-Object { $_.DriveSerialNumber -match 'A4F219C0|A4F2-19C0' }

Note what this does and does not show. A LNK proves a file was opened from the drive. It does not prove a file was copied to it; copying through Explorer creates no LNK. For copies, look at the $MFT and USN journal on the source volume, OpenSavePidlMRU for "Save As" to the drive, and, if you have the device itself, the file system timestamps on it.

When you have the device itself

If the drive is seized, close the loop from the other side. Connect it through a write blocker and image it before anything else. Read the hardware serial from the USB descriptors (on a Linux examination host, lsusb -v or udevadm info shows iSerial) and compare it with USBSTOR. Read the VSN from the VBR of each partition and compare it with the LNK and Jump List hits. Then check the file system on the device: files whose names match the LNK targets, and their created times on the device, which on a copy typically reflect when the copy landed there. A matching serial, a matching VSN and matching file names turn a registry inference into physical corroboration. If the VSN does not match but the serial does, the drive was reformatted after the files were opened.

# Hardware serial and VID/PID of an attached device, from a Linux examination host
lsusb -v 2>/dev/null | grep -E 'idVendor|idProduct|iSerial'

MTP phones and cameras

Phones connected in file transfer mode use Media Transfer Protocol. They appear under Enum\USB (and under a SWD\WPDBUSENUM entry), in Windows Portable Devices with their friendly name, and in Kernel-PnP events, but not under USBSTOR and without a drive letter or VSN. ShellBags are the best record of browsing: paths such as Galaxy S23\Internal storage\DCIM\Camera. LNK files for items opened directly from an MTP device are less consistent than for mass storage, so do not treat their absence as meaningful.

Building the exfiltration narrative

A convincing USB exfiltration finding usually has five parts:

1. The device: vendor, product, serial (unique, not &-generated), VID/PID.
2. The window: first install, connection times from 1006 or Kernel-PnP, last arrival and removal from 0066/0067.
3. The user: MountPoints2 in their profile, a matching interactive logon.
4. The data: LNK and Jump List entries with the device VSN, ShellBags on its drive letter, dialog MRUs pointing to it, and source-side file system activity inside the window.
5. The absence of alternatives: no other user session, no remote access at that time.

Write each timestamp with its meaning and time zone, and state the limits: "last arrival" is the last one, not the only one.

Pitfalls

• Feature updates wipe history. Major Windows upgrades can remove USBSTOR entries and recreate setupapi logs. Check Windows.old, volume shadow copies and SYSTEM\Setup\Upgrade\Pnp\CurrentControlSet\Control\DeviceMigration before concluding a device was never used.
• Assuming the current drive letter. Letters change; use the mapping valid during the window.
• Comparing Windows-generated serials across hosts. They are not hardware identifiers.
• Mixing time zones. Registry and events are UTC; setupapi is local time.
• Expecting DriverFrameworks-UserMode logs. They are off by default on recent builds.
• Treating a reformatted drive as a different drive. The VSN changes on format; the hardware serial does not.
• Not parsing registry transaction logs. Recent device activity may only be in SYSTEM.LOG1/.LOG2.

Tools

• Registry Explorer and RECmd (Eric Zimmerman): bookmarks for USBSTOR, MountedDevices and MountPoints2; RECmd batch files dump them to CSV.
• EvtxECmd: maps for Partition/Diagnostic and Kernel-PnP events.
• USB Detective: automates correlation across registry, setupapi, events, LNK and Jump Lists; the commercial editions go further than the community edition.
• RegRipper: usbstor, usb, mountdev, mp2 plugins for quick text reports.
• The browser parsers on this site, such as the Registry Parser, for single hives.

RECmd.exe -d E:\case\C --bn .\BatchExamples\RECmd_Batch_MC.reb --csv E:\out\registry

Step-by-step workflow

1. Collect: SYSTEM, SOFTWARE and their logs, every NTUSER.DAT, C:\Windows\INF\setupapi*.log, the event logs, each profile's Recent folder, and shadow copies. The triage guide lists the KAPE targets.
2. Inventory devices: list USBSTOR and USB entries with serials, VID/PID and friendly names; flag Windows-generated serials.
3. Date them: 0064 to 0067, setupapi first install (converted to UTC), then every 1006 and Kernel-PnP event.
4. Map volumes: MountedDevices for drive letters and volume GUIDs; VSN from 1006 VBR data or EMDMgmt.
5. Attribute: find the volume GUID in each user's MountPoints2, map the profile to a SID, confirm the logon.
6. Find the files: LNK and Jump List entries matching the VSN, ShellBags on the drive letter, dialog MRUs, and source-side $MFT/USN activity inside the connection window.
7. Report: a UTC timeline with each timestamp's meaning, the identifiers linking each step, and the gaps you could not close.

For the broader registry context behind these keys, see Windows registry forensics, and for the full USB key reference, the USB devices cheat sheet.