Windows USB Artifacts Forensics

 

Since their inception, portable devices have been one of the main security threats to enterprises. These devices can be plugged or inserted into any system to perform malicious activities ranging from intellectual property theft and confidential data exfiltration to malware propagation. Some advantages of USB devices over traditional storage systems (such as floppy devices, CDs, and DVDs) are high storage capacity, small size, low cost, and portability. Under these advantages, USBs are widely used in white-collar crimes.

The ubiquity of USB devices has engendered difficulty in auditing and controlling their usage in corporate environments. Fortunately, a myriad of artifacts related to USB activity exist that can be pieced together to tell a compelling story of their nefarious usage. As you shall discover presently, removable device forensics provides an incredibly rich source of data for the forensic examiner.

Location of USB Device Information

When a USB device is plugged into a computer, Microsoft Windows-based operating systems update Windows Registry keys and Event log files. These must be investigated, and the information garnered must be cross-referenced with shell item artifacts to accomplish a full audit of removable devices in the system under scrutiny.

USB Device Classes

USB devices are classified into several categories based on their functionality, as defined by the USB Implementers Forum (USB-IF). Each USB class has its own drivers and protocols, making it easier for operating systems to recognize and interact with devices. These devices leave behind different artifacts on the computer endpoints to which they are connected. While it will be infeasible to undertake an in-depth discussion of every device class and associated forensic artifact, this post aims to equip the investigator with the requisite knowledge to conduct a critical audit of any USB device(s) they find germane to their investigations.

• Human Interface Devices—The USB Human Interface Device class (USB HID class) is a part of the USB specification for computer peripherals: it specifies a device class (a type of computer hardware) for human interface devices such as keyboards, mice, touchscreens, game controllers, and alphanumeric display devices. This USB device class (Class 03h) is designed for devices that interact with users through input and output actions. It was introduced to standardize how peripherals like keyboards, mice, and game controllers communicate with computers and other host systems.
• Media Transfer Protocol— This protocol allows the bidirectional transfer of audio, media, and other file types, such as zip files and documents, between digital media players and a computer. Developed by Microsoft, the Media Transfer Protocol (MTP) is an extension to the Picture Transfer Protocol (PTP) communications protocol that allows media files to be transferred automatically to and from portable devices. MTP and PTP share the same class code (06h) as the data transfer layer used by MTP is the PTP specification. The Picture Transport Protocol (PTP) was developed by the International Imaging Industry Association. This protocol is used by direct printers, scanners, and other digital still photography devices (DSPDs) to unidirectionally transfer image and video files and their associated metadata. When a device using MTP is connected to a computer via USB, it appears as a "media device" rather than a simple storage device. Examples of MTP devices include smartphones, tablets, and portable media players.
• Mass Storage Class—The USB Mass Storage Class (MSC) is a set of computing communication protocols defined by the USB Implementers Forum that allows USB devices to be recognized and used as external storage by a host computer. When a USB device operates in MSC mode, it emulates the functionality of an external storage medium, allowing the host system to interact with it as if it were a traditional storage device. Examples of devices in this class include external hard drives (HDD), portable flash memory devices (USB flash drives), solid-state drives (SSD), memory card readers, and external optical drives (CD/DVD drives).

USB Forensic Analysis

Since we will be investigating registry keys a lot in USB device artifacts forensics, it is essential, especially for the newbie forensic examiner, to understand the current configuration settings in the SYSTEM registry hive. In the SYSTEM registry hive, there is a key called the ControlSet00x that stores configuration data for your system. When analyzing a live system, the current version of the key is stored in memory as CurrentControlSet. It is not typically seen this way in an offline SYSTEM hive, but rather as ControlSet00x, where x is a real integer (such as 1, 2, and so on). To ensure you are looking at the correct data, you must inspect the SYSTEM\Select\LastKnownGood value to determine which ControlSet we need to examine.

Figure 1: SYSTEM registry hive current configuration settings

In the figure above, we see the LastKnownGood data value is set to 1, which means we will be investigating ContolSet001.

Human Interface Devices (HIDs)

HID attacks exploit HIDs to inject malicious code into computer systems. They use a programmable microcontroller loaded with malware hidden in what appears to be an everyday HID device, often a USB drive. When plugged in, the malicious USB drive acts like a keyboard and starts executing a pre-programmed sequence of keystrokes. These can do a ton of things, ranging from data exfiltration and propagation of malware to a complete collapse of enterprise infrastructure. These attacks are fast, stealthy, and difficult to detect. The primary reason for the success of these attacks is that many operating systems assume HID devices are safe, thus permitting them to run without hurdles. Examples of HID attack tools include BadUSB, Rubber Ducky, WiFi HID injector, USB Ninja, and AirDrive (a hardware keylogger).

HID device class associations are stored under the SYSTEM\CurrentControlSet\Enum\HID key. In general, they record less data than other device types, but at a minimum, you can expect to find Vendor ID, Product ID (PID), and timestamps.

Figure2: HID Registry artifact

The image above reveals a Vendor ID listed as VID_80EE&PID_0021. An online lookup identifies it as VirtualBox. Although attackers typically do not change the default values, it should be noted that many of the malicious USB projects possess capabilities that allow spoofing of VID and PID information. HIDs record three important timestamp information in the subkey <iSerialNumber|ParentIdPrefix>\Properties\{83da6326-97a6-4088-9453-a1923f573b29} in the subkeys named 0064, 0066, and 0067. These are Windows 64-bit FILETIME timestamps recording the first connection time, the last connection time, and the last removal time, respectively. 

Media Transfer Protocol (MTP) Devices

In MTP, devices are mounted at the logical level (as opposed to the physical level for MSC devices), and the underlying file system structure is not seen. This limitation restricts direct access to the filesystem. In Windows 10+ versions, MTP and PTP devices are displayed under the Devices and Drives dialog. On older versions, they are displayed under Portable Devices. They are not assigned drive letters (such as C:\ or D:\). 

MTP devices can serve as a point of data exfiltration from a forensic perspective; hence, it is important to assess whether there is proof that this kind of device was used during periods of interest. Not all currently available forensic tools can parse MTP device-associated information correctly; as such, a forensic examiner must have knowledge of the registry and other operating system artifacts generated by these devices. MTP and PTP-based devices typically maintain fewer registry and other OS artifacts than MSC-based devices. The relevant registry paths to look out for when examining a suspect system for MTP device connection are SYSTEM\CurrentControlSet\Enum\USB and SOFTWARE\Microsoft\Windows Portable Devices\Devices. Also, files accessed from these devices may not create shell items as expected. LNK file creation for these device types is highly dependent on the version of Windows, the application doing the opening, and the file type. For instance, systems running Windows 7 would produce LNK files for DOCX and JPG files but not for PDF, TXT, or XLS files. Windows 11 systems only produce LNK files for folders—not files—that are accessed on MTP devices, according to current testing. Despite this, it is still quite possible to find references to these devices in other artifacts, such as ShellBags and at least some LNK files. Since these devices are not assigned drive letters, look for “MTP” designations and for paths similar to the following (from Windows 11 LNK files):

        
text
        

            
        
     
Absolute Path: My Computer\Huawei P8 Lite\Internal Storage\DCIM\202503_

Mass Storage Class

USB Mass Storage Class devices are mounted at the physical level; thus, the underlying file system structure is available for viewing. It provides direct access to sectors for reading and writing. A mounted Mass Storage Class device appears in Windows Explorer under "Device and Drives" in Windows 10+ versions and "Device with the subcategory Removable Storage" on older versions. Devices are typically assigned the next available drive letter (D:\, E:\, and so on). Due to the ubiquity of Mass Storage Class devices and the wealth of artifacts they leave behind, the majority of this post will cover investigating these devices. Investigators can utilize the same tools and techniques used during MSC device audits to analyze other device classes like HID and MTP, bearing in mind that they often leave fewer footprints.

