Archive for Windows Artifacts

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.

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.

Including Shellbag Data in Timelines

Windows shellbags hold a wealth of potential evidentiary value in forensic investigations.  There are already a few articles that detail the forensic impact of shellbags, including Chad Tilbury’s writeup on Windows 7 shellbags and a great article by Willi Ballenthin.  Metadata that is stored internally to the shellbags is of particular interest when it comes to forensic investigations.  Since shellbags are not parsed under the current version of log2timeline (0.62), my first thought was to write a module for log2timeline to incorporate shellbag data, however, my Perl abilities are not yet up to the task (although I’m working on them!).  So I instead decided to find a way to use existing tools to accomplish what I set out to do – incorporate shellbag data in my timeline.

With the latest release of SIFT, Willi Ballenthin’s shellbags.py script is included in the mix.  Shellbags.py, documented on Willi’s site, parses the shellbag data from a registry hive and outputs the result in bodyfile format.  This bodyfile can then be passed through mactime to obtain a timeline of events relating to a user’s shellbags.  Then, this timeline of shellbag data can be merged with a timeline from log2timeline.  To illustrate, I’ve included an example of combining MFT and shellbag timelines below.  Note that this assumes that the MFT and NTUSER.DAT have already been extracted from an image.

There are a couple of slightly different approaches that you can take when you know that you’ll be adding in shellbag data to a timeline.  The first is to create a bodyfile using log2timeline, add in the shellbag data, and then run mactime against the entire thing.  The second option is to run mactime against the two outputs before a bodyfile is ever created, and then merge those two timelines together.  Both options are shown below.

Option 1

  1. log2timeline -o mactime -f mft -z GMT my.mft > tln_body
  2. shellbags.py ntuser.dat >> tln_body
  3. mactime -d -b tln_body > timeline.csv

Option 2

  1. log2timeline -o mactime -f mft -z GMT my.mft | mactime -d -b – > timeline.csv
  2. shellbags.py ntuser.dat | mactime -d -b – | sed ‘1d’ – >> timeline.csv

Note that in the second option above, I piped the mactime output to “sed ‘1d’ -” because I wanted to eliminate the header row from my shellbag timeline before appending it to the existing timeline.  This way, I don’t have a header row in the middle of my timeline.  It likely wouldn’t make a difference during analysis, but I don’t like knowing that it’s there. It’s also important to point out that you’ll need to use the mactime output module of log2timeline if you plan on merging it with your shellbag timeline.  Running mactime against the current default output format of log2timeline will strip all of the values because the input of mactime will be different than the format that it expects.While a module to parse shellbag data will undoubtedly be added to log2timeline in the future, we at least have the option of manually adding shellbag data to an existing timeline now.  It may not always be necessary to include shellbags in a timeline during an investigation, however, in some cases it could add the context that is needed to connect the dots of removable devices or activity involving deleted folders.