Updates

Things tend to move fast in the DFIR world sometimes, and since my last post, there have been some updates to some of the things that were mentioned/discussed, and those updates were important enough that I thought that they needed to be visible.

Page_brute
Robert has updated his blog post on restoring Windows CMD sessions from the pagefile; the update includes an updated Yara rule.

AmCache
Thanks to some data shared by a friend, I was able to see that not all of the File subkeys in the AmCache.hve file will have a SHA-1 hash listed.  This does nothing to obviate Yogesh's work in this area; in fact, I would suggest that it opens the question of what data is recorded and under which circumstances, making this an even more important resource.  I'd sent Mari a copy of the RegRipper amcache.pl plugin to try out, and she found that it crashed...it turns out this was due to the fact that not all of the subkeys had a value named "101" (see Yogesh's blog post with the values listed); I got that fixed right away.

Yogesh has since posted part 2 of his series of blog posts discussing the AmCache.hve file.  Yogesh addresses other subkeys within the AmCache.hve file, as well as some other files within the same folder.  If you're at all interesting in seeing some of what's new in Windows 8/8.1, specifically for DFIR analysts, take a look.

Shellbags
Thanks to Dan's research regarding shellbags artifacts, as well as his willingness to share his test data, I've been updating the RegRipper shellbags.pl plugin.  As of now, it's capable of parsing the type 0x52 shell items that Dan found, and it provides the key path for the resources.  So, instead of just:

Control Panel\User Accounts\Create Your Password 
Control Panel\User Accounts\Change Your Picture 

...now you'll see:

Control Panel\User Accounts\Create Your Password [Desktop\0\3\0\0\]
Control Panel\User Accounts\Change Your Picture [Desktop\0\3\0\1\]

The purpose of this is to allow analysts to validate what they're seeing much more easily.  Using this additional information, analysts can validate the embedded DOSDate MAC times, among other things.

I hope that this blog post helps analysts understand the embedded DOSDate time stamps within shell items.

With respect to shellbags, something "interesting" I've found is that the MFT file reference that can be found in some shell items that comprise the shellbags artifacts can a bit misleading; well, maybe not "misleading" but not easily validated. While I've been able to validate the accuracy of this information for folders on local hard drives (I have the MFT as well as the USRCLASS.DAT hive in some data sets), for removable drives and other resources, the data cannot be validated without the MFT from that external resource.  As such, at this point, I'm debating whether to provide the MFT file reference in the plugin output, or comment out that code (which would allow someone to un-comment it).

Part of the reason why I'm debating (with myself, mostly) whether or not to provide this information in the output of the plugin is that right now, there's a great deal of information being displayed, and I'm afraid that not all of it is all that well understood.  I've seen analysts try to fit the data they're seeing in the tool output to their theory by assuming (albeit incorrectly) what the data means, and that just doesn't work.  In fact, it can be disastrous to the examination.

For example, here's an extract from the output of the current version of the shellbags.pl plugin, run against a sample data set:

| 83/8           |My Computer\D:\VM [Desktop\1\2\5\]
| 275/2         |My Computer\D:\VM\Win2008 [Desktop\1\2\5\0\]
| 84/6          |My Computer\D:\VM\Win7 [Desktop\1\2\5\1\]
| 5402/3       |My Computer\D:\VM\Win2003 [Desktop\1\2\5\2\]
| 5410/2       |My Computer\D:\VM\XP2 [Desktop\1\2\5\3\]
| 5422/6       |My Computer\D:\VM\XP3 [Desktop\1\2\5\5\]
| 404/43       |My Computer\D:\test [Desktop\1\2\6\]
| 405/43       |My Computer\D:\vsc [Desktop\1\2\7\]

Now, I have the image of the system from which this data was extracted, so I've been able to extract and parse the MFT in order to verify the MFT file references, which are listed as the MFT record number, followed by the sequence number.  So, for an analyst that has an image, or even just the hive file and the MFT available, it's a simple matter to determine whether the path listed in the output of the tool can be referenced to a current record in the MFT, or to an older, historic record.  An example of this would be where the MFT file reference for the D:\test folder (as illustrated above) is "404/43" in the shellbags, but MFT record 404 in the current MFT has a higher sequence number (44 or above) and a different name.

Okay, as if that's not confusing enough, what happens if you have MFT file references for paths that are NOT on hard drive local to the system?  Consider the following:

| 136/5        |My Computer\F:\seattle\Tools [Desktop\1\1\36\0\]
| 556/37      |My Computer\F:\seattle\Tools\case2 [Desktop\1\1\36\0\0\]
| 560/3        |My Computer\F:\seattle\Tools\case1 [Desktop\1\1\36\0\1\]

In this case, this information was pulled from one of my own systems, and I know that the F:\ volume was, in fact, an external USB-connected wallet drive.  Without the MFT from the wallet drive, this information cannot be validated.  Is this data then useful?

How Valuable Is Data?
All of this brings up a very important question...specifically, what data is valuable, and how valuable is it? Can value be assessed differently by different analysts, or is data value somewhat universal?

What is the value of the data if it is misunderstood by the analyst? Is the value of the data diminished if the analyst follows it down the wrong path, based on misunderstood data and incorrect assumptions?

Here's an example - below at the embedded MAC times taken from the D:\VM\Win2003 entry above:
M: 2011-08-18 23:55:46
A: 2011-08-18 23:55:46
C: 2011-08-18 23:48:32

What do these time stamps mean? What is the "value" of this data?

SAM Hive
Lance posted an EnScript that parses the SAM Registry hive file and displays the users in each security group.

This has been an integral part of the RegRipper samparse.pl plugin for some time now, and it's great to see the need for this information being recognized and brought to other tools.

Addendum, 17 Dec: On the heels of Corey's RecentFileCache.bcf post, Lance has written an EnScript to parse the file.  I told you...sometimes you can go weeks without anything going on in the DFIR world, and then all of sudden, things start to happen fast!

Addendum, 18 Dec: Corey posted another PCA article, this one addressing Registry keys that maintain data (not configuration information) regarding indicators of program execution.  Great stuff!