To understand the digital footprints left behind by MSC peripherals, it is necessary to discuss the two prevailing data transfer protocols in use within Windows. The USB Storage subsytem (USBSTOR) supports file transfer via the traditional protocol used with USB 1.1 and USB 2.0 devices known as Bulk-Only Transport (BOT). It uses bulk transfers for data movement as the name suggests. It is a half-duplex protocol, meaning data transfer and command transmission do not occur simultaneously. A majority of MSC devices still employ this protocol today because of its long history. With the introduction of USB 3.0, however, the older BOT protocol was retained along with a new protocol named USB Attached SCSI Protocol (UASP). UASP was developed to address the shortcomings of the traditional USB Mass Storage Bulk-Only Transport protocol, i.e., an inability to perform command queueing or out-of-order command completions. To support these features, the Bulk Streaming Protocol was added to the USB 3.0 specification, and Streams support was added to the USB host controller interface (Extensible Host Controller Interface). It uses the standard SCSI command set and allows for much faster, multi-threaded transfers. It operates in full-duplex mode, allowing simultaneous data transfer and command execution. This new protocol was designed to support ultra-fast solid-state media and the new faster transfer rates implemented in the USB 3.0 specification. 

If you have previously audited a suspect system for USB artifacts, you would have likely focused only on the USBSTOR registry key. In modern systems, this focus can lead to missing important devices. With the introduction of UASP devices, a change in investigative approach is required to accomplish a thorough audit since UASP devices are not tracked under USBSTOR. As you will see presently, UASP devices are recorded in a different registry key named SCSI. For the most part, the investigative processes for these two different devices will mirror each other with slight deviations.

The best location to commence a USB device audit is the SYSTEM\CurrentControlSet\Enum\USB key. This key tracks devices across a range of device classes, including USBSTOR, UASP, MTP, PTP, and HID. It gives a great overview of previously connected devices that could be of investigative value. This key is present in XP+ versions of Windows. The USB key provides the following information:

• Device type (USBSTOR, UASP, HID, MTP, etc)
• Vendor ID
• Product ID
• Device iSerialNumber
• ParentIdPrefix (UASP devices)

It is important to note that a complete system USB device history may not be obtained due to a not-so-often data clean-up by the operating system following major OS updates.

Figure 3: USB key Registry artifact

Noticeable from the USB key in the above image are a series of subkeys starting with 'VID. ' Each of these subkeys represents different devices previously connected to the system. The first information of evidentiary value is within the names of the subkeys themselves. The VID and PID values are hexadecimal values that represent the manufacturer and product identifier for the connected USB device. The Vendor Identifiers (VIDs) are assigned by the USB Implementers Forum (USB-IF). One of the most comprehensive databases for these values is the USB IDs Repository. It is frequently updated and the best available resource for such lookups. DeviceHunt is a graphical front-end to the USB IDs database and the PCI IDs Repository, making it an easy source of VID and PID information.

Figure 4: USB device Vendor

 

The next piece of information in the USB key is the iSerialNumber of the device. This is shown in Figure 3 above as the subkey directly under the VID key (AAI6UXDKZDV8E90U). As you shall discover later, this identifier can be called by different nomenclatures and may or may not be tied to the physical device hardware, but for now, it should be noted as an important, unique value that can be used to track a particular USB device across multiple other registry keys and event logs. Unfortunately, not all USB devices report an iSerialNumber in their device descriptor. In such cases, Windows will generate a unique instance ID for the device. To tell when this is the case, take a look at the unique instance ID for the device, and if the second character (not the second to the last character, but the second character in the string) is an “&” (as shown in the Figure below), then the unique instance ID was created and assigned by the operating system, rather than extracted from the device descriptor of the device.

Figure 5: Windows-generated iSerialNumbers

For profiling a device on a single system, it matters not whether the iSerialNumber is hardware-based or Windows-generated, as both will uniquely identify a device on the system. However, it becomes extremely challenging to track the same device across multiple systems if it lacks a unique hardware-based iSerialNumber since Windows will assign a different value on each system. Also, low-quality USB devices can create confusion. They might report inconsistent iSerialNumbers even on the same system, making a single device appear as multiple devices. In such cases, you will need to rely on other artifacts like the Vendor and Product ID (VID, PID), Volume name, or the Volume Serial Number for investigative leads.

Another piece of information needed within the USB key is present in the values stored within the iSerialNumber sub-key. The DeviceDesc and Service fields typically provide enough information to determine with accuracy the type of the device under investigative scrutiny. Common service types that can be encountered include:

• USBSTOR (Mass Storage Class USBSTOR)
• UASPSTOR (Mass Storage Class UASP SCSI)
• HidUSB (HID input device)
• WUDFWpdMtp (MTP devices like smartphones)
• RtlWlanu (Realtek RTL8188EU Wireless LAN 802.11n Network Adapter)
• usbvideo (Video device like webcam)
• usbaudio (Microphone)
• USBHUB3 (USB HUB)
• BTHUSB (Bluetooth)
• vmusb (VMWare USB device pass-through)
• usbccgp (Composite USB device - A peripheral that has combined functionality from one or more device class. E.g., a keyboard with combined mouse input).

Figure 6: Service value for SCSI UASP devices

Figure 7: Service value for MTP devices

Other information in this subkey that you might be interested in are:

• Driver - The driver information that was used in installing the USB device.
• LocationInformation - This value displays the port and hub number to which the USB device was attached to on the system. In figure 3, the USB device was attached to Port 1, Hub2.
• Mfg - This displays the name of Setup Information File or the INF file, which in figure 3 was usbstor.inf, and status of the compatibility of USB device, which was Compatible USB storage device.

The final information needed are three important timestamps recorded in the subkey <iSerialNumber>\Properties\{83da6326-97a6-4088-9453-a1923f573b29} in the subkeys named 0064, 0066, and 0067. These are Windows 64-bit FILETIME timestamps recording the first connection time, the last connection time, and the last removal time, respectively.

A computer system used frequently may have a very long list of previously connected USB devices, in which case, examining individual subkeys under the SYSTEM\CurrentControlSet\Enum\USB key may be tedious for the investigator, the Registry Explorer tool by Eric Zimmerman has a plugin to extract information of interest from the key and present them in a tabular form as shown in the image below. Note that the timestamp reported by this plugin is the last write time of the VID/PID registry key and may not accurately represent when the device was last used.

Figure 8: Registry Explorer USB plugin

The USB Storage (USBSTOR) Subsystem 

This registry key tracks Mass Storage Class USB Bulk-Only Transport protocol (USBSTOR) device connections to a Windows computer endpoint. USB Attached SCSI Protocol (UASP) device connections are stored in the SYSTEM\CurrentContolSet\Enum\SCSI key. Both protocols had been discussed previously. The USBSTOR is managed by the usbstor.sys driver, which is responsible for the connection between the USB mass storage and the operating system. This driver is typically located at %SYSTEMROOT%\Windows\System32\drivers\usbstor.sys. The USBSTOR service, which is linked to the driver, runs in the background to manage device connectivity and transfer data. If a USBSTOR device of interest has been identified following an initial examination of the SYSTEM\CurrentContolSet\Enum\USB key, a corresponding artifact should be found at the SYSTEM\CurrentContolSet\Enum\USBSTOR key with an iSerialNumber matching that found in the \Enum\USB key. The device's serial number is what connects these two keys together. With this, the USBSTOR registry key can be probed for additional artifacts of evidentiary value such as:

• Device ID - This is contained in the very nomenclature of the USBSTOR immediate sub-key. It is often used verbatim by other registry artifacts.
• Friendly Name - The name of the device. This is typically associated with the manufacturer and model of the device.
• First connection timestamp.
• Last connection timestamp.
• Last removal timestamp.

Each device recorded under the USBSTOR registry key has a DiskId value located at SYSTEM\CurrentControlSet\Enum\USBSTOR\<Device ID>\Serial Number\Device Parameters\Partmgr. This value, when correlated with the information obtained from the %SYSTEMROOT%\Windows\System32\winevt\Logs\Microsoft-Windows-Partition/Diagnostic.evtx event log file, provides additional metadata and timestamps for the suspect device.

Similar to the \Enum\USB key, the USBSTOR subkeys are known to be removed during major Operating system updates (starting in Windows 10+ versions).

Figure 9: USBSTOR Registry artifact

As seen in Figure 9 above, each immediate subkey of the USBSTOR is named with a string of the format Disk&Ven_[VendorName] &Prod_[ProductName]&Rev_PMAP\[SerialNo]. Below each Disk&Ven_ string subkey will be one or more unique subkeys known as the iSerialNumbers. There can be more than one iSerialNumbers below a device identifier because different devices of the same type have previously been connected to the computer. In Figure 9 above, we find a match for the iSerialNumber AAI6UXDKZDV8E9OU (obtained in the analysis of the \Enum\USB key in Figure 3) under a key named Disk&Ven_Lexar&Prod_JumpDrive&Rev_1100. This key is referred to by Microsoft as the Hardware ID/Device ID. Going by Microsoft's convention, our target device is a Lexar JumpDrive Revision 1100 USB device. This is further corroborated by data from the more human-readable FriendlyName: Lexar JumpDrive USB Device.

USB Device Timestamps

When examining modern Windows systems for evidence of USB connections, three timestamps are germane to our investigation they include:

• First time connected
• Last time connected
• Last removal time

Under the iSerialNumber subkey for each device is a subkey named Properties. Under the Properties subkey is a specific globally unique identifier (GUID) key, {83da6326-97a6-4088-9453-a1923f573b29} holding subkeys with the relevant timestamp information listed above. They are available for all of the different USB device classes previously discussed - HID, MTP (found in the Enum\USB key), USBSTOR, and UASP (found in the Enum\SCSI key). Each key contains a 64-bit timestamp in the Windows FILETIME format. When examining these locations via Eric Zimmerman's Registry Explorer, these values are automatically converted to human-readable timestamps as seen in the figure below.

Figure 10: USB Device connection timestamps

• 0064 (Windows 7+ versions) - First install/connection date of the USB device.
• 0066 (Windows 8+ versions) - Last connection date of the USB device.
• 0067 (Windows 8+ versions) - Last removal date of the USB device. This is typically updated notwithstanding if the device was safely ejected or forcefully pulled out.

You might also observe that the 0065 subkey also contains a valid 64-bit Windows FILETIME timestamp. This subkey records the time of the last driver installation for the device. Upon initial installation of the USB device, this subkey contains a value that is almost always identical with the 0064 subkey. If an updated version of the USB device driver gets installed later, this subkey will be updated and will contain a value different from the 0064 subkey. This, however, would be of little significance to a forensic examiner, hence the emphasis on the above three timestamps.

Before the discovery of the timestamp information recorded in the aforementioned keys by the forensic examiner, Yogesh Khatri, the standard way to determine the first-time connection timestamp for a USB device was to view the Plug and Play log located at %SYSTEMROOT\Windows\INF\setupapi.dev.log (named setupapi.log in Windows XP systems). The Plug and Play (PnP) Manager logs information of new devices plugged in and installed in the setupapi.dev file. This plain text log file contains information, including the timestamp of the driver first installed, and it also stores information of the device,  including the serial number, product ID, and vendor ID. The timestamp found here could be slightly different from that found in the registry since both data sources can be recorded at slightly different times during the installation process. The timestamp logged here is stored in the local system time instead of the UTC time recorded in the registry. 

Figure 11: The setupapi.dev.log file

Comparing the Last connected timestamp with the Last removal timestamp gives an insight into the duration of the last USB connection. 

Figure 12: Duration for which USB device was last connected

The Registry Explorer tool by Eric Zimmerman also has a plugin for USBSTOR and SCSI UASP device types to extract information of interest from the key and present it in a tabular form.

