Wednesday, October 31, 2012

Shellbag Analysis, Revisited...Some Testing

I blogged previously on the topic of Shellbag Analysis, but I've found that in presenting on the topic and talking to others, there may be some misunderstanding of how these Registry artifacts may be helpful to an analyst.  With Jamie's recent post on the Shellbags plugin for Volatility, I thought it would be a good idea to revisit this information, as sometimes repeated exposure is the best way to start developing an understanding of something.  In addition, I wanted to do some testing in order to determine the nature of some of the metadata associated with shellbags.

In her post, Jamie states that the term "Shellbags" is commonly used within the community to indicate artifacts of user window preferences specific to Windows Explorer.  MS KB 813711 indicates that the artifacts are created when a user repositions or resizes an Explorer windows.

ShellItem Metadata
As Jamie illustrates in her blog post, many of the structures that make up the SHELLITEMS (within the Shellbags) contain embedded time stamps, in DOSDate format.  However, there's still some question as to what those values mean (even though the available documentation refers to them as MAC times for the resource in question) and how an analyst may make use of them during an examination.

Having some time available recently due to inclement weather, I thought I would conduct a couple of very simple tests in to begin to address these questions.

Testing Methodology
On a Windows 7 system, I performed a number of consecutive, atomic actions and recorded the system time (visible via the system clock) for when each action was performed.  The following table lists the actions I took, and the time (in local time format) at which each action occurred.

Action Time
Create a dir: mkdir d:\shellbag 12:54pm
Create a file in the dir: echo "..."  > d:\shellbag\test.txt 1:03pm
Create another dir: mkdir d:\shellbag\test 1:08pm
Create a file in the new dir: echo "..." > d:\shellbag\test\test.txt 1:16pm
Delete a file: del d:\shellbag\test.txt 1:24pm
Open D:\shellbag\test via Explorer, reposition/resize the window 1:29pm
Close the Explorer window opened in the previous step 1:38pm

The purpose of having some time pass between actions is so that they can be clearly differentiated in a timeline.

Once these steps were completed, I restarted the system, and once it came back up, I extracted the USRCLASS.DAT hive from the relevant user account into the D:\shellbag directory for analysis (at 1:42pm).  I purposely chose this directory in order to determine how actions external to the shellbags artifacts affect the overall data seen.

 Results
The following table lists the output from the shellbags.pl RegRipper plugin for the directories in question (all times are in UTC format):

Directory MRU Time Modified Accessed Created
Desktop\My Computer\D:\shellbag 2012-10-29 17:29:25 2012-10-29 17:24:26 2012-10-29 17:24:26 2012-10-29 16:55:00
Desktop\My Computer\D:\shellbag\test 2012-10-29 17:29:29 2012-10-29 17:16:20 2012-10-29 17:16:20 2012-10-29 17:08:18

Let's walk through these results.  First, I should remind you that that MRU Time is populated from Registry key LastWrite times (FILETIME format, granularity of 100 ns) while the MAC times are embedded within the various shell items (used to reconstruct the paths) in DOSDate time format (granularity of 2 seconds).

First, we can see that the Created dates for both folders correspond approximately to when the folders were actually created.  We can also see that the same thing is true for the Modified dates.  Going back to the live system and typing "dir /tw d:\shell*" shows me that the last modification time for the directory is 1:42pm (local time), which corresponds to changes made to that directory after the USRCLASS.DAT hive file was extracted.

Next, we see that MRU Time values correspond approximately to when the D:\shellbag\test folder was opened and then resized/repositioned via the Explorer shell, and not to when the Explorer window was actually closed.

Based on this limited test, it would appear that the DOSDate time stamps embedded in the shell items for the folders correspond to the MAC times of that folder, within the file system, at the time that the shell items were created.  In order to test this, I deleted the d:\shellbag\test\test.txt file at 2:14pm, local time, and then extracted a copy of the USRCLASS.DAT and parsed it the same way I had before...and saw no changes in the Modified times listed in the previous table.

In order to test this just a bit further, I opened Windows Explorer, navigated to the D:\shellbag folder, and repositioned/resized the window at 2:21pm (local time), waited 2 minutes, and closed the window.  I extracted and parsed the USRCLASS.DAT hive again, and this time, the MRU Time for the D:\shellbag folder had changed to 18:21:48 (UTC format).  Interestingly, that was the only time that had changed...the Modified time for the D:\shellbag\test folder remained the same, even though I had deleted the test.txt file from that directory at 2:14pm local time ("dir /tw d:\shellbag\te*" shows me that the last written time for that folder is, indeed, 2:14pm).

Summary
Further testing is clearly required; however, it would appear that based on this initial test, we can draw the following conclusions with respect to the shellbag artifacts on Windows 7:

1.  The embedded DOSDate time stamps appear to correspond to the MAC times of the resource/folder at the time that the shell item was created.  If the particular resource/folder was no longer present within the active file system, an analyst could use the Created date for that resource in a timeline.

2.  Further testing needs to be performed in order to determine the relative value of the Modified date, particularly given that events external to the Windows Explorer shell (i.e., creating/deleting files and subfolders after the shell items have been created) may have limited effect on the embedded dates.

3.  The MRU Time appears to correspond to when the folder was resized or repositioned.  Analysts should keep in mind that (a) there are a number of ways to access a folder that do not require the user to reposition or resize the window, and (b) the MRU Time is a Registry key LastWrite time that only applies to one folder within the key...the Most Recently Used folder, or the one listed first in the MRUListEx value.

I hope that folks find this information useful.  I also hope that others out there will look at this information, validate it through their own testing, and even use it as a starting point for their own research.

No comments: