Windows Forensics: USB Device Profiling

7 min readJun 19, 2024

Overview:

Profiling USB devices are one of those traditional forensic activities that any investigator should know how to do. Despite wide spread use of Cloud storage applications, USBs are still used as means of delivering malware and data exfiltration. This article is going to cover the steps to identify USBs and, if possible, attribute any activity during the time the USB was in use to a user. Here is a list of what we want to know about a USB device:

1. Vendor and Product ID
2. iSerialNumber/ParentIdPrefix
3. Friendly name, vendor, product, and version
4. First/last time the device connected
5. Last time the device was removed
6. Volume Name
7. Last mountpoint/drive letter
8. Volume GUID, if applicable 
9. User Account Associated with the device
10. Volume Serial Number

NOTE: there are multiple classes of USB devices, from keyboards and phones to portable storage devices. This article will focus on Mass Storage Class devices with USB Storage Port services. Additionally, we will primarily be using the Registry to obtain our information, so the only non-native tool needed is Registry Explorer.

Determining the Current Configuration Settings

In the SYSTEM hive, there is a key called ControlSet00X that stores configuration data for your system. Normally, while you are actively using your computer, the current version of the key is stored in memory as CurrentControlSet and isn’t seen in an offline hive. To ensure you’re looking at the correct data set, we must inspect SYSTEM\Select\LastKnownGood to determine which ControlSet we need to examine.

Here we see the LastKnownGood value is set to 1, which means we will be working with ControlSet001.

NOTE: I will commonly use the phrase CurrentControlSet to refer to this last known configuration, instead of the memory resident version of the key. If I say CurrentControlSet later in the article, please know that I’m referring to the LastKnownGood and not the memory resident.

SYSTEM\CurrentControlSet\Enum\USB

The USB key is, more or less, a catch all that stores useful information regarding external devices regardless of device type.

Registry Explorer has some builtin plugins to assist speeding up the process of analyzing keys. When looking at the USB key, the tool will grab high level information for all its subkeys and aggregate it into a table view like the screenshot above. It Reports on:

Timestamp: the last write time for the associated subkey
The subkey’s name (NOTE: they are named according to vendor and product ID, VID/PID)
Serial Number: this value is the iSerialNumber and is hard coded in the firmware of the device
ParentIdPrefix: This value will only appear if the device is a USB attached SCSI devices (UASP)
Service: type of device
etc…

We are going to continue examining the USBSTOR device with the key named: VID_0781&PID_5581. Before we do, use the VID/PID on DeviceHunt to determine the make and model of the USB.

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Vendor: SanDisk, Product: Ultra

SYSTEM\CurrentControlSet\Enum\USB\VID_0781&PID_5581

While the high level information reported by Registry explorer is helpful, there are more granular details contained in the subkeys.

As mentioned earlier, each device will create a subkey under SYSTEM\CurrentControlSet\Enum\USB identified by the VID and PID.

When you expand the device you’re investigating you’ll see the device’s iSerialNumber as the name of the next subkey.

NOTE: We can determine if the iSerialNumber meets USB standards and is a unique value by looking at the second offset of the number. If there is an &, then the number was generated by Windows. There can be, and are, caveats to this rule; especially with classes other than USBSTOR. For now, this is how we are going to interpret these values.

When we inspect the $iSerialNumber key, we see more information confirming:

DeviceDesc: the device is a bulk-only transfer, mass storage device
Service: it’s a USBSTOR (USB Storage Port Protocol)

SYSTEM\CurrentControlSet\Enum\USB\VID_0781&PID_5581\$iSerialNumber

The more interesting information comes from the subkey: Properties\{83da6326–97a6–4088–9453-a1923f573b29}. Here we are able to determine when the device was: first connected, last connected, and last removed from the system.

First Connected Time: SYSTEM\CurrentControlSet\Enum\USB\$vid\$iSerial\Properties\$guid\0064

Last Connected Time: SYSTEM\CurrentControlSet\Enum\USB\$vid\$iSerial\Properties\$guid\0066

Last Removal Time: SYSTEM\CurrentControlSet\Enum\USB\$vid\$iSerial\Properties\$guid\0067

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Vendor: SanDisk, Product: Ultra
4. First Connect: 2024-06-13, 14:06:41
   Last Connect:  2024-06-13, 15:22:23
5. Last Removal Time: 2024-06-13, 20:36:31

Determine Friendly Name and Version Number

To get the friendly name of the device and version number, we can look under the USBSTOR key. The version number is in the HardwareID value.