Figure 13: Registry Explorer USBSTOR plugin

Identifying USB Device Volume Name

A Volume name is a unique name assigned to a storage volume helping a user to identify and manage different USB devices. This can help with tracing artifacts associated with a device, including shell item information in LNK files that can identify specific files and folders present on the device. Not all devices maintain a volume name. In Windows, volume names are largely associated with only MSC and MTP/PTP devices. They are also not mandatory and may not be assigned to some devices. In these circumstances, the registry key records the last mount point (drive letter) instead.

To identify the volume names of connected USB devices in the system under examination, we will locate the Windows Portable Devices registry key and subkeys in the SOFTWARE registry hive SOFTWARE\Microsoft\Windows Portable Devices\Devices. Most subkeys here are named according to the Device ID and iSerialNumber of the device. This makes correlation with other keys like Enum\USB or Enum\USBSTOR very easy. Each subkey records one value called the FriendlyName, which stores the last volume name for the connected USB device or the last drive letter if no value name exists.

Another advantage of examining this key is that contrary to the USB and the USBSTOR keys that are susceptible to automatic system cleanup activity, data present in this key often goes back much further in time. The examiner might thus identify devices that cannot be fully profiled, but at least he can determine their manufacturer, iSerialNumber and volume names. In such cases, the last write time of the associated subkey can provide a clue as to when the device was first connected to the system (though this timestamp has also been known to be reset during major system updates).

The Registry Explorer tool also has a plugin for Windows Portable Devices, where it presents all the information about devices recorded in the key in a tabular form, as shown in the figure below:

The USBSTOR information from the above figure is complete with Device ID, iSerialNumber, and the Friendly Name. The reader may notice that the entries for MTP and UASP devices appear to be missing some information. This is because this plugin is optimized to extract USBSTOR information and sometimes misses information from other device classes as it is stored differently within the raw subkeys of the Windows Portable Devices registry key. If you find a device of interest with incomplete information in this plugin, you must conduct a manual review of appropriate keys to find the information that you seek as opposed to relying on an automation mechanism. 

Identifying The Last Mountpoint Drive Letter

The drive letter is often recorded in various system artifacts such as Prefetch, RecentDocs, Jump lists, LNK files, OpenSavePidlMRU, ShellBags, and more. Matching the last mount point with these artifacts helps investigators trace file access and usage. The last mountpoint information can be found at the following Registry locations.

• SOFTWARE\Microsoft\Windows Search\VolumeInfoCache (Windows 7 and higher versions)
• SYSTEM\MountedDevices 

The last mount point drive letter is not guaranteed to be available as several factors (as you shall discover presently) can affect its presence or accuracy. These two registry keys only store information on the last device connected at a specific drive letter, and a given drive letter may have been shared across multiple devices connected to the system. The artifacts at the above-mentioned registry keys tend to persist longer than other USB artifacts, particularly on Windows 10+ version systems that clear many registry keys during major system updates. The MountedDevices registry key artifacts, in particular, tend to survive system cleanup and sometimes provide information on much older devices.

The VolumeInfoCache key maintains a series of subkeys, one for each drive letter in use on the system. Each of these subkeys maintain a VolumeLabel that records the volume name of the last device to be connected as that drive letter. By correlating this volume name to other artifacts previously found in your investigation, you can assign drive letters to some devices (noting that only the last device at that drive letter will be recorded). This key does not maintain a historical record of every device that has ever been connected at that drive letter. The figure above shows the Registry Explorer VolumeInfoCache plugin's output for the system under investigation, presented in a tabular form. The timestamps displayed here are simply the last write time of each subkey. While they often indicate the last connection time of the USB device, they have not been as thoroughly tested as previous timestamps that we have encountered hitherto.

A good advantage of this artifact is that it is easier to read and extract information from than the MountedDevices registry key, which has been the more traditional source of this information. In general, this artifact is more suitable for examining SCSI drives (including MSC UASCP) and mounted objects like Microsoft VHDs.

