Windows USB Forensics: Tracking External Device Connections

Forty-Seven USB Drives Walk Into a Network

A financial services client called us on a Friday afternoon. Their DLP solution flagged 14 GB of data copied to a removable device, but the employee had already left the building. The question was straightforward: which device, when exactly, and what else had been connected to that workstation over the past 90 days? Windows USB forensics gave us every answer within the hour.

Removable storage remains one of the most common exfiltration vectors mapped under MITRE ATT&CK Exfiltration Over Physical Medium (T1052). Despite every endpoint protection platform on the market, USB drives still walk out the door. The forensic artifacts Windows leaves behind are detailed, timestamped, and surprisingly durable. If you know where to look, the operating system has been keeping receipts since installation.

My position is direct: every IR playbook should include a USB triage procedure. Alert fatigue makes it easy to deprioritize removable media events, but these artifacts are low-noise and high-signal. Here is the systematic approach we use across our managed environments at SSE.

The Five Registry Keys That Tell the Full Story

Windows stores USB history across five registry locations. Each key holds a different piece of the puzzle. Merging them together reconstructs exactly how an external device was used, when it was connected, and who was logged in at the time.

1. USBSTOR — The Master Device List

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR is your starting point. Every USB storage device plugged into the system since OS installation appears here. Each entry records the vendor ID (manufacturer name), product ID, and the device serial number.

One important detail investigators miss: if the second character of the device serial number is an ampersand (&), the device does not have a hardware serial number. Windows generated that identifier internally, which means it cannot reliably track the same physical device across different machines. Note this in your findings — it is a legitimate caveat defense counsel will raise.

2. Enum\USB — Device Class Identification

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB provides the device class, vendor ID, and product ID at a lower level. This is where you determine whether the connected device was Mass Storage Class (MSC) or Media Transfer Protocol (MTP). The distinction matters. MSC devices mount as a drive letter and leave filesystem artifacts. MTP devices behave like a media player and interact through a different driver stack.

3. MountedDevices — Drive Letter Assignment

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices maps a device serial number to the drive letter or volume that Windows assigned when the USB was inserted. This tells you exactly which drive letter the suspect device received. Cross-reference this with file access logs and ShellBag entries to establish what was accessed on that volume.

4. MountPoints2 — User Attribution

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 is the key that answers who. This records which user account was logged in when a specific USB device was connected. The key also includes a Last Write Time for each device entry. During a recent engagement for an education sector client, this single artifact linked a specific staff account to an unauthorized device connection that occurred outside business hours.

5. EMDMgmt — Volume Serial Numbers

Software\Microsoft\Windows NT\CurrentVersion\EMDMgmt stores the volume serial number for the last mounted device. This is particularly useful when you need to correlate a specific formatted volume to a physical device already documented in USBSTOR.

Connection Timestamps: First, Last, and Everything Between

Knowing a device was connected is half the job. Knowing exactly when it was first and last connected completes the timeline. Windows stores these timestamps in specific registry values under SYSTEM\ControlSet001\Enum\USBSTOR\{VEN_PROD_VERSION}\{USB serial}.

The values that matter:

• 0064 — First connection timestamp
• 0066 — Last connection timestamp

However, the first-connected time has a caveat. In many Windows versions, the registry does not reliably store the initial connection timestamp. Instead, the first connected time is recorded in C:\Windows\inf\setupapi.dev.log. Search this file for the serial number from the USBSTOR entry, and you will find the exact datetime the driver was first installed for that device. Preserve this file early in your collection — it is a critical artifact that gets overlooked.

# PowerShell: Search setupapi.dev.log for a specific device serial
Select-String -Path "C:\Windows\inf\setupapi.dev.log" -Pattern "YOURSERIALHERE" -Context 3,3

For organizations running Windows 10 or Server 2016 and later, you can enable granular USB auditing through the DriverFrameworks-UserMode event log channel at Applications and Services Logs → Microsoft → Windows → DriverFrameworks-UserMode. The relevant Event IDs are 2003, 2005, 2010, and 2100. A single insertion of a never-before-seen USB flash drive generates up to 16 events. Event ID 2003 fires first, giving you a precise starting timestamp for the connection.

Building the Triage Playbook

Here is the 15-minute workflow we run across all client endpoints when USB exfiltration is suspected. We built this after handling enough incidents to know which steps actually move the needle versus which ones burn time.

