With massive external hard drives and smartphones everywhere, the USB interface continues to be a major channel for data theft and malware infections. For anyone working in digital forensics and incident response, building a solid timeline of when a USB device was plugged in, used, and removed is often essential. Whether you are investigating a departing employee who might have copied sensitive intellectual property to a thumb drive, or tracing a ransomware outbreak, the answers frequently involve external storage.

The important thing about these artifacts is their ability to link external USB devices to local file access operations. Proving that a specific flash drive was connected is only half the battle; you also need to know what files the user opened or copied while that drive was active. This requires a solid understanding of how Windows handles different types of hardware behind the scenes – and what it does (and does not) record for each class of device.

Categorizing Connected Storage Devices

To make sense of the data you extract from a drive image or from a running computer during live system analysis, you first need to understand how Windows treats different devices the moment they are plugged in. The system reacts differently depending on the class of the device.

• Mass Storage Class (MSC) devices: These are your standard USB thumb drives and external SSD and hard drives. They use the USBSTOR service, and Windows sees them as basic block storage. Because Windows has direct access to the storage blocks, it can format them with familiar file systems like NTFS, exFAT, or FAT32. The system typically assigns them traditional drive letters (like D: or E:) and they have standard Volume Serial Numbers (VSNs). Notably, some modern devices (especially via newer transport paths) can appear differently (e.g., UASP-related paths/services in some cases).
• MTP and PTP devices: Modern smartphones, digital cameras, and tablets are a frequent and sometimes overlooked exfiltration path. They often connect using the Media Transfer Protocol (MTP) or Picture Transfer Protocol (PTP). Unlike standard thumb drives, these devices do not give Windows direct access to their raw storage. Instead, the phone’s own operating system acts as a middleman, handling file requests. This means traditional artifacts such as logical drive letters or standard VSNs may be missing, requiring the investigator to rely on alternate data sources designed to track portable-device metadata.

Where to Look for the Evidence

Windows 10 and 11 act like detailed, albeit fragmented, recording systems. They track the life cycle of hardware as it connects and disconnects. To build your timeline, you will typically pull information from the Plug and Play (PnP) subsystem, the Windows Registry, Event Tracing for Windows (ETW) event channels, and file system artifacts. By pulling these pieces together, you can move past isolated clues and build a clear picture of what the user was doing.

Windows Registry: Identifying the Hardware

The Windows Registry is one of the richest places to look for system activity and user behavior (see Investigating Windows Registry for more details). It represents a historical record of what hardware was installed and how it was configured. For USB investigations, the SYSTEM hive is your starting point. Before you start digging through an offline registry hive, always check SYSTEM\Select\Current (and, where relevant, LastKnownGood) to make sure you are looking at the active control set used during the last boot.

Tracking Different Device Types

The registry separates general USB connections from actual storage devices. Knowing where to look saves time and helps you filter out noise from non-storage devices like mice or keyboards.

• General USB connections: Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB, you will find a large list of historically enumerated devices still represented in the hive. This includes webcams, Bluetooth adapters, and storage drives. The folders here are named using the device’s Vendor ID (VID) and Product ID (PID).
• Mass storage identification: To focus on storage media, look at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR. This is the master list of external storage devices the system has enumerated as USB storage. Under the product name, you will find a subkey for the device’s serial number. This serial number is crucial because it lets you tie your evidence to a particular physical flash drive. Keep in mind: if the second character of the serial number is an ampersand (&), it usually means the device did not expose a unique serial number in hardware. Windows may synthesize an identifier (often tied to the port/instance), which can make it harder to uniquely attribute activity to a specific physical device across different ports or systems. Note that this is not a guarantee but rather a heuristic indicator.
  Why does it look like that? When a unique serial number isn’t provided by the device descriptor, Windows generates a “Device Instance ID” based on the physical port/hub location. Because it’s tied to the specific USB port hierarchy, plugging the same non-unique drive into a different port on the same machine will generate a completely different ID.