The SYSTEM\MountedDevices registry key is another location where you can identify the last mount point of a device. This key contains detailed information but only for Mass Storage Class (MSC) devices. USBSTOR devices are the easiest to investigate using this registry key.

The MountedDevices registry key records a series of information for each drive letter it maintains. By searching for the device iSerialNumber within the value data, you can correlate the corresponding drive letter with that iSerialNumber. In the figure above, the iSerialNumber AAI6UXDKZDV8E90U is present in the value data for \DosDevices\E:, indicating that the device with that iSerialNumber was the last mounted as E:\. A particular device may have been mounted previously using multiple drive letters; you are therefore encouraged to undertake a search of each drive letter for a possible match.

If the device of investigative interest is a UASP (SCSI) or a USBSTOR device that is a real disk drive (a USB-attached HDD or SSD), the profiling process with the SYSTEM\MountedDevices registry key becomes a little more complicated. Thumb drives are tagged and treated differently by Windows, and they typically have just a single partition. HDDs and SSDs can have several mounted partitions, and thus, drive partition information must be recorded for each instance. This data takes the place of the iSerialNumber stored for thumb drives. To complicate things further, the data stored, the data stored depends on which of the two primary partitioning schemes are in use - MBR and GPT.

SYSTEM\MountedDevices For GPT Partition

If the data value for a drive letter starts with DMIO:ID, it references a GUID Partition Table (GPT) that was mounted as that drive letter. Tracking back to the original device is relatively easy in this case. The 16 bytes after DMIO:ID (i.e., the last 16 bytes of the value data) represents the Unique Partition GUID. Searching across the registry hives for these 16 bytes can identify other keys tagged with this value, often resulting in keys that can help define the actual device. If no hits were found, it is possible the device was mounted long ago, and the other related keys have aged out (The MountedDevices registry key maintains data longer than other registry locations).

Note: For the uninformed reader who might be a little confused, the hex bytes 44-4D-49-4F-3A-49-44-3A as seen in the image below correspond to the ASCII characters DMIO:ID:.

SYSTEM\MountedDevices For MBR Partition

If the data value for a drive letter does not start with DMIO:ID: and neither is it a USBSTOR device with an iSerialNumber, then the device under examination is likely using the MBR partition scheme. The first four bytes consist of a unique value known as the Disk Signature. This value is written into the disk's Master Boot Record (at drive offset byte 440 if it needs to be verified on an actual device). It is also stored in different registry keys as a unique identifier for that drive. A registry search for the unique four bytes can often uncover hits in other keys that can help identify the device as seen in the figure below.

Mounted Devices: Volume GUID

If the device under investigation is a Mass Storage Class USBSTOR device, you should find a long string, with the iSerialNumber of the device present in the value data, rendered in a similar format as \??\Volume{fb7f93ec-37a4-11e6-8254-080027d269d7}.  The values within this key that start with “\??\Volume” and end in GUIDs refer to the volumes that were mounted on the system. 

The Global Unique Identifier (GUID) between the curly braces is the Windows-assigned Volume GUID for that device. As we shall see next, this number will be needed to attribute the USB device to a specific user. You should be aware that the investigative step that follows can only be done for Mass Storage Class USBSTOR devices. For other device types, you will have to look to the Windows event logs to identify contemporaneous user account activity. 

Identify Related User Account

If the device being investigated is a USBSTOR device, an attempt can be made to attribute the usage of the said device to a user account in the system. To do this, we have to look to the NTUSER.dat registry hive. Each user in a system has an NTUSER.dat registry hive maintaining user configuration data for the system, which is loaded into primary memory when the user logs in to the system. The MountPoints2 key within this registry hive stores information related to mounted drives, network shares, and other types of removable media the user has had access to via the Windows explorer. The full path to the key in question is NTUSER.dat\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoint2. Beneath this key are many long strings of numbers and letters that start and end with curly brackets; these are globally unique identifiers (GUIDs). These are, in fact, the same GUIDs that are found in the MountedDevices key within the System hive. As an NTUSER.dat registry hive is maintained for each user in the system, all suspected NTUSER.dat hives should be loaded into the Registry Explorer tool and searched simultaneously  If you find a Volume GUID match in the MountPoints2 key for the same GUID previously identified in the SYSTEM\MountedDevices, then we know one of two things must be true about the associated user profile:

