Archive for usb device

USB Device Tracking using the Partition/Diagnostic Event Log

One of the new event logs that was introduced in Windows 10 is the Microsoft-Windows-Partition/Diagnostic event log.  Matt Graeber pointed out some of the data this log contains in October of 2017 and Harlan followed up shortly thereafter, but there doesn’t appear to be a great deal of information available outside of that, particularly with regard to how this event log can be leveraged in USB device investigations.  This is the first of a multi-part series that will break down pieces of this event log that are useful as it relates to USB device tracking.

Background

Introduced in Windows 10, the Partition/Diagnostic event log creates a new event record with ID 1006 when a device is connected to or disconnected from the system.  When viewed in the Windows event viewer, the default “General” view of these records is not exactly helpful, but the “Details” view includes many useful bits of information about the connected device.  Unfortunately, this event log appears to be cleared when a major Windows update (such as the Fall Creators Update) occurs so you will likely not have records in the current log dating back prior to the most recent major update.  However, the records that are present can provide you with a substantial amount of information about a particular device including device identifiers, connection times, disconnection times, the device volume boot record (VBR), device master boot record (MBR), and more.

Device Info from Event ID 1006

Device Volume Boot Record

Event ID 1006 of the Partition/Diagnostic event log contains a field for the volume boot record of a device that was connected to the system.  This field contains a hexadecimal string of the entire VBR of the device.  This is significant in USB device investigations because the VBR contains, among many other things, the volume serial number.  Additionally, if the USB device has a FAT-formatted file system, the volume name is available from the VBR.

As you know, the volume serial number is a critical link in correlating activity reflected in LNK files and jump lists with a particular device since the device VSN is embedded in both LNK files and jump lists.  The EMDMgmt subkey of the SOFTWARE registry hive may contain the volume serial number of connected devices, however, this subkey is not populated in some instances – including when Windows detects that it’s installed on a solid state drive.  Given the proliferation of SSDs, the overall usefulness of the EMDMgmt subkey is declining.  The good news is that despite a device’s VSN becoming less available from the EMDMgmt subkey, the VSN may still be available from the Partition/Diagnostic event log.

VSN Embedded in Event ID 1006

By saving the value of the VBR0 field (pictured above) to a new file, you can use any hex editor or tool capable of parsing raw VBRs to harvest the VSN, volume name, and other useful information from the volume boot record.  Another option would be to use a USB device forensics tool that handles all of the extraction, parsing, and correlation of all of this information for you (such as USB Detective).

The information found in the Partition/Diagnostic event log is useful in and of itself, but it can become even more powerful when correlated and combined with other sources of USB-related data, such as other event logs, registry hives, and setupapi logs.  In addition to the device volume boot record, there are other pieces of useful information that can harvested from the Partition/Diagnostic event log.  I plan to cover some of the other parts in follow-up posts – stay tuned for a breakdown of those bits.

Amcache and USB Device Tracking

Eric Zimmerman recently posted about updates to the amcache in Windows 10.  There are numerous additions to the new amcache format, including information about application shortcuts, device containers, and more.  This post is focused on the new information concerning storage devices tracked in the amcache, specifically in the Root\InventoryDevicePnp key.

Some of the useful bits of data that can be found through analysis of the amcache include device serial numbers, descriptions (e.g. FriendlyName-like values), volume names, VID/PID data, and more.  When a USB storage device is connected to a system, multiple subkeys in the amcache are created under Root\InventoryDevicePnp.  The following four keys have been observed to be associated with a device connection:

  1. swd/wpdbusenum/_??_usbstor#disk&ven_{manufacturer}&prod_{model}&rev_{rev}#{S/N or UID}#{53f56307-b6bf-11d0-94f2-00a0c91efb8b} (WPD class subkey)
  2. usbstor/disk&ven_{manufacturer}&prod_{model}&rev_{rev}/{S/N or UID} (diskdrive class subkey)
  3. storage/volume/_??_usbstor#disk&ven_{manufacturer}&prod_{model}&rev_{rev}#{S/N or UID}#{53f56307-b6bf-11d0-94f2-00a0c91efb8b} (volume class subkey)
  4.  usb/vid_{VID}&pid_{PID}/{S/N or UID} (USB class subkey)

Each of these four subkeys is created under Root\InventoryDevicePnp and will hold information about a connected device, with some information duplicated across two or more of the subkeys.  The Container ID of the device is present in each of the subkeys and can be used to easily link the information from each subkey.  The Container ID is helpful in tracking a device across other artifacts on a system as well since it is present in the USBSTOR subkey, the DeviceContainers subkey, and more.  Of the four subkeys listed above, the WPD class and diskdrive class subkey appear to contain the most useful information for identifying and profiling a USB device.

WPD Class Subkey

The WPD class subkey contains information such as the manufacturer, model/description, and the volume name/label of the device. Interestingly, I’ve seen instances in my testing where the volume name of a device is populated in the WPD class subkey when it is not available in other locations that it often exists (e.g. Windows Portable Devices key in the SOFTWARE hive).  This alone makes the WPD class subkey worth checking in order to help build a more complete profile of a USB device.

WPD Class Subkey

Diskdrive Class Subkey

The diskdrive class subkey contains information such as a description of the device (e.g. TOSHIBA External 3.0 USB Device) and the device serial number. The device serial number, along with VID/PID data, can be obtained from the ParentId value as well as the name of the subkey itself.  An example of a diskdrive class subkey name is: “usbstor/disk&ven_kingston&prod_dt_101_g2&rev_1.00/001372995dddcb6185180cdb&0”.

diskdrive Class Subkey

In my testing, the LastWrite time of all four class subkeys in the InventoryDevicePnp key is the same and is updated when a device is first connected, but it also appears to be updated through events outside of device connection/disconnection.  As such, the LastWrite time of these subkeys does not appear to be a reliable indicator of a connection or disconnection event.  I’ve also found that the subkeys related to some USB devices are quickly rolled out of the InventoryDevicePnp key.  In some instances, the most recently connected USB device was deleted after a system restart.  In other cases, the subkeys remained in the InventoryDevicePnp for some time.

The amcache doesn’t store the depth of USB device information found in the SYSTEM hive or other well-known locations, but it provides an additional data point that helps to corroborate and/or supplement data harvested from other areas.  For example, the Description value of the WPD class subkey can be used to gather the volume name/label of a device that was discovered through analysis of the SYSTEM hive by using the device serial or Container ID to correlate the two data points.  This method of analysis – using multiple data points across a system – will help to build a more complete profile of connected devices as well as increase your overall confidence in your findings.