• Smart device tracking: Because smartphones using MTP do not show up in the standard USBSTOR key, investigators sometimes miss them. Their connection history, friendly names, and Device Container IDs are commonly stored under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\WPDBUSENUM – see The Mobile Blind Spot section below for a full discussion of how to interpret this data and its investigative limits.
  Note: While MTP devices often populate the WPDBUSENUM key, this is not guaranteed. In practice, smartphone connection data may also be recorded directly within the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB branch. Investigators should actively check the \Enum\USB key and filter the subkeys by looking for a Service value of WUDFWpdMtp and a Capabilities value with the removable device flag set (CM_DEVCAP_REMOVABLE, 0x4); together, these are a strong indicator the device is acting as a portable MTP endpoint, but not a universal confirmation across all vendors/builds/device configurations.

Timestamps and the devpkey.h Mapping

Once you figured out what device was plugged in, you also need to know exactly when it happened. The registry has a well-known issue sometimes called the “timestamp paradox.” Every registry key has a LastWrite time, but the individual values inside the key do not. If a key updates frequently, the LastWrite time only tells you when the key itself was changed – not which value triggered the change.

To address this, Windows stores per-device timestamps for when a device is installed, connected, and removed. You can find these in the device instance properties under paths like:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_...&PID_...\...\Properties\{83da6326-97a6-4088-9453-a1923f573b29}\....

Forensic researchers have mapped several of the property IDs found here to definitions in Microsoft’s devpkey.h, which effectively acts as a decoder ring for common USB lifecycle timestamps. In many builds, the following IDs are seen:

• 0x64 (InstallDate): The time the device driver was successfully installed (last successful install for that instance). This value changes on later driver updates.
• 0x65 (FirstInstallDate): The first time the device was set up (first configured). This value often remains stable even if drivers are updated later.
• 0x66 (LastArrivalDate): The most recent time the hardware was plugged in and recognized by the system.
• 0x67 (LastRemovalDate): The most recent time the hardware was unplugged or disconnected.

These times are stored in UTC, so remember to convert them to the computer’s local time zone (and account for daylight saving where applicable). By looking at LastArrivalDate and LastRemovalDate, you can often estimate how long the device was attached during its most recent session.

Analyzing Windows Event Logs

While the registry gives you a strong overview, the Windows Event Logs provide the details. Windows uses ETW to write a range of .evtx logs that track hardware events in near real time. These logs can be extremely useful, but keep in mind that some channels may be disabled by default or have limited retention depending on local logging policy. We have a comprehensive writeup about the ETW subsystem in Forensic Analysis of Windows 10 and 11 Event Logs.

Driver and Storage Logs

There are a few event channels that are commonly useful when investigating USB activity:

• DriverFrameworks-UserMode: The Microsoft-Windows-DriverFrameworks-UserMode/Operational log can provide a detailed view of user-mode driver framework activity during device setup. Event IDs such as 10000, 10001, and 10002 may show driver initialization and configuration around the moment the hardware is plugged in. When the device is removed, you may see events such as 2100 and 2102. (Availability and exact event mix can vary by build and configuration.)
• Storage-ClassPnP: Once the device is running, the Microsoft-Windows-Storage-ClassPnP/Operational log tracks activity around the storage volume itself. Event IDs such as 507 and 512 are commonly reviewed. Event 507 is especially useful because it often records identifying strings (vendor/product) and may include the device-reported serial number-handy for cross-checking what you found in the registry.
• MTP / portable device logs: For phones and cameras, relevant events surface in Microsoft-Windows-WPD-MTPClassDriver/Operational, Microsoft-Windows-DeviceSetupManager/Admin, and the System log via the Microsoft-Windows-UserPnp provider. These are covered in detail in The Mobile Blind Spot section below, including how to use the Device Container ID as a correlation pivot across sources.

Additional quick-win pivots: Don’t overlook SetupAPI.dev.log, which often provides a straightforward, chronological record of device/driver installation and updates (useful for first-seen/first-install context when event channels are missing or truncated). For legacy continuity, many analysts still check MountPoints2 (in the user hive) as a historical indicator of volumes a user account has interacted with – helpful as supporting evidence, but not a definitive device identifier on its own. Finally, when a Volume Serial Number is unavailable or unreliable, pivot using other stable identifiers such as the disk signature (MBR), GPT Disk/Partition GUIDs, or the Windows volume GUID (e.g., \\?\Volume{...}\), and correlate those across registry, event logs, and file system artifacts where possible.

Finding the Volume Serial Number (VSN)

