USB Device Forensics: Devices, Users and File Transfers

When a USB drive is suspected in a data theft or malware case, investigators often hold a dozen artefacts that each answer a different question, and the case goes wrong when one artefact is made to answer all of them. The registry can tell you which device was seen and roughly when, the event logs can tell you when it arrived and which account was signed in, and the user's file activity can tell you what was opened from it, but no single source proves that a specific file was copied to a specific drive by a specific person. This guide sets out a USB investigation workflow for Windows endpoints: the identifiers that tie a device together across artefacts, the registry keys, logs and timestamps to collect, how to attribute activity to a user, how to reason about file transfers, and where endpoint telemetry fills the gaps. It is written for incident responders, forensic analysts and insider risk investigators. It builds on the Windows Forensic Artefacts Guide, which covers the general artefacts, and does not repeat it.

Key takeaways

Build the device identity first. Vendor ID, product ID, the Windows instance identifier, the volume GUID, the drive letter and the volume serial number are the keys that join registry, log and user artefacts into one device story.
The "serial number" in the registry is a Windows value, not a verified manufacturer serial. Enclosures, docks and adapters report their own identifiers, so check against the physical device before you state it as fact.
Connection times come from several places with different clocks. Registry timestamps are UTC FILETIME values, setupapi.dev.log is local time, and key last-write times record the last change to a key, not necessarily the event you care about.
User attribution needs per-user evidence. MountPoints2 in the user's NTUSER.DAT, the Subject fields of event 6416 and the user's LNK files and Jump Lists place a person at the device; machine-wide keys do not.
Host artefacts rarely prove a copy. Files opened from the drive leave traces; files written to it often do not, so plan for endpoint DLP or device control telemetry before the incident, not after.

The questions a USB investigation must answer

Write the questions down before collecting anything. Each has its own best evidence, and confusing them is the root of most overstated findings.

Question	Best evidence on Windows	What it cannot tell you
Was this type of device ever connected?	Enum\USB and Enum\USBSTOR subkeys, setupapi.dev.log device install sections	Which user, or how many times
Is it the same physical device we seized?	Vendor ID, product ID and instance identifier, compared with the physical device and vendor tools	Certainty where the device reports no unique serial or sits in an enclosure
When was it first and last connected?	Properties subkeys under the device instance (first install, last arrival, last removal), setupapi.dev.log, event 6416, Partition/Diagnostic 1006	Every intermediate connection; only some sources keep history
Which drive letter and volume did it get?	MountedDevices, ParentIdPrefix, DeviceClasses volume interface keys	Whether the letter was later reused by another device
Which user was involved?	MountPoints2 in NTUSER.DAT, Subject fields of event 6416, the user's LNK files and Jump Lists	Who was physically at the keyboard
What was opened from or copied to it?	LNK files and Jump Lists for opened files, ShellBags for browsed folders, endpoint DLP and device control events for writes	Writes, from host artefacts alone, in most cases

Building the device identity

A USB storage device appears in Windows at several layers, and each layer records a different identifier. Collect all of them and put them in one row per device before you build a timeline.

Device instance ID: Plug and Play assigns every device node a device instance ID that persists across restarts. Microsoft's USB documentation shows the format USB\VID_<vid>&PID_<pid>\<serial or port-based ID>. When a device has no serial number, or the IgnoreHWSerNum flag is set for it under HKLM\SYSTEM\CurrentControlSet\Control\usbflags\<vvvvpppprrrr>, Windows generates a port-based ID instead, so the same stick in a different port can look like a new device.
Vendor and product IDs: the four-digit hexadecimal VID and PID identify the hardware type, not the unit. Many units share them.
Storage class identity: under HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR the class key names the vendor, product and revision (for example Disk&Ven_..&Prod_..&Rev_..) and each subkey below it is an instance. The instance key's FriendlyName and ParentIdPrefix values are the ones you will use later.
Volume GUID and drive letter: HKLM\SYSTEM\MountedDevices maps \DosDevices\X: drive letters and \??\Volume{GUID} names to binary data that, for USB storage, contains the device path or the ParentIdPrefix. That is how you tie a device to a letter and a volume GUID.
Volume serial number: the file system's volume serial number is assigned when the volume is formatted. It is recorded in LNK files and Jump Lists for files opened from the volume, which makes it the bridge between the device and the user's file activity. Reformatting changes it.

Treat serial numbers with care. SANS testing found that the value under USBSTOR that investigators call the serial number does not always match the manufacturer's label: SATA to USB adapters reported different values for the same drive, a portable drive reported the enclosure's serial rather than the internal disk's, and several drives behind one dock reported an identical value. The same research showed that the long-repeated rule that an ampersand in the second character always means a Windows-generated ID is not reliable. The value is consistent for a given device on a given system, so it is a good tracking identifier, but describe it as the identifier Windows recorded and verify it against the physical device before calling it the manufacturer serial in a report. The SCSI enumerator key can also hold USB-attached disks, so do not stop at USBSTOR.

Registry artefacts and their timestamps

The SYSTEM, SOFTWARE and NTUSER.DAT hives hold most of the device history. Parse offline hives with a tool that replays the transaction logs, or recent changes will be missing. See the EZ Tools Guide for registry parsing tools.

Artefact	Location	What it gives you	Timestamp notes
USB enumerator	SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_xxxx\<instance>	Every USB device, storage or not (keyboards, phones, network adapters)	Key last-write times change for many reasons; do not read them as connection times
USB storage	SYSTEM\CurrentControlSet\Enum\USBSTOR\<class>\<instance>	Vendor, product, revision, instance identifier, FriendlyName, ParentIdPrefix	See the Properties subkeys below
Device property times	...\<instance>\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\0064, 0065, 0066, 0067	First install date, install date, last arrival, last removal	FILETIME values in UTC, as parsed by RegRipper's usbstor plugin
Mounted devices	SYSTEM\MountedDevices	Drive letter and volume GUID to device mapping	A letter can be reassigned to a later device; check every entry
Device interface classes	SYSTEM\CurrentControlSet\Control\DeviceClasses\{53f56307-b6bf-11d0-94f2-00a0c91efb8b} (disk) and {53f5630d-b6bf-11d0-94f2-00a0c91efb8b} (volume)	Disk and volume interfaces carrying the instance ID and ParentIdPrefix	Last-write time of the subkey approximates a connection in the current boot
Portable devices	SOFTWARE\Microsoft\Windows Portable Devices\Devices	Friendly names, often the volume label, for media and storage devices	Useful to match a label the suspect may recognise
Per-user mount points	NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2	Volume GUIDs the user's session saw, plus mapped network shares	The user-specific link; last-write time of each GUID subkey supports the timeline

Do not trust a single timestamp. The four Properties values are the most direct record of install, arrival and removal, but they hold only the latest arrival and removal. Corroborate with the logs below, and record which source each time in your report came from.

Log sources: setupapi, Security and Partition/Diagnostic

Logs supply history the registry overwrites, and the Security log supplies a user.

Log	Event or entry	What it records	Watch out for
%SystemRoot%\INF\setupapi.dev.log	Device install section beginning `>>> [Device Install ...]` followed by a `Section start` line with a yyyy/mm/dd hh:mm:ss.mmm time	First driver installation for a device, with its hardware IDs: a strong first-connection marker	Times are local system time; convert using the TimeZoneInformation key before merging with UTC sources. Rotated older logs may sit beside it
Security.evtx	6416: A new external device was recognized by the System	Device ID (instance path), Device Name, Class ID and Class Name, Vendor IDs, Compatible IDs, Location Information, plus Subject SID, account and Logon ID	Only logged when the Audit PNP Activity subcategory is enabled; Version 1 fields arrived in Windows 10 1511. Subject is usually SYSTEM; Microsoft recommends reporting when it is not
Security.evtx	6419 to 6424	Requests to disable or enable a device, and device installations forbidden or allowed by policy	Shows device control decisions, which are evidence of attempts
Microsoft-Windows-Partition/Diagnostic.evtx	1006	Manufacturer, model and serial values, and raw partition table, MFT and VBR data for each connection	Serial may reflect an enclosure; still one of the best per-connection histories on Windows 10 and 11
DriverFrameworks-UserMode/Operational	Device connection events	Arrival and removal for devices using user-mode drivers	Check whether the channel was enabled on the host before relying on its absence

Use the Logon ID in event 6416 to join to logon event 4624 and the session it belongs to. That gives you the account that was signed in when the device was recognised, which is stronger than inferring a user from machine-wide registry keys.

Attributing activity to a user

Machine artefacts say a device was here. Courts, HR panels and management will ask who used it. Build attribution from several independent sources:

Find the volume GUID in a user's MountPoints2. A match in one user's NTUSER.DAT, and not in others, puts the device in that user's session.
Match the volume serial number in the user's LNK files and Jump Lists. These record the volume type, serial and label of the volume a file was opened from, plus the file path and timestamps. Files that lived on drive E: of a removable volume with the target serial are direct evidence of access by that profile. See the Windows Forensic Artefacts Guide for how LNK files and Jump Lists are structured.
Check ShellBags for folders browsed on the removable volume. They show folder names the user navigated, which often reveal the purpose of the drive.
Join event 6416 and 4624 by Logon ID for the account and logon type at the moment of recognition.
Corroborate with non-host sources: badge records, CCTV, VPN or remote session logs. A remote session at the time of connection changes the story completely.

Shared accounts and kiosk devices defeat attribution. Where several people use one profile, say so in the report rather than naming the most likely person. The Insider Data Theft Guide covers the wider evidence picture for staff cases.

Reasoning about file transfers

Most USB cases turn on what left the organisation, and this is where host artefacts are weakest. Be explicit about what each source supports.

Evidence	Supports	Does not support
LNK or Jump List entry pointing at a file on the removable volume	The file existed on the volume and was opened by that profile	That it was copied there from this host
Source file last-access time changes (where enabled)	The file was read at roughly that time	Where the data went; backups and antivirus also read files
Recent archive creation (ZIP or 7z) on the host just before the device arrived	Staging behaviour worth explaining	Transfer, without a link to the volume
Analysis of the seized device itself (MFT, file creation times, folder structure)	What files are on it, when they were created on that volume	Which host they came from, unless metadata or paths link back
Endpoint DLP or device control event with file name, size and device serial	A write or attempted write of that file to that device, by that account	Content beyond what the policy captured

If you have the device, image it. Imaging the drive with a write blocker and hashing it lets you compare file creation times on the USB volume with the host timeline. Times on a copy reflect when the copy was created on the destination volume, so a cluster of creation times on the stick that matches the arrival time from event 6416 is strong corroboration. See the Disk Imaging and Forensic Acquisition Guide and the File System Forensics Guide.

Endpoint telemetry closes the gap. Device control and endpoint DLP tools record writes that the operating system does not. For example, Microsoft Defender for Endpoint raises the RemovableStoragePolicyTriggered action type in the DeviceEvents table when a removable storage policy fires, with BusType, ClassGuid, DeviceInstanceId, MediaName, ProductId, VendorId, SerialNumber and the policy verdict in AdditionalFields, alongside FolderPath and FileSize. Advanced hunting returns at most 300 of these events per device per day, so use the device control report for heavy users. Other endpoint platforms expose equivalent fields; confirm what yours records and how long it keeps it before you need it. Controls themselves are covered in the Removable Media and USB Control Guide.

Investigation workflow

Preserve first. Collect volatile data if the host is live and the device is still attached, then acquire the SYSTEM, SOFTWARE, every NTUSER.DAT and UsrClass.dat with their transaction logs, setupapi.dev.log and its rotated copies, the Security, System and Partition/Diagnostic event logs, LNK files, Jump Lists and $MFT. Record hashes and chain of custody using the Chain of Custody Form Template.
Pull endpoint telemetry before it ages out. Export device control, DLP and EDR events for the host and account for the full period of interest on day one.
Build the device table. One row per device: VID, PID, instance identifier, FriendlyName, ParentIdPrefix, volume GUID, drive letters, volume serial numbers, first install, last arrival, last removal.
Build the connection timeline. Merge setupapi first installs, Properties times, 6416 events and Partition/Diagnostic 1006 events in UTC, with the source and original time zone in a column. Plaso will parse most of these into one super-timeline; see the Forensic Timeline Analysis Guide.
Attribute. Work through MountPoints2, LNK and Jump List volume serials, ShellBags and Logon ID joins, as above.
Assess file movement. Combine host traces, device image analysis and telemetry, and state the strength of each finding.
Test your interpretation. Where a conclusion depends on how Windows behaves, reproduce it on a test machine with the same build and a similar device, and keep the test notes.
Report with limits. Separate observed facts from inferences, name the source of every time, and call identifiers "Windows-recorded" unless verified. The Forensic Report Writing Guide covers structure.

Decision guidance

Triage collection or full image: a targeted collection of hives, logs and user artefacts answers most USB questions within hours. Take a full image when the case may go to court, when deletion or anti-forensics is suspected, or when you need unallocated space and Volume Shadow Copies for older registry states.
Host only or host plus device: if the device can be recovered, image it. Without it, transfer findings will usually stay at "opened from" rather than "copied to".
Small organisations without EDR telemetry should at least enable Audit PNP Activity and forward event 6416 to central logging; it is cheap and gives a user-linked connection record that survives local log clearing.
Large organisations should agree with legal and HR in advance which telemetry may be used for staff investigations, and keep retention long enough to cover typical notice periods.

Other platforms in brief

On Mac laptops with Apple silicon, the Privacy and Security setting "Allow accessories to connect" decides whether new USB, Thunderbolt or SD card accessories need approval, with "Ask for new accessories" as the default and administrators able to control it on supervised devices. That makes the configured setting itself relevant context in a macOS case. Device connection evidence on macOS lives mainly in the unified log, so collect a log archive early and follow the macOS Forensics Guide. Linux hosts record USB attach messages in the kernel and system journal; see the Linux Forensics Guide.

Detection and measurement

Forensic readiness for USB cases is decided before the incident. Monitor and measure:

Coverage of event 6416: percentage of Windows endpoints with Audit PNP Activity enabled and forwarding to the SIEM.
Telemetry retention: days of device control and DLP events retained, against the longest typical gap between an incident and its discovery.
Unknown device rate: removable storage connections from devices not on the approved list, per month, and how many were investigated.
Time to device table: hours from case opening to a complete device and connection table for the host.
Finding quality: share of USB findings in reports that cite at least two independent sources for each time and each attribution.

Alert on 6416 events where the Subject is not SYSTEM, on first-seen storage devices on sensitive hosts, and on bulk writes to removable media shortly before a resignation or role change. The Forensic Readiness Guide covers the wider preparation.

Common failure patterns

Calling the USBSTOR value a manufacturer serial and then failing to match the seized drive in court, because the identifier came from an enclosure or adapter.
Mixing local and UTC times. setupapi.dev.log in local time placed next to UTC registry and event times shifts the sequence by hours, and a "copy before the device arrived" contradiction appears from nowhere.
Reading key last-write times as connection times. Many system processes touch these keys; use the Properties values and logs for times.
Attributing from machine keys alone. USBSTOR proves nothing about which user was present; without MountPoints2, LNK or event 6416 evidence, the user is an assumption.
Treating "opened from" as "copied to". A LNK file proves the file was on the stick and was opened, not that it came from this host.
Collecting too late. Partition/Diagnostic, Security and EDR data roll over; days of delay lose the connections you need.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	RS.AN-03, DE.CM-09, DE.AE-02	Establish what happened; monitor endpoints and analyse device events
NIST SP 800-53 Rev 5	IR-4, AU-2, AU-12, MP-7	Incident handling, logging the right events, controlling media use
ISO/IEC 27001:2022 Annex A	A.5.28 Collection of evidence, A.7.10 Storage media, A.8.15 Logging	Evidence handling, media rules and the logs investigations depend on
MITRE ATT&CK	T1052.001 Exfiltration over USB, T1025 Data from Removable Media, T1091 Replication Through Removable Media, T1200 Hardware Additions	The behaviours a USB investigation confirms or rules out. See MITRE ATT&CK T1052 Exfiltration Over Physical Medium and MITRE ATT&CK T1025 Data from Removable Media

Practitioner checklist

Enable Audit PNP Activity on Windows endpoints and forward event 6416 centrally.
Confirm how long device control and DLP telemetry is retained and extend it to cover typical discovery delays.
Collect hives with transaction logs, setupapi logs, Security and Partition/Diagnostic logs, LNK files and Jump Lists in every USB case.
Build one device table joining VID, PID, instance identifier, volume GUID, drive letter and volume serial before timelining.
Normalise every time to UTC and record the source and original time zone.
Describe identifiers as Windows-recorded until verified against the physical device.
Attribute only with per-user evidence and state the limits of shared accounts.
Image the device whenever it can be recovered, and reproduce any behaviour your conclusion depends on.

USB Device Forensics Guide: Tracing Devices, Users and File Transfers on Windows