• 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, you will need to look at the Security Event logs of the system and examine when the user was logged in. This can be done by taking the spread in timestamps between Event IDs 4624 and (4647 or 4634). Be sure that the logon ID matches for the logon/logoff events. The lastwrite timestamps for the MountPoints2\Volume GUID key is an indication of the last time the key was connected. 

From the image above, examining the MountPoints2 key revealed the same Volume GUID that was discovered in the MountedDevices key fb7f93ec-37a4-11e6-8254-080027d269d7, indicating the account to which this NTUSER.dat file belongs was logged in while the device was present in the system. As mentioned previously, this investigative step only yields results when the device being profiled is a Mass Storage Class USBSTOR device. However, since there are connection timestamps with each device, we can often rely upon the Windows event logs and other artifacts to link device usage of any type to specific user activity.

Event Log Analysis

The Windows 10-introduced custom event log Microsoft-Windows-Partition/Diagnostic.evtx located at the path %SYSTEMROOT%\Windows\System32\winevt\Logs\Microsoft-Windows-Partition/Diagnostic.evtx records a wealth of device-specific information whenever a device is connected/disconnected from the system. Each event records a ton of information about the device, including model, manufacturer, Vendor ID (VID) and Product ID (PID), disk capacity, and two different serial numbers - the SCSI serial number (labelled "SerialNumber"), and the iSerialNumber (part of the "ParentId field"). It also maintains the content of the Master Boot Record (MBR) and up to three Volume Boot Records (VBR).

Entries are recorded this log whenever a device is connected/disconnected providing detailed history on device usage. Reviewing the "Capacity" field will quickly tell you what type of event you are inspecting. The Capacity field records a value greater than zero for connect events and record a value of zero for disconnect events. But you should also note that events are also recorded during sleep/hibernation and shutdown, complicating the pattern seen in this log. Windows does not make viewing this log easy. As a result, you might want to consider reading the XML view which captures a lot of information as seen in the truncated output below.

A major limitation to using this log is that Windows feature updates are known to clear this log. Hence, it only maintains data for a time after the last major update. You might want to consider viewing the Microsoft-Windows-StorageSpaces-Driver/Operational.evtx log, which contains duplicative information.

When examining evidence of USB device usage on suspect systems, your investigation would be considered robust if you can tell what files and folders were present on the media. This can typically be achieved by tieing information from shell items such as Jump list and LNK (shortcut) files to device details. This linkage can be accomplished by using the Volume Serial Number. FAT, exFAT, and NTFS file systems all have Volume Serial Numbers (VSNs) stored within the Volume Boot Record of each partition. LNK files and Jumplist entries record the device VSN for each file or folder items. Matching the VSN from a USB device with the VSN recorded in a shell item is a sufficient proof that the file or folder was opened from that device.  

To obtain the Volume Serial Number of a device, you will have to refer to the Microsoft-Windows-Partition/Diagnostic.evtx event log. The VSN is stored and derived from the VBR data. Data is stored in hexadecimal and VSN values are represented as four bytes (little endian) located at offsets 0x43 (FAT), 0X64 (exFat), and 0x48 (NTFS) within each VBR. This data can be extracted from the raw hex data, noting the endianness, but there is an open-source tool written in Python that can automate the process of extracting all the logged VSNs that reside in the Microsoft-Windows-Partition%4Diagnostic.evtx as shown in the image below.

By effectively applying USB forensic techniques, investigators can reconstruct events, establish timelines, and identify potential sources of data leakage or unauthorized access. This knowledge aids in the attribution of actions, the identification of responsible individuals, and the overall strengthening of digital security.