If you want to prove someone stole files, you need to connect a physical flash drive to the logical file system. Relying on drive letters is risky because of the “drive letter problem.” Windows recycles drive letters. If a user plugs a thumb drive into E:, removes it, and then plugs a different drive into the same system, that drive might later receive E: as well, which can blur attribution if you rely on the letter alone.

A more stable clue is the Volume Serial Number (VSN). The VSN is a hex value generated when a volume is formatted. Because the same physical device can be reformatted (changing the VSN), the VSN identifies the specific logical volume instance rather than the physical USB stick.

Windows 10 and 11 often record mount diagnostics in the Partition event channel: Microsoft-Windows-Partition/Diagnostic (stored as Microsoft-Windows-Partition%4Diagnostic.evtx). (Note that major Windows updates may clear these logs). When a volume is mounted, Event ID 1006 can include a VBR (boot record) snapshot in fields such as Vbr0. You can extract the VSN from this data, but the offset depends on the file system:

• NTFS: VSN at offset 0x48 (4 bytes, little-endian)
• FAT32: VSN at offset 0x43 (4 bytes, little-endian)
• exFAT: VSN at offset 0x64 (4 bytes, little-endian)

Check out USB Forensics (DFIR Review) for more information about identifying VSNs; they have a number of screenshots with these offsets highlighted. This channel often persists longer than some other operational logs, but retention still depends on the system’s configured log size and overwrite policy – so treat it as “frequently available,” not guaranteed.

The Mobile Blind Spot: Tracking MTP and PTP Devices

The registry and event log sources mentioned above establish that a smart device was present. This section draws those threads together and addresses what analysts can – and cannot – conclude from them.

Smartphones and tablets connecting via MTP or PTP are now among the common and sometimes overlooked exfiltration vectors, often acting as an alternative to traditional flash drives. Because these smart devices do not expose raw block storage to the host computer, the device’s internal operating system brokers all file access and transfer requests. Consequently, traditional artifacts such as logical drive letters or standard VSNs are frequently absent when dealing with MTP connections. This requires the investigator to pivot to alternative telemetry streams specifically designed to monitor smart device metadata.

Despite these missing pieces, investigators can still reliably reconstruct device identities and connection timelines. Instead of the standard USBSTOR key, historical records for these smart endpoints are maintained within the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SWD\WPDBUSENUM registry key. This location stores the device’s friendly name, manufacturer details, and its unique connection history. Furthermore, the Microsoft-Windows-WPD-MTPClassDriver/Operational.evtx log records the successful initialization of the connection and often captures device model/manufacturer and sometimes firmware/build details. For tracking user activity, ShellBags remain exceptionally valuable; because MTP devices do not receive traditional drive letters, their ShellBags reference highly specific Registry paths or GUIDs to seamlessly track graphical navigation through the mobile device’s internal storage. Note that user-specific interactions with these portable devices are often tracked in the NTUSER.DAT hive under Software\Microsoft\Windows\CurrentVersion\Explorer\AutoplayHandlers and Explorer\Portable Devices.

However, there are distinct limits to what can be natively reconstructed without third-party monitoring tools. While registry keys and event logs can prove that hardware was physically present and connected, they do not inherently prove that the user interacted with or extracted the data. Because MTP devices lack standard VSNs, relying on LNK files and Jump Lists to conclusively prove a specific file was copied to the mobile device is often not possible using the classic VSN-based pivots, as those file system artifacts depend heavily on logical volume identifiers, and may require alternative sources (application logs, cloud sync artifacts, mobile acquisition) to reach the same level of confidence. Therefore, while these artefacts can provide evidence of some folder navigation/browsing, proving a definitive file transfer natively through Windows artifacts is significantly more challenging and frequently requires acquiring the mobile endpoint itself.

File System Artifacts: Proving User Interaction

Registry keys and event logs help establish that hardware was attached to the computer. However, proving a drive was plugged in does not necessarily mean anything was accessed. To show a user actually opened files, copied data, or ran a malicious program, you have to dig into file system artifacts.

LNK Files and Jump Lists

To connect a specific file to a specific USB drive without relying on changing drive letters, forensic specialists often use LNK files and Jump Lists.

