Archive for shellbags

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.

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.