SYSTEM\CurrentControlSet\Enum\USBSTOR\$device\$iSerial

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Friendly Name: USB SanDisk 3.2Gen 1 USB Device
   Vendor: SanDisk, Product: Ultra, Version: 3.2Gen1
4. First Connect: 2024-06-13, 14:06:41
   Last Connect:  2024-06-13, 15:22:23
5. Last Removal Time: 2024-06-13, 20:36:31

Determine Volume Information

We can obtain the Volume name by locating Windows Portable Devices in the SOFTWARE hive.

Volume Name: SOFTWARE\Microsoft\Windows Portable Devices\Device\$device

To get the volume GUID, we can look under SYSTEM\MountedDevices.

The Volume GUID is: \?\volume{$GUID}

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Friendly Name: USB SanDisk 3.2Gen 1 USB Device
   Vendor: SanDisk, Product: Ultra, Version: 3.2Gen1
4. First Connect: 2024-06-13, 14:06:41
   Last Connect:  2024-06-13, 15:22:23
5. Last Removal Time: 2024-06-13, 20:36:31
6. Volume Name: New Volume
7. Last Mount Point/Drive letter: TBD
8. Volume GUID: {b445a977-284b-11ef-b163-c333a7edd79a}

Determining if the Device is Associated with a User Account

Now that we know the Volume GUID, we can cross reference that value with NTUSER hive. To do this, we will need to look under MountPoints2.

NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2

Since the volume GUID is present, we know one of two things must be true:

The user was actively logged in when the device was present
The user was the last user to be logged in when the device was connected

To determine which scenario is valid, we would need to look at the system’s Security Event Logs and determine when the user was logged in. That can be done by taking the difference in timestamps between Event IDs: 4624/4647 or 4624/4634. Be sure the LogonID matches for the logon/logoff events.

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Friendly Name: USB SanDisk 3.2Gen 1 USB Device
   - Vendor: SanDisk, Product: Ultra, Version: 3.2Gen1
4. First Connect: 2024-06-13, 14:06:41
   - Last Connect:  2024-06-13, 15:22:23
5. Last Removal Time: 2024-06-13, 20:36:31
6. Volume Name: New Volume
7. Last Mount Point/Drive letter: TBD
8. Volume GUID: {b445a977-284b-11ef-b163-c333a7edd79a}
9. User Account Associated w/ the device: Ross
10. Volume Serial Number: TBD

Obtaining the Volume Serial Number

To get the Volume Serial Number (VSN), we can refer to Microsoft-Windows-Partition/Diagnostic.evtx log and cross reference the last connected time for the device. Keep in mind, the registry records time in UTC and Event Logs record local time. Be sure to check SYSTEM\CurrentControlSet\Control\TimezoneInformation to properly interpret the timestamps in the Event Logs.

The VSN is stored in Vbr0and because the device we are examining is an NTFS system, we need to look at offset 0x43 to find the VSN. Keep in mind the byte order as well, it will be in little-endian.

Contents of Vbr0 from Diagnostic.evtx. Offset 0x43 shows the VSN to be: 306B19C9.

We can also slap the easy button by using an open-source tool called Partition-4DiagnosticParser and filtering for the iSerialNumber of the device.

Using Partition-4DiagnosticParser to get the VSN.

1. VID/PID: 0781, 5581
2. iSerialNumber: 0401805d69c0bed0de932277ac861f044d10940c13885d7307a00cd7471423b
3. Friendly Name: USB SanDisk 3.2Gen 1 USB Device
   - Vendor: SanDisk, Product: Ultra, Version: 3.2Gen1
4. First Connect: 2024-06-13, 14:06:41
   - Last Connect:  2024-06-13, 15:22:23
5. Last Removal Time: 2024-06-13, 20:36:31
6. Volume Name: New Volume
7. Last Mount Point/Drive letter: TBD
8. Volume GUID: {b445a977-284b-11ef-b163-c333a7edd79a}
9. User Account Associated w/ the device: Ross
10. Volume Serial Number: 306B19C9

Determining the Last Mount Point/Drive Letter

I’m unable to determine what the device’s drive letter was from the registry since that drive letter has been reused. Nor am I able to do it through Event Logs since I don’t have log archiving setup and events from that time period have been overwritten. However, one possible way to approach this would be to investigate various shell items on the system (such as LNK files) and determine if any of them contain a matching VSN. I probably should’ve pulled some shell items when I took the triage image, but I only copied out the registry and event logs. So that’s my bad. If you want to do this with your own system, I recommend to pull LNK artifacts with your image.

NOTE: VSNs are assigned during formatting, so it’s possible for the same iSerialNumber to have more than one VSN.