• LNK files (Windows shortcuts): Windows frequently creates shortcut files when users open documents or applications via Explorer or common shell mechanisms (behavior can vary by version, policy, and how the item was accessed). These shortcuts capture details about the target at the time it was opened. LNKs can record the target path, timestamps, and – most importantly for USB cases-the Volume Serial Number (VSN) of the volume where the target resided.
• Jump Lists: Jump Lists are the recent-items lists that appear when you right-click an app icon on the taskbar. They are primarily stored as AutomaticDestinations-ms files, and (for some apps and behaviors) CustomDestinations-ms files in subfolders of the %APPDATA%\Microsoft\Windows\Recent\ folder. Individual records inside Jump Lists are structurally similar to LNK data and can contain the same high-value pivots, including full paths and the VSN.

By extracting the VSN from a relevant LNK or Jump List record, you can search for that VSN in Partition diagnostic events (or other volume-mount artifacts). Once you find it, you can correlate that volume to the device identity in the registry (USBSTOR) and related logs. By cross-checking these artifacts, you can often demonstrate that a specific document was opened from a specific removable volume – regardless of what drive letter it had at the time.

Tracking Navigation and Execution

Sometimes you need to show what folders a user clicked through, or demonstrate that they ran a portable tool directly from a removable drive. That is where additional artifacts come in.

• ShellBags: Found in the user’s registry hives (NTUSER.DAT and UsrClass.dat), ShellBags capture folder view settings for locations the user browsed in Explorer. They can persist even after a USB device is unplugged. For MTP devices that do not use standard drive letters, ShellBags may reference portable-device paths and GUID-based identifiers, which can still help you reconstruct navigation on the device. More about ShellBags in Investigating Windows Registry.
• Timeline (ActivitiesCache.db): Windows 10 introduced Timeline, which recorded user activity in a SQLite database. Depending on Windows version and configuration, this database may still exist and contain records of opened items and application activity. Windows 11 removed the visible Timeline interface, but some related activity collection mechanisms may still be present – so treat it as a “check and confirm” artifact rather than an assumption. Location: subfolders under %LocalAppData%\ConnectedDevicesPlatform (parent path). Notably, Timeline records are typically only stored for up to 30 days.
• Execution tracking: If you need to show a program was executed from removable media, review multiple sources. The Application Compatibility artifacts (including Amcache.hve) can preserve execution-related evidence / program presence and compatibility metadata and may include hashes and path/volume context. The Background Activity Moderator (BAM) and Desktop Activity Moderator (DAM) can record execution paths for some programs. In Windows 11, the Program Compatibility Assistant (PCA) can also maintain readable logs of program execution events associated with user-launched applications. Amcache should be viewed as a supporting application compatibility artifact, and correlated with other execution artifacts.

Conclusion

We previously published individual posts exploring the Windows Registry and Windows Event Logs, and now we are assembling them to target a highly specific, pervasive threat: the connection and utilization of external storage media by malicious actors. The difference between a basic analyst and an expert is the ability to tie these loose threads together. None of these artifacts tell the whole story on their own. To build a defensible chain for malicious use of an unauthorized drive, you typically correlate multiple layers: identify the device in the Registry, bound connection time using per-device timestamps and event logs, associate storage identity using a stable pivot (like VSN or volume identifiers), and then demonstrate interaction using file system artifacts (LNKs, Jump Lists, ShellBags, execution traces). This correlation reduces ambiguity and produces a timeline that is less likely to be disputed than any single artifact in isolation.

Manually pulling these pieces together takes time, which is why we built Elcomsoft Quick Triage. It is designed to quickly extract all the registry keys, event logs, and file system artifacts discussed in this article, giving you the data you need to build your timeline without manually digging through the piles of data.

We are grateful to the members of the forensic community whose research continues to drive the industry forward:

1. Investigating Windows Registry, ElcomSoft blog
2. Forensic Analysis of Windows 10 and 11 Event Logs, ElcomSoft blog
3. Digital Forensics: Artifact Profile – USB Devices, Magnet Forensics
4. Understanding USB Artifacts: HID, MTP, PTP, and MSC Devices, CyberEngage
5. Windows Registry Forensics: Analysis Techniques, Belkasoft
6. Overview of USB Event Tracing for Windows, Microsoft Learn
7. Leveraging LNK Files & Jump Lists in USB Device Forensics, USB Detective
8. Jump List Examination, Forensic Focus
9. BAM and DAM in Windows Forensics: Tracking Executed Applications, CyberEngage
10. Diving into the Windows 11 Forensics PCA Artifact, Sygnia