Archive for October 2017

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.

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.