Author Archive for Jason Hale

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.

Memory Acquisition and Virtual Secure Mode

Starting in Windows 10 and Server 2016, Microsoft added the option to enable various forms of virtualization-based security (VBS).  This feature suite currently includes Credential Guard, Device Guard, Application Guard, and more.  All of these optionts leverage virtual secure mode (VSM), which includes a secure kernel and secure user mode component and is made possible through the use of a hypervisor.  On the forensics side, encountering a system with virtual secure mode or some form of virtualization-based security enabled can have an impact on your investigation.  This post is about one of the more significant impacts I’ve seen thus far: memory acquisition.Physical memory is commonly acquired using a software-based memory acquisition tool such as winpmem, DumpIt, Magnet RAM Capturer, FTK Imager, or one of the several other options available.  These tools typically load a device driver into the kernel and subsequently read memory through mapping the DevicePhysicalMemory object, using a function such as MmMapIoSpace, or directly manipulating the page tables.  Many of these tools also share a similar trait: their use on a system with virtual secure mode enabled results in a system crash.

Result of attempted memory acquisition

Clearly, a BSOD while attempting to acquire physical memory from a system is not ideal.  If the system is an end-user machine, you will likely be left with a frustrated user (not to mention the obvious impact on your memory dump).  If the system is a more critical piece of the organization such as a server, the consequences of a system crash could extend well beyond the impact on your memory dump.  One way to avoid this scenario is to first determine whether virtual secure mode is enabled.One of the easiest ways to determine if VSM is enabled on a live system is to check whether the “Secure System” process is running.  This is the process associated with the secure kernel and, in my experience, serves as the “trigger point” as to whether a system will crash when running several memory acquisition tools.  Simply put, if the “Secure System” process is running, make sure you are using a tool that plays nice with virtual secure mode.

Task Manager view of system with VSM enabled

Most of the memory acquisition tools I’ve tested on a system with VSM enabled result in a system crash shortly after the acquisition driver is loaded.  The tested tools include multiple versions of winpmem, Magnet RAM Capturer, FTK Imager, and older versions of DumpIt.  The table below lists some of the unsuccessful tools I’ve identified.  I should note that the DumpIt v3 issue was not necessarily related to VSM; rather, it was a lack of an EV certificate that prevented the DumpIt driver from loading in the first place.

Fortunately, there are tools that currently dump memory even when VSM is enabled.  The tools I’ve identified at this point are Belkasoft RAM Capturer, Comae Technologies‘ DumpIt v3.0.20170620, and Passmark osforensics v5.1.1001.  There are also some tools that I have not yet been able to test due to licensing issues or otherwise.  These include options such as WindowsSCOPE and the combination of F-Response with a separate acquisition tool.  If anyone has a specific tool or version they would like to see tested, let me know and I’d be happy to give it a shot and report the results as long as the tool is available to me.

Update (9/6/17): I was able to use a trial license of WindowsSCOPE to test memory acquisition from a system with VSM enabled. WindowsSCOPE was not able to acquire a memory dump, but it did not result in a system crash.  Instead, a small error message reported that the selected memory “could not be fetched”.  The table above has been updated with these results.

Update (9/11/17): According to Stick Dave, the lastest version of winen (as of 9/11/17) fails to acquire memory from a system with VSM enabled.  Like many other tools, it fails with a BSOD.

Fun with Recycle Bin $I Files & Windows 10

A few weeks back, I found myself in need of a free tool to parse $I files from Windows Vista+ recycle bins.  For anyone needing a refresher, $I files store metadata regarding the act of sending a file to the recycle bin in Windows Vista and later.  These $I files essentially replace the functionality of the INFO2 file used in Windows XP and store information such as the name and original path of a file before it was sent to the recycle bin as well as the time the file was sent to the recycle bin.  The file format itself is trivial to manually parse in a hex editor, but I wanted to be able to demonstrate the value of the $I files to students in a class I was teaching without the need for a hex editor.  I also wanted the students to be able to easily parse these files on their own.  I was aware of a couple of free tools that parse $I files, but couldn’t find one that was exactly what I was looking for – so I decided to write one and provide it to my students. I doubt that I’m the only one to encounter this, so I’ve released this simple $I file parser in case someone else finds that they have a need for it.  The link is at the bottom of this post for those interested.

One of the intriguing things I came across in writing this tool is that $I files from Windows 10 recycle bins vary slightly from those in Vista through 8.1.  The change is not significant, but it is enough to potentially throw off some $I file parsers.  The slight change also provides us with the ability to distinguish between $I files originating from a Windows 10 system and those originating from a Vista/7/8/8.1 system.  This piece of information could be important in some instances.  For example, if you encounter an $I file in the unallocated space of a Windows 10 system, you could determine if that file was an artifact from a previous non-Windows 10 installation.  Given the ability to distinguish Windows 10 $I files from previous versions, I’ve included a version field in the output of my $I file parser so that this information is reported.The difference I’ve noted between the Windows 10 $I file structure and that from previous versions of Windows is detailed below.