1. Collect the SYSTEM hive — Export or image SYSTEM from C:\Windows\System32\config. This gives you USBSTOR, Enum\USB, and MountedDevices in one artifact.
2. Collect NTUSER.DAT — Pull the hive for every user profile on the machine. MountPoints2 lives here, and you need it for user attribution.
3. Preserve setupapi.dev.log — Copy C:\Windows\inf\setupapi.dev.log before anything else modifies it.
4. Export event logs — Pull the System event log and the DriverFrameworks-UserMode channel if auditing was enabled.
5. Parse and correlate — Use a tool like NirSoft USBDeview or Eric Zimmerman’s Registry Explorer to pull structured data from the hives. Match serial numbers across all five registry keys to build the complete device profile.

# PowerShell: Quick enumeration of USBSTOR entries on a live system
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Enum\USBSTOR\*\*" | 
  Select-Object FriendlyName, Mfg, Service, PSChildName | 
  Format-Table -AutoSize

For offline analysis of registry hives, Eric Zimmerman’s RECmd with the BatchExamples configs will parse USB artifacts into timeline-friendly CSV output. We run this configuration across all our managed endpoints when incident response kicks off.

Correlating with File Access Evidence

Registry artifacts prove a device was connected. To prove what was accessed on that device, you need two more artifact sources. ShellBag entries at HKCU\Software\Microsoft\Windows\Shell indicate which folders were browsed through Explorer — though they record folder access, not individual files. The Most Recently Used list at HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU can show recently accessed items, including files opened from or saved to the removable volume.

When we handled an insider threat investigation for a law firm, the combination of MountPoints2 timestamps and ShellBag entries placed a specific attorney’s account browsing a USB-mounted directory containing privileged client files at 11:47 PM on a Saturday. The registry told us who, when, and what path. The DLP logs told us how much data moved. Together, they built a defensible timeline. If your organization needs help building this kind of incident response capability, reach out to our team.

Scaling USB Monitoring Across the Enterprise

Manual registry analysis works for individual incident response. It does not scale to 500 endpoints. For proactive monitoring, forward DriverFrameworks-UserMode events to your SIEM and build detection rules around unauthorized device classes.

// KQL: Detect USB mass storage connections on monitored endpoints
DeviceEvents
| where ActionType == "PnpDeviceConnected"
| where DeviceDescription has "USB Mass Storage"
| where DeviceId !in (approved_device_list)
| project Timestamp, DeviceName, DeviceId, InitiatingProcessAccountName
| sort by Timestamp desc

This detection maps directly to MITRE ATT&CK T1052.001 (Exfiltration Over USB). Pair it with a Group Policy that restricts removable storage to approved device IDs, and you shift from reactive forensics to proactive prevention. NIST’s Cybersecurity Framework maps this control under the Protect function — specifically PR.PT-2 for removable media policies.

For organizations already using Microsoft Defender for Endpoint, the device control feature handles USB whitelisting natively. The Microsoft documentation covers policy deployment through Intune or Group Policy. We have deployed this across 200+ endpoints for a client in the healthcare sector and reduced unauthorized USB connections to near zero within 30 days.

If your environment includes systems where forensic data integrity is critical, make sure your cloud backup service covers endpoint images. Having a known-good baseline image to compare against makes anomaly detection during USB investigations significantly faster. Similarly, for organizations under regulatory requirements, maintaining email backup alongside endpoint forensic readiness ensures you can reconstruct the full communication trail around a suspected exfiltration event.

What USB Forensics Cannot Tell You

No forensic method is complete, and USB artifact analysis has real limitations. Registry entries prove a device was connected — they do not prove what files were copied. You need filesystem timestamps, jump lists, and potentially USN journal entries to establish file-level activity. If the user formatted the drive after use, volume serial numbers may not match previous records.

Additionally, sophisticated actors can use USB devices that spoof serial numbers or use MTP mode to avoid leaving the same artifact trail as standard mass storage devices. Anti-forensics tools exist that specifically target setupapi.dev.log and USBSTOR entries. Acknowledge these gaps in your reports. Overstating what the evidence proves undermines credibility in legal proceedings.

Related reading: if you are investigating ransomware delivery via USB, the same registry keys apply — the initial access vector through a removable device will be documented in USBSTOR before encryption begins. And for scripting your collection process, solid PowerShell module management makes the difference between a repeatable workflow and a one-off script that breaks on the next engagement.

The Practical Takeaway

Windows records USB device connections across five registry keys, a setup log, and optionally the event log system. No single artifact tells the whole story. Your triage playbook should collect all five registry paths, preserve setupapi.dev.log, and correlate device serial numbers across sources to build a defensible timeline. For proactive defense, forward USB events to your SIEM and enforce device control policies. Mean time to detect drops from hours to minutes when the right correlation rules are already running.