Archive for diagnostic

USB Device Tracking using the Partition/Diagnostic Event Log – Part 2

In my last post, I discussed using the Partition/Diagnostic Event Log in Windows 10 for USB device tracking.  Specifically, we looked at the volume boot record (VBR) available in this event log and what it means to a forensic investigation.  In this post, I’ll continue by examining the device master boot record (MBR) that is available in this event log and discuss how it can be leveraged in a forensic examination.

Event ID 1006 of the Partition/Diagnostic event log contains a field for the MBR of a device that was connected to the system. This field is used to store a hexadecimal string of the entire MBR of the device at the time the event record was created.  The MBR often contains boot code, the disk signature, and the disk partition table.  In addition to the partition table embedded in the MBR, the raw partition table bytes are included as a separate field in Event ID 1006.  It’s also worth noting that GPT disks are handled differently than MBR disks when it comes to this event log.  I’ll save the partition table and differences in GPT handling for a later discussion and will focus on the disk signature from an MBR drive in this post.

The \MountedDevices subkey has historically been used to determine the last drive letter and/or the volume GUID associated with a removable device by correlating the serial number or ParentIdPrefix stored in the \DosDevices\X: or \??\Volume{GUID} value data with its corresponding device.  This is well documented (here, here, here, and many other places).  However, the  value data available in the \MountedDevices subkey for a fixed device (such as an external hard drive) stores the disk signature of the device instead of the serial number or ParentIdPrefix.  This means that determining the previous drive letter of a fixed device using the \MountedDevices subkey requires that you know the disk signature of the fixed device.

The disk signature is a 4-byte value located at decimal offset 440 of the MBR and is easily obtained from the external device itself, but it’s difficult to come by without access to the device.  This is why obtaining the MBR from Event ID 1006 is so valuable – it provides the examiner with a means to determine a device’s disk signature without access to the device itself.

Disk Signature Embedded in Event ID 1006

By saving the value of the MBR field (pictured above) to a new file, you can use any hex editor or tool capable of parsing raw MBRs to obtain the disk signature from the MBR.  After determining the disk signature, you can then try to match the disk signature up with the value data in the \MountedDevices subkey to find a drive letter with which the disk was associated.  Another option would be to use a tool such as USB Detective that handles the extraction, parsing, and correlation of all of this information for you.  Regardless of your approach, the Partition/Diagnostic Event Log should be included in your USB device investigations.

USB Device Tracking using the Partition/Diagnostic Event Log – Part 1

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.