$I structure prior to Win 10

Windows 10 $I structure

 

 

 

 

As you can see, the only structural change in the Windows 10 version appears to be the addition of the file name length field at offset 24.  This will typically result in $I files from Windows 10 systems being smaller than in prior versions since the $I file is only as large as it needs to be.  In prior versions, each $I file was a static 544 bytes.  While not structural, another change can be found in the header/version field.  The header field for Vista, 7, 8, and 8.1 is 0x01, while this field is 0x02 for Windows 10.  This makes it very easy to distinguish between the two versions when parsing.

For those interested, the link to download my $I file parser can be found on the download page here.

Adobe Reader’s Not-So-cRecentFiles

Version 11.0.07 of Adobe Reader, released in May 2014, introduced some interesting changes that can impact forensic examination.  With previous versions of Reader for Windows, the cRecentFiles subkey found in the Acrobat Reader subkeys of an NTUSER.DAT hive provided an examiner with the five most recent files accessed by Adobe Reader.  Information about these files was divided into five subkeys named “c1”, “c2”, “c3”, etc., with each subkey containing a bit of information about the accessed file.  Version 11.0.07 of Adobe Reader expanded this capability, tracking much more than just the five most recently accessed files.  Additional information is also recorded about each accessed file, as well as a list of the
five most recently accessed folders.

The screenshot below shows the new look of the “c#” subkeys that store information about recent files accessed in Adobe Reader version 11.0.07 and above.  Note that the full path to these subkeys is found in a user’s NTUSER.DAT hive under “SoftwareAdobeAcrobat Reader<version>AVGeneralcRecentFilesc#”.

Values in a cRecentFilesc# subkey

The new values added to the “cRecentFilesc#”subkeys are
“sDate”, “uFileSize”, and“uPageCount”.  The “uFileSize” and “uPageCount” are pretty self-explanatory, storing the size of the file in bytes and the number of pages in the accessed file, respectively.

sDate value data

The “sDate” value stores the last time that the file was accessed in Adobe Reader.  The “sDate” value type is REG_BINARY, but the value data holds a simple ASCII string of the timestamp.  Interestingly, the time zone offset of the system at the time the file is opened is included in the “sDate” value data.  If the time zone of the system is changed, the offset included in the “sDate” value is reflected accordingly for files that are later opened in Adobe Reader.  This provides examiners with a more more granular view of when files were accessed in Adobe Reader, as previous versions only allowed us to determine the last time the most recent PDF was accessed.

The five most recently accessed folders are also tracked by
Adobe Reader version 11.0.07 and later in a “cRecentFolders” subkey under “HKCUSoftwareAdobeAcrobat Reader<version>AVGeneral”.  Recently accessed folders are maintained in a similar fashion as the recently accessed files, but the level of detail associated with each accessed folder is pretty minimal.  Each “c#” subkey provides us with the name and path of the accessed folder via the tDIText (or sDI) value, and we can correlate the Last Write time of the cRecentFolders subkey with time that the most recent folder was accessed.

Values in a cRecentFoldersc# subkey

Perhaps the most significant change from a forensic perspective in Adobe Reader version 11.0.7 and later is the alteration to the number of files tracked in the cRecentFiles subkey.  Instead of the most five most recent files that are tracked in previous versions, Adobe Reader 11.0.7 appears to track the 50 most recently accessed files.  In version 11.0.9, the maximum number of recently accessed files jumps to 100.  After testing the current version of Adobe Reader DC, 100 still appears to be the maximum.  This means that you could have up to 100 “c#” subkeys under the cRecentFiles key!  After 100 documents have been accessed, the subkeys will be reused in a FIFO fashion as seen in previous versions of Adobe Reader (e.g. the contents of subkey c100 will be removed and replaced with the contents of c99).

cRecentFiles with 100 subkeys

Examiners should be aware of this additional functionality in Adobe Reader in order to take advantage of the historical information it provides.  The cRecentFiles subkey from a user’s active NTUSER.DAT hive can provide a nice list of files accessed by Adobe Reader.  With later versions storing up to 100 “recently” accessed files, the cRecentFiles subkeys could end up storing files that were not-so-recently accessed as well.  Further, when combined with previous versions of the user’s NTUSER.DAT hive from volume shadow copies, an examiner may be provided with quite a detailed history of files accessed using Adobe Reader.