Digital Forensics Stream
Findings, tips, and tools developed while trekking through the world of digital forensics

Archive for Windows 10

Posted by Jason Hale 
· October 19, 2019 
· 2 Comments

ShellBags & Windows 10 Feature Updates

Windows 10 feature updates have far reaching impacts on a digital forensic investigation. Released twice a year in Windows 10, these updates essentially install a new version of the Windows operating system when they’re applied. From clearing event logs to removing common USB storage registry subkeys and more, feature updates touch many artifacts often relied upon in digital investigations.

ShellBags are a popular artifact in Windows forensics often used to identify the existence of directories on local, network, and removable storage devices. ShellBags are stored as a highly nested and hierarchal set of subkeys in the UsrClass.dat registry hive of Windows 10 systems (although they’ve been around since much earlier versions of Windows). The structure and layout of shellbags has been covered in numerous locations (such as here and here), so I won’t be detailing that.  Instead, the focus of this post is to highlight the impact of Windows 10 feature updates as it relates to the interpretation of shellbags in a forensic investigation.

One of the data points that can be leveraged during shellbag analysis is the LastWrite time of various subkeys within the BagMRU hierarchy in an attempt to identify the first and last interacted times of a directory referenced by shellbags. The methodology used to identify these times, which leverages the MRUListEx values in conjunction with subkey LastWrite times, was detailed by Dan Pullega back in 2013 and later described in an episode of David Cowen’s forensic lunch. It was also incorporated into some shellbag forensic tools. While the interaction times of a directory referenced in shellbags can be extremely valuable, they come with some caveats for later versions of Windows 10.

During the process of installing a Windows 10 feature update, testing has shown that the LastWrite time of all subkeys in the BagMRU hierarchy are updated.  This looks to be the case with versions dating back to at least 1709 and up through the latest feature update (1903 at the time of this writing).  Since the LastWrite time of these subkeys is used to illustrate an interaction time with a directory, this eliminates the examiner’s ability to use the active UsrClass.dat hive to reliably determine interaction times that occurred prior to the most recent feature update.  As an example, the below screenshot illustrates the view of a couple of shellbag entries just prior to the 1803 feature update being applied to a system.

View of ShellBags Prior to Feature Update

The next screenshot below is from the same shellbag entries on the system after the 1803 feature update was applied on May 9, 2018.  As you can see, the first and last interacted timestamps have been updated to May 9, 2018.  The interaction times here are simply pulled from the LastWrite time registry subkeys.  The LastWrite time of the subkeys was changed during the feature update.

View of ShellBags After a Feature Update

This change wouldn’t necessarily stand out if you were focusing on a single location within the system shellbags. However, when the first/last interacted times (or the LastWrite times of UsrClass.dat subkeys) are viewed in aggregate, it becomes clear that they have been updated en masse.

Interaction Times After a Feature Update

One thing to note in this example is that the directory file system timestamps (such as the Created On timestamp included in the screenshots above) that are included in the shellbag extension blocks remain unchanged across feature updates.  However, the first and last interaction methodology that relies upon the LastWrite time of registry subkeys is limited by Windows 10 feature updates.  If a directory referenced in the shellbags is interacted with after a feature update, the associated LastWrite time should be as reliable as it has been for identifying an interaction time.  Directories that have not been interacted with since the most recent feature update will not have a reliable interaction time available in the active UsrClass.dat since any interaction time previously available for the directory was updated during the feature update.

This issue is reminiscent of the problems caused when various USB-related subkey LastWrite times were updated en masse.  As with the USB-related subkeys though, understanding the limitations of the data points that are being relied upon – registry subkey LastWrite times in this example – will allow an examiner to more effectively and accurately leverage the artifact.

2 Comments
Categories : Registry Forensics, Windows 10, Windows Artifacts
Tags : , , ,
Posted by Jason Hale 
· July 17, 2018 
· No Comments

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.

No Comments
Categories : Event Logs, USB Device Forensics, Windows 10
Tags : , , , , , ,
Posted by Jason Hale 
· May 1, 2018 
· No Comments

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.

No Comments
Categories : Event Logs, USB Device Forensics, Windows 10
Tags : , , , , ,
Posted by Jason Hale 
· October 19, 2017 
· No Comments

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.

No Comments
Categories : Registry Forensics, USB Device Forensics, Windows 10, Windows Artifacts
Tags : , ,
Posted by Jason Hale 
· October 7, 2017 
· 3 Comments

RecentApps Registry Key

While digging into a Windows 10 NTUSER.DAT hive recently, I came across a registry key/subkey hierarchy that was really intriguing.  The top level key, called RecentApps, contained references to several applications and files that had been accessed on the system.  In addition to the application and file name, I found that the path to the application, a launch count, the full path to the file, and the last time the file was accessed was available from the RecentApps key hierarchy.

The RecentApps key is located in the user’s NTUSER.DAT hive at Software\Microsoft\Windows\Current Version\Search\RecentApps. Its general hierarchy looks something like the image below.  Beneath the RecentApps key is a series of subkeys named by GUIDs.  Each GUID subkey directly under RecentApps corresponds to an application.  Some of the GUID subkeys have additional subkeys as well, which correspond to particular files accessed by the application.

RecentApps key hierarchy

Application GUID Subkeys

As mentioned, the subkeys directly under RecentApps are associated with applications.  Each of these GUID subkeys contain values that may be of useful during an examination, such as the full path to the application, a last accessed time, and a launch count.  The LastAccessedTime value is in the ever-popular 64-bit FILETIME format.  In my experience, both the LastAccessedTime and LaunchCount values have been consistent with the last execution and run count data available in the UserAssist key.

RecentApps File Subkey

File GUID Subkeys

Each subkey under an application GUID’s “RecentItems” subkey is associated with a file accessed by the application and is also named by a GUID.  The information included in each file GUID subkey includes the file name, a last accessed time (in some cases), the full path of the file, and more.

The last accessed time, when present, is a FILETIME value and appears to be consistent with the last accessed time available from jump lists in the file system.  Unfortunately, this value does not appear to be populated in many cases.  Windows 10 Professional version 1703 build 15063.483 has been observed with the LastAccessedTime value populated, but in all other tested versions of Windows 10 – both before and after the release of 15063.483 – this value appears to be set to zero.  Fortunately, an access time for the file referenced by the file GUID subkey can be determined using the LastWrite time of the file GUID subkey itself.  Importantly, the LastWrite time does not appear to be updated on subsequent access to the file, so the LastWrite time should not be concluded as the last time the file was accessed without further corroborating evidence from other artifacts.

RecentApps\RecentItems Subkeys

The number of file GUID subkeys under each application GUID key appears to be limited to 10.  Interestingly, the cycling of these subkeys does not appear to be on a first-in-first-out basis (as with many other artifacts in Windows).  Instead, it appears that when an eleventh subkey is added to an application GUID key, the file GUID subkeys are arranged alphabetically by name.  After being arranged alphabetically, the last one in the list is removed.  Since the alphabetization is by GUID, it is inherently random which 10 files that were accessed by an application will be included in the list of file GUID subkeys .  The method of cycling utilized by the file GUID subkeys means that an examiner cannot conclude that the files referenced by these subkeys are the 10 files most recently accessed by a particular application.

Data points such as the RecentApps key hierarchy in Windows 10 help to provide corroborating information to increase an examiner’s overall confidence in his or her findings.  If any type of anti-forensic measures were taken (system or user initiated), locations such as the RecentApps key may also provide information that was deleted from other and more well known areas of the system.

3 Comments
Categories : Registry Forensics, Windows 10
Tags :

Twitter

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

DISCLAIMER

The contents of this blog reflect my opinion and may not represent the views of my employer or anyone else.  Any material on this blog, especially related to technology and/or forensic methodology should not be assumed to be true in all possible scenarios.  As always, test any theories, ideas, or tools from this blog in your own environment before stating them or the results therefrom as factual.