usb-drive

Purpose and Function

Windows maintains a detailed history of USB storage devices that have been connected to the system. The primary purpose of this tracking is to facilitate a seamless "plug and play" experience. When a device is reconnected, Windows uses this historical information to quickly recognize it, load the correct drivers, and assign it a drive letter without needing to go through the full installation process each time.

From a DFIR perspective, this convenience feature creates a persistent and invaluable log of all external storage devices that have ever been attached to the machine. This history can prove that a specific device was used on a system, even if the device is no longer physically present.

Location and Structure

The evidence for USB device history is distributed across several locations, primarily within the Windows Registry and system log files.

1. Registry - The USBSTOR Key:

   • Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USBSTOR

   • Structure: This is the primary registry key for tracking USB Mass Storage devices. It contains a subkey for each unique device that has been connected. The name of the subkey is derived from the device's hardware identifiers (Vendor ID, Product ID, and a Unique Serial Number).

   • Metadata: Within each device's subkey, you can find the device's friendly name, hardware IDs, and a timestamp indicating when the device was first installed on the system.

2. Registry - Mounted Devices:

   • Location: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

   • Structure: This key maps volume identifiers (e.g., \DosDevices\E:) to unique volume GUIDs. It helps correlate a specific device with the drive letter(s) it was assigned.

3. Log Files - setupapi.dev.log:

   • Location: C:\Windows\inf\setupapi.dev.log

   • Structure: This plaintext log file records detailed information about device installations, including drivers. It contains high-precision timestamps for when a USB device was first connected and last connected/disconnected.

Stored Metadata

By correlating information from these sources, an analyst can build a comprehensive profile for each connected USB device:

• Device Identifiers: Vendor ID (VID), Product ID (PID), and a unique Serial Number. This combination can often identify the exact make and model of the device.

• Device Name: The "Friendly Name" of the device as reported to the OS (e.g., "SanDisk Cruzer Blade").

• First Connected Timestamp: The date and time the device was first ever connected to the system (found in USBSTOR and setupapi.dev.log).

• Last Connected Timestamp: The date and time the device was most recently connected (found in setupapi.dev.log).

• Last Removed Timestamp: The date and time the device was last unplugged (found in setupapi.dev.log).

• Assigned Drive Letter: The drive letter (e.g., E:) that was assigned to the device's volume.

Forensic Value

Analyzing the history of USB devices is critical for understanding how data and programs may have been introduced to or exfiltrated from a system.

• Proving a Device Was Present: It provides definitive proof that a specific USB storage device was connected to the system, which is essential for refuting claims that a device was never used.

• Establishing a Timeline of Use: The timestamps for first connection, last connection, and last removal allow an analyst to pinpoint when a device was physically interacting with the system. This can be correlated with other evidence, such as program execution traces from a specific drive letter.

• Identifying the Source of Malicious Files: If malicious files are found to have been executed from a removable drive, the USB history can help identify the specific device used, linking the activity to a physical object.

• Tracking Data Exfiltration: In data theft investigations, the USB history can show which devices were connected around the time sensitive data went missing.

Specialized tools like Nirsoft's USBDeview, Eric Zimmerman's JLECmd (which can parse setupapi logs), or forensic suites are typically used to aggregate and parse this information efficiently.

---

Reflection points (SS Contest)

For a ScreenSharer, the USB device history is the primary tool for investigating one of the oldest bypass methods: running cheats from a removable drive.

• The "Cheat on a Stick" Bypass: A common tactic is for a player to store their cheats on a USB drive, run them from there, and then unplug the drive before the screenshare. The goal is to leave no files on the main system drive. The USB history artifacts completely defeat this tactic.

• Finding the Recently Unplugged Drive: The most powerful piece of evidence is finding an entry in the setupapi.dev.log or a tool like USBDeview showing that a USB Mass Storage device was unplugged just moments before the screenshare began. This is an extremely strong indicator that the player was trying to hide the device.

• Correlating with Execution Evidence: If Prefetch or BAM shows the execution of a file from a drive letter like E:\, an SSer can then check the USB history to prove that a specific USB device was recently mounted as the E: drive, directly linking the physical device to the cheat execution.

• FAT32/exFAT Context: Players often use FAT32 or exFAT on USB drives, which lack robust journaling ($UsnJrnl). This makes the USB history even more critical, as it may be the only persistent record of the device's presence and activity on the system.