Tuesday, August 26, 2014

Forensic FOSS: 4n6k_volatility_installer.sh - Install Volatility For Linux Automatically

Introducing FORENSIC FOSS! These posts will consist of open source software for use in everyday forensic investigations.

What Is It?
4n6k_volatility_installer.sh is a bash script that installs Volatility 2.4 (and all dependencies) for Ubuntu Linux with one command.

Why Do I Need It?
Compiling source on Linux can be a pain. Dependency hunting wastes time and drives people away from considering Linux builds of cross-platform software. With this script, you can (1) skip all of the dependency frustration, (2) get right into using the newest version of Volatility, and (3) leverage the arguably more powerful and versatile *nix shell. No longer do you have to worry about whether or not you "have everything."

What's Required?
An internet connection and an APT-based Linux distribution [for the time being]. This script has been tested on stock Ubuntu 12.04 and Ubuntu 14.04. Some testing has been done to support SIFT Workstation 3.0.

What Does It Do?
Specifically, 4n6k_volatility_installer.sh does the following:
  • Downloads, verifies, extracts, and installs source archives for everything you will need to complete a full installation of Volatility 2.4:
    • Volatility 2.4
    • diStorm3
    • Yara (+ magic module) + Yara-Python
    • PyCrypto
    • Python Imaging Library + Library Fixes
    • OpenPyxl
    • IPython
    • pytz
  •  Adds "vol.py" to your system PATH so that you can run Volatility from any location.
  • Checks to see if you are using SIFT 3.0 and applies some fixes. 
How Do I Use It?
Volatility will be installed to the directory you specify.
  • From a terminal, run: 
    • sudo bash 4n6k_volatility_installer.sh /home/dan
In the above example, the following directories will be created:
  • /home/dan/volatility_setup 
    • Contains dependency source code and the install_log.txt file.
  • /home/dan/volatility_2.4
    • Contains the Volatility 2.4 install.
You must enter a full path for your install directory.
Where Can I Download It?
You can download the script from my Github page or by right clicking and saving this link.

Check the Github page for the script's MD5 hash.

Bottom Line?
Don't be afraid of the terminal. Read the source for this script and understand how it works. Automation is acceptable only after you understand what is happening behind the scenes.

I'm open to making this script better. If you see a problem with the code or can suggest improvements, let me know and I'll see what I can do.

Thanks to the Volatility team for writing an amazing tool. Go to http://www.volatilityfoundation.org for more info. Thanks to @The_IMOL, Joachim Metz, @dunit50, and @iMHLv2 for feedback.

Wednesday, April 16, 2014

Forensics Quickie: Merging VMDKs & Delta/Snapshot Files (2 Solutions)

FORENSICS QUICKIES! These posts will consist of small tidbits of useful information that can be explained very succinctly.

Scenario
I had a VM that was suspended. I needed to see the most recent version of the filesystem. Upon mounting the base .vmdk file, I was presented with the filesystem that existed before the snapshot was taken.

Solution #1
(turns out I ran into a similar problem before...see my post on Mounting Split VMDKs).

The issue lies within the fact that when you create a VM snapshot, "all writes to the original -flat.vmdk are halted and it becomes read-only; changes to the virtual disk are then written to these -delta files instead"[2]. So basically, when I was mounting the base .vmdk file (the "someVM-flat.vmdk"), I wasn't seeing anything that was written to the disk after the snapshot was created. I needed a way to merge the delta files into the -flat file.

To further explain what I was working with, I had three .vmdk files:
  1. Win7.vmdk (1KB in size; disk descriptor file; simply pointed to the -flat.vmdk)
  2. Win7-flat.vmdk (large file size; the base .vmdk file)
  3. Win7-000001.vmdk (delta/snapshot file; every write after the snapshot is stored here)
*Note that this image was not split. If it was, I would just use the method detailed in my other post

As mentioned, I needed to merge these all into one to be able to mount the .vmdk and see the most recent version of the filesystem. VMware includes a CLI tool for this. It is stored in the "Program Files\VMware" folder. Run this command.

vmware-vdiskmanager.exe –r Win7-000001.vmdk –t 0 singleFileResult.vmdk

Note that the .vmdk file being used as input should be the .vmdk for the latest snapshot. You can confirm which .vmdk file this is by checking the VM's settings.


You can also define what kind of disk you want to output, as well. I have never found it necessary to use anything other than 0.
 

You can now mount the new .vmdk to see the most recent version of the file system. I *imagine* you could do this for previous snapshots if you define the proper .vmdk. But I have not tested that.

Solution #2
The other solution, which I wound up using after finding out how to do it correctly, is to import the .vmdk files in order within X-Ways. If you try to import a delta file before the base .vmdk, X-Ways will throw an error saying:

"In order to read a differencing VMDK/VHD image, the corresponding parent must be (and stay) opened first. They should be opened in order of their last modified dates - oldest first, skipping none."

So, I did as it said; I imported Win7.vmdk, then Win7-000001.vmdk. It's that easy.

Though this method may become cumbersome with many snapshots/delta files, you would be able to incrementally see what writes had been made to each snapshot. Just be careful when adding delta files for snapshots that depend on previous snapshots (see below).

VMware's Snapshot Manager showing snapshot dependencies.

Thanks to Eric Zimmerman, Jimmy Weg, and Tom Yarrish for helping with the X-Ways method.

-Dan Pullega (@4n6k)

References
1. Consolidating snapshots in VMware Fusion
2. Understanding the files that make up a VMware virtual machine

Saturday, March 29, 2014

Forensics Quickie: Verifying Program Behavior Using Source Code

FORENSICS QUICKIES! These posts will consist of small tidbits of useful information that can be explained very succinctly.

Recently, I stumbled upon a question related to the behavior of a given program. That program was Mozilla Firefox and the behavior in question was how profile directory names were generated. Through this post, I will cover how to approach this question and how to solve it with available resources (source code).

The Question
How are Firefox profile directory names generated?

The Answer (and the road to get there)
To answer this question, we first have to understand which artifacts we are examining. In this case, we are dealing with Firefox profiles. Those are located in a user's AppData folder. By navigating AppData, we eventually find C:\Users\someUser\AppData\Roaming\Mozilla\Firefox\Profiles.

The Firefox 'Profiles' folder showing the directory for the profile named "default."

We see a folder for the only Firefox profile used on the system. Reasonably, this account is named "default" by default. But what about that seemingly random prefix?

Let's see if we can glean anything from trying to create a profile in Firefox. First, let's open up the Profile Manager by typing "firefox.exe -p" in the 'Run...' dialog (Windows key + R).

We can confirm that there is only one profile and it is named "default."

When we try to create a profile, we see the following window:


Great. We can actually see where it is going to be saved. And no matter what we enter in the text input field, the prefix stays the same. This tells us that the folder for this new profile isn't generated based on the profile name we enter. But there are other possibilities, such as the folder name being based on the current time.

There are many other tests we could run, but we actually don't need to -- the source code for Firefox is freely available online. Once we download and extract the source code, we can try to find the function that handles the generation of the profile's folder name.

Uncompressed, the Firefox source code is about 585MB. That's a lot of code to review. A better way to sift through all of this data is to either index it all and search it or to just recursively grep the root folder. I decided on the latter.

To find out where to look first, we can try to find a constant, unique phrase around the text in question. In the above image, the string "Your user settings, preferences and other user-related data will be stored in:" is right before the path name with which we are concerned. So let's grep for that and see if we can find anything.

There are many ways to grep data, but this was a quick and dirty job where I wasn't doing any parsing or modifying, so I used AstroGrep. I went ahead and searched for the a watered down version of the aforementioned unique phrase: "will be stored in." The results showed that the file named CreateProfileWizard.dtd contained this unique phrase (there were many files that were responsive, but based on the phrase's context and the filename for the file in which the phrase was found, we can determine relevancy).

A snippet of the responsive "CreateProfileWizard.dtd"  file containing our unique phrase.

Now, it's just a matter of tracing this phrase back to its source. So we grab another unique phrase that is relevant to our discovery, such as "profileDirectoryExplanation," and see if we can find any more relevant files. Grepping for it comes back with more results -- one of which is createProfileWizard.xul. I didn't see much in this file at first glance (though there is quite bit of good info such as "<wizardpage id="createProfile" onpageshow="initSecondWizardPage();">" -- which will be seen soon), so I decided to see what else was in same directory as this file. There, I found createProfileWizard.js.

A snippet of the "createProfileWizard.js" file showing the functions used to generate the profile directory names.

Skimming the code, we can see that a salt table and Math.random() are used to determine the 8 character prefix. At line 68, we see the concatination of kSaltString ('0n38y60t' in the animated gif), a period ('.'), and aName (our text input field variable -- in our example, "abcdefg" or "4n6k").

In the end, the point is that having source code available makes research more streamlined. By looking at the Firefox source, we were able to determine that the profile directory names aren't based on a telling artifact.

Using what is available to you is invaluable. By having a program's source code [and approaching an issue with an analytic mindset], verifying program behavior is made so much easier.

I'll end with this: open source development is GOOD -- especially for forensics. Whether it's a tool meant to output forensic artifacts or just another Firefox, we are able to more confidently prove why we are seeing what we're seeing.

-Dan Pullega (@4n6k)

* Special thanks to Tom Yarrish (@CdtDelta) for spawning this post.

Monday, February 17, 2014

Forensics Quickie: PDF Metadata Forensics (Sunday Funday Answer)

FORENSICS QUICKIES! These posts will consist of small tidbits of useful information that can be explained very succinctly.

David Cowen's Sunday Funday contests are great. In short, a question is posed about a subject, and readers get the opportunity to answer and explain how it is relevant in a forensic investigation. Much can be learned from these contests, as a great answer is almost always delivered and posted publicly. I highly recommend checking it out and submitting answers (it's a weekly thing, so the subjects vary widely).

This week's (2/16/14) subject was PDF Metadata. I took a stab at answering and wound up winning, so I figured it wouldn't hurt to post my answer here. The original answer, along with a preface by David Cowen, can be found here.

The Questions
The subject's prompt was as follows:

1. What metadata can be present within a PDF document?
2. What affects the types of metadata that will be present within a PDF document?

The Answer
The following is my answer to the prompt. Disclaimer: this was written in the wee-hours of one night, so if there are any typos or errors, please feel free to contact me.

----
Much can be gleaned from PDF metadata. Of course, there are the standard fields that will provide you with relatively common metadata...but depending on the program you use to create the PDF, there could be much, much more.

Let's start with the most common metadata. Most PDFs will have embedded metadata showing the PDF version, creation date, creation program, document ID, and last modified date. There are definitely more, but I have left them out as they wouldn't be very useful in an investigation (e.g. page count). The use for the aforementioned metadata is fairly obvious, but I will explain nonetheless.

The more obvious PDF metadata entries are:
  • Creation program: program used to create the PDF (was it through desktop software, was it scanned, etc.)
  • Creator/Author/Producer: Username or full name of the PDF's author OR further details on the program used to create the PDF (is it a previous employer?)
  • Title: the title of the PDF that usually provides an outdated name for the document; good for identifying previous employer documents or documents that have been converted from one format into a PDF (e.g. SecretBluePrint.eps or oldCompanyFinances.doc shows up in the 'title' metadata entry)
Those are the easy ones. But what about the more overlooked metadata? As I mentioned before, the program used to create or modify the PDF may have a huge impact on what information you are given. With that, let's look into it.

First, timestamps. We know that file metadata could potentially serve as a better indicator of when a given document was created. If the PDF has been transferred across various volumes and systems -- and we would like to find the origin of the document -- the creation date in the file metadata is going to be more reliable than the file system creation date (as the filesystem date/time will have been updated with the copies/moves).
A More Reliable Creation Date

The metadata 'creation' date will [usually] preserve the REAL date of the file's creation. That is, if the PDF has been transferred across various volumes and systems, the 'creation' date in the file's metadata is going to give us a better idea of when the document was initially created.

The 'modified' date can be used in a similar way. We might even be able to tell how many programs through which the PDF was modified/saved. Say we have a PDF created using Adobe InDesign. If we were to open this PDF, modify it, and then save it as a new file using 'Save As...' in a program like Adobe Acrobat, we would see that the 'creation' date is still unchanged, but the 'modified' date had been updated (file system creation dates will tell us differently). Pretty standard stuff. Even if the PDF is saved using 'Save As...' (essentially creating a new file altogether with an updated file system creation time) AND it is moved from one system to the next, we will still have a genuine 'creation' date. Not only that, but we will have a metadata 'modified' date AND a new file system creation time to work with. Correlation among file metadata and file system timestamps are beyond the scope of this answer, but you get the point; 'creation' and 'modified' metadata dates are powerful and can be used creatively.
Also, with many PDF timestamps, we will be able to see a timezone offset. For example, a creation timestamp could be 2013:02:22 11:21:34-06:00. We now have a potential indication that the program that produced this PDF was set in Mountain time.

I mentioned that we might be able to determine if a PDF was created and modified through more than one program. As a quick side note, and if we really wanted to dive into the PDF analysis, we could take a look at some of the other telling metadata. The example above suggested creating a PDF in InDesign, opening it up in Acrobat, modifying it, and then saving it as a new file. When this happens, some of the metadata in the new file (like the 'modified' time) is updated while all of the InDesign metadata stays intact. However, there is a significant difference this time around: the 'XMP Toolkit' metadata value is different. Adobe implements their XMP Toolkit in all of their applications and plugins. They even open sourced it, so other programs can use it (and many do). The point is, "the XMPCore component of this toolkit is what allows for the creation and modification of the metadata that follows the XMP Data Model" (more here and here). So we have two PDFs, but the metadata for each was manipulated by two different versions of Adobe's XMP Core.

InDesign used:
"Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27" and...

Acrobat used:
"Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03"

But why is this important? Well, we can now more accurately pinpoint the program used to create the PDF. Sure, we will likely already have a metadata entry that tells us the 'Creation Program,' but consider the above example; that tool (InDesign) may have been used to initially create the PDF, but it was NOT used to open, modify, and save a new version of it (Acrobat did that). Let's keep this in mind as we explain some other interesting metadata...

Remember: the amount of metadata that a program uses when creating files is limitless. XMP is built on XML, so any metadata tags can be defined. Let's take a real-world example of how powerful PDF metadata can be when created from certain programs. Download Trustwave's Global Security Report PDF from 2013. Run it in exiftool. What do you see? That's right, the "History" metadata fields will show you not only that the document was saved 497 times, but it will also show you the exact times that is was saved, the program used to save it each time, and the Document Instance ID for each save (less exciting).

While you have that open, take a look at the creation date (2013:02:22 11:21:34-06:00) and modify date (2013:05:09 10:47:39-07:00). The modify date is much later, but the last "History" save on the file was 2013:02:22 11:18:06-06:00. What's up with that? This is because the PDF was modified in a different program; one newer than InDesign CS5.5. How do I know this? Well, look at the XMP Core version. The XMP Core version used for InDesign CS5.5 is "Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03." I just so happen to have a PDF created with InDesign CS6 and that PDF uses "Adobe XMP Core 5.3-c011 66.145661, 2012/02/06-14:56:27." How can it be that CS5.5 is using a later XMP Core version than CS6?! Because another program was used to modify the CS5.5 PDF after the last save. On 2013:05:09 10:47:39-07:00 (the modify date), some program (let's just say it's Acrobat to satisfy my example from before) modified the PDF. The XMP Core version shown in the metadata is NOT from CS5.5.

Also from the 'History' metadata, we can tell that the creation date is actually "2012:12:29 11:20:49-06:00." and NOT "2013:02:22 11:21:34-06:00." My guess is that InDesign was keeping track of the saves, but when it came down to exporting the PDF, it tacked on the export date as the "Create Date" (as the last 'History' save of the file is 3 minutes before the alleged "Create Date").

If we really wanted to, we could use another metadata field (the PDF version) to further pinpoint the program used. If the PDF version is 1.7, we could look for programs on a suspect computer that save PDFs to version 1.7 by default. Believe it or not, many programs still save PDFs as version 1.4, 1.5, and 1.6.

After all of this, I think it's safe to say that PDF metadata can be pretty valuable. You just need to know what's available to you and how to interpret it.
----

(Thanks to David Cowen for posing the question and offering up the G-C Partners Multi-Boot USB 3.0 flash drive prize!)

-Dan Pullega (@4n6k)

Thursday, February 6, 2014

Forensics Quickie: Pinpointing Recent File Activity - RecentDocs

FORENSICS QUICKIES! These posts will consist of small tidbits of useful information that can be explained very succinctly.

Let's revisit the basics...

Scenario
A suspicious employee left your company on January 28, 2014. You'd like to know which files were most recently used (opened, saved) on the employee's system right before he/she left.

The Solution
Pull the user's NTUSER.DAT. Run RegRipper to easily output the the values within the Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs subkey.

To give some background, the RecentDocs subkey will contain a few things:
  • Subkeys named after every file extension used on the system (e.g. a subkey for .zip, .doc, .mp4, etc.). 
    • Each of these subkeys will contain its own MRUListEx value that keeps track of the order in which files were opened. (Sound familiar? We also saw use of the MRUListEx value upon analyzing shellbags artifacts). 
    • Each subkey will store up to 10 numbered values; each numbered value represents a recently opened file with the extension found in the subkey's name.

     
    The .gif subkey showing the 10 most recently opened .gif files for a specific user. The order is stored in MRUListEx.

  • A subkey for folders most recently opened.
    • Can store up to 30 numbered values (i.e. the 30 most recently opened folders).
  • A root MRUListEx value
    • Stores the 149 most recently opened documents and folders across all file extensions.

With that, take note that MRU times are powerful; here's why:

Since every extension has its own subkey, we will have quite a few registry key LastWrite times with which to work. But so what? When dealing with RecentDocs, the LastWrite time only applies to the most recently opened file within that subkey. While this is certainly the case, we mustn't forget that we also have an all-encompassing MRUListEx in the root of the RecentDocs subkey.

So what does this mean? By using the LastWrite times of each subkey and the root MRUListEx list, we can more accurately determine when certain files were last opened. While we won't be able to get an EXACT time for non-MRU (i.e. files that are not the first entry in the MRUListEx value), we may be able to determine a time range in which these files were opened. Consider the following example:



Our root MRUListEx shows:

RecentDocs
**All values printed in MRUList\MRUListEx order.
Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs
LastWrite Time Thu Feb  6 14:08:49 2014 (UTC)


  26 = smiley.gif
  99 = strange_bird.jpg
  42 = books_to_read.csv
  130 = secret_clients.csv
  55 = zip_passwords.rtf
  87 =
my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 = notes.txt

  ...

At this point, if we look at the first few entries of the root MRUListEx, we can really only tell that smiley.gif was last opened on Feb 6, 2014. So let's mark it:

  26 = smiley.gif ............................Feb  6 14:08:49 2014
  99 = strange_bird.jpg
  42 = books_to_read.csv
  130 = secret_clients.csv
  55 = zip_passwords.rtf
  87 =
my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 =
notes.txt
  ...

That secret_clients.csv looks pretty interesting. Let's look at the .csv subkey to see if we can find out when it was opened.

The .csv subkey's MRUListEx shows:

Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.csv
LastWrite Time Sat Jan 18 19:19:22 2014 (UTC)
MRUListEx = 6,2,1,7,3,5,4
  

  6 = books_to_read.csv  
  2 = secret_clients.csv
  1 =
my_diet.csv
  7 = contacts.csv
  3 = phillip.csv
  ...

Dang. Looks like the books_to_read.csv file is the most recently opened .csv, which means that the Jan 18 19:19:22 2014 LastWrite time of the .csv subkey is going to represent the last time that that file was opened -- not secret_clients.csv. I guess we can give up on this one...

...or...we could look at the surrounding files to glean some more information. First, let's mark the known LastWrite time in our root MRUListEx list.

  26 = smiley.gif ............................Feb  6 14:08:49 2014
  99 = strange_bird.jpg
  42 = books_to_read.csv...............Jan 18 19:19:22 2014
  130 = secret_clients.csv
  55 = zip_passwords.rtf
  87 = my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 =
notes.txt
  ...

Looking at our list, we can see that there are two open times that we know for sure. We can also see that there is another file that was opened between these times. It looks like strange_bird.jpg was opened after smiley.gif, but before books_to_read.csv. Since this list is an all-encompassing list, it would be safe to say that between January 18 and Feb 6, strange_bird.jpg was opened. But let's go ahead and confirm that.

The .jpg subkey's MRUListEx shows:

Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.jpg
LastWrite Time Sat Jan 18 21:54:57 2014 (UTC)
MRUListEx = 4,2,3,1
  

  4 = strange_bird.jpg 
  2 = stone_tanooki.jpg
  3 = camel.jpg

  1 = fighting_frogs.jpg

It looks like strange_bird.jpg is the most recently opened .jpg on the system. That means that the Jan 18 21:54:57 2014 LastWrite time of the .jpg subkey represents the the time at which strange_bird.jpg was opened. Again, let's mark it in our root MRUListEx list:

  26 = smiley.gif ............................Feb  6 14:08:49 2014
  99 = strange_bird.jpg...................Jan 18 21:54:57 2014
  42 = books_to_read.csv...............Jan 18 19:19:22 2014
  130 = secret_clients.csv
  55 = zip_passwords.rtf
  87 =
my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 =
notes.txt
  ...

At this point, we still don't know when secret_clients.csv was last opened. Upon finding its LNK file, we note that it had been first opened in late 2013 (LNK creation time). If this machine was running XP, we would be able to grab the access time of this LNK file to see when it *might* have been last opened. Alas, we are using Windows 7 (disclaimer: there are tons of other things you should be looking at anyway; this is merely one example of why we would want to look at RecentDocs). Let's keep moving.

Taking a second look at our root MRUListEx list, we notice that the next item after secret_clients.csv is zip_password.rtf. That also looks interesting, so let's see when that was opened.

The .rtf subkey's MRUListEx shows:

Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.rtf
LastWrite Time Sat Jan 17 14:15:31 2014 (UTC)
MRUListEx = 2,1
  

  2 = zip_passwords.rtf 
  1 = fiction_novel.rtf

It looks to be the first one, so we can use the LastWrite time to mark it in our list.

  26 = smiley.gif ............................Feb  6 14:08:49 2014
  99 = strange_bird.jpg...................Jan 18 21:54:57 2014
  42 = books_to_read.csv...............Jan 18 19:19:22 2014
  130 = secret_clients.csv
  55 = zip_passwords.rtf.................
Jan 17 14:15:31 2014
  87 = my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 =
notes.txt
  ...

With that, we have found a pretty tight time frame as to when secret_clients.csv was last opened. We don't have the exact date and time, but we can now say that is was last opened somewhere between Jan 17 and Jan 18.

It looks as though there are some more .csv files that were recently opened, and by the looks of it, that .txt file might be able to help us hone in on a time frame.

The .txt subkey's MRUListEx shows:

Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs\.txt
LastWrite Time Sat Jan 10 18:23:08 2014 (UTC)
MRUListEx = 4,5,2,1,3
  

  4 = notes.txt 
  5 = groceries.txt
  2 = how_to_make_toast.txt
  1 = my_novel.txt
  3 = address.txt
  ...

Just as before, let's mark the LastWrite time in our root MRUListEx list.

  26 = smiley.gif ............................Feb  6 14:08:49 2014
  99 = strange_bird.jpg...................Jan 18 21:54:57 2014
  42 = books_to_read.csv...............Jan 18 19:19:22 2014
  130 = secret_clients.csv
  55 = zip_passwords.rtf.................
Jan 17 14:15:31 2014
  87 = my_diet.csv
  3 = contacts.csv
  74 = phillip.csv
  72 =
notes.txt...............................Jan 10 18:23:08 2014
  ...

Again, we don't have an exact date and time as to when the my_diet.csv, contacts.csv, and phillip.csv files were last opened. But, based on the LastWrite time of the .txt subkey, we do know the time frame in which these files were opened.

Now imagine that a USB device was also plugged in at some point within this time frame. It is possible that the suspicious employee may have done a "Save As..." on contacts.csv and saved it to the external device. It is also possible that the employee opened the file and copy/pasted the information into an email. Of course, the possibilities are endless, but you get the point.

And it goes without saying that other artifacts, such as LNK files, jump lists, ComDlg32, OfficeDocs, and more should also be used to complement RecentDocs analysis. In particular, ComDlg32 would be of interest in this scenario, as it will show you files recently opened/saved. It offers more information (e.g. the executable used to open the file, the file's path, etc.) and stores saves/opens by extension, as well. As such, we can use this same technique to pinpoint file open/save times (though, it is a bit limited, as the * extension subkey will only show up to 20 entries).

This post quickly became longer than expected, but it's still a quickie. I'll end with this:

This is nothing new. All of this data is available to you in the Windows registry. This is a fairly basic technique, but it is also one that shouldn't be overlooked. And as always, use more than one artifact to make your case.

-Dan Pullega (@4n6k)

Wednesday, December 4, 2013

Shellbags Forensics: Addressing a Misconception (interpretation, step-by-step testing, new findings, and more)


Everything I've learned on the subject of digital forensics has been a direct result of both experience and reading forensics books, blogs, and list-serv responses written by people like Ken Pryor, Harlan Carvey, Eoghan Casey, Chad Gough, Rob Lee, Lee Whitfield, Brad Garnett, David Kovar, Andrew Case, Dave Hull, Dan O'Day, Shafik Punja, Frank McClain, Cory Altheide, Corey Harrell, Joe Garcia, Hal Pomeranz, *deep breath* Troy Larson, Chad Tilbury, Andrew Hoog, Andrew Hay, cci, pr0neer, Eric Huber, Luby Novitovic, Michael Hale Ligh, Alex Bond, Willi Ballenthin, Jimmy Weg, Corey Harrell, Dan Farmer, Larry E. Daniel, Jamie Levy, Tom Yarrish, Andreas Schuster, Loc Nguyen, David Cowen, Didier Stevens, Joachim Metz, Ovie Carroll, David Nides, Brian Carrier, Joseph Shaw, Jesse Kornblum, Adamb, Alissa Torres, Sarah Edwards, Patrick Olsen, Eric Zimmerman, Jake Williams, Brian Baskin, and many more (I know I've forgotten some; I apologize to those I've missed). So I just wanted to start off with a quick 'thank you,' as you've all driven me to this point. Your work is very much appreciated.
----------------------------------
[UPDATE #10 07/23/2014]: This post has been cited as a source in the "Shellbags in Memory" section of The Art of Memory Forensics (p.299).
[UPDATE #09 06/24/2014]: This post has been selected as the 2014 Forensic 4cast "Digital Forensic Article of the Year." As mentioned at the top of this post, my boundless thanks go out to the people who share research; without them, none of this would have been possible.
[UPDATE #08 06/24/2014]: Material from this article was discussed in a presentation I gave at the 2014 SANS DFIR Summit. The slides for that talk can be found here. Nicole Ibrahim also noted the behavior of shellbags in her research on MTP devices; that can be found in the slides for her talk at the 2014 SANS DFIR Summit.
[UPDATE #07 06/24/2014]: David Cowen has written a nice blog post about further identifying potentially accessed devices based on shellbags artifacts. It takes into mind the other information included in shellbags artifacts: MFT file records and sequence numbers.
[UPDATE #06 04/08/2014]: This blog post has been nominated for a Forensic 4cast award. More details can be found here and here. Thank you to everyone who has been a part of this.
[UPDATE #05 01/21/2014]: I gave a presentation at a Chicago-based forensics meetup (Chi4n6) that focused upon the contents of this blog post. The slides can be downloaded here.
[UPDATE #04 01/14/2014]: Great news! TZWorks sbag v0.35 has been released with fixes for (a) the MRU Time issue (there is an 'mru' indicator column now), (b) identifying type 0x52 shell items (Acronis backups now parse correctly), and (c) identifying shellbags entries for MTP devices (they are now seen in output and parsed correctly). I have tested these fixes and can confirm their validity. With that said, if you are using sbag for analysis, do not use any version prior to v0.35.
[UPDATE #03 12/28/2013]: Nicole Ibrahim wrote a nice shellbags post focused upon MTP devices. Note that "not all tools account for MTP devices in the reporting output." I ran a quick test; TZWorks sbag does not show these entries in output. Fixed. See UPDATE #04.
[UPDATE #02 12/23/2013]: Harlan posted a nice summary of this post on his blog. It explains the significance of the items discussed below and why more research is needed in the forensics space. Also, in the comments section of his post, I have written an addendum to this blog post.
[UPDATE #01 12/16/2013]: I have been working with Harlan Carvey to improve the capabilities of RegRipper's shellbags.pl. Harlan has been super responsive and has built in support for the 0x52 shell item type. Test validation is now easier, as subkey paths are included in output by default. He has also done some more research on the MFT reference number issue. We discussed whether or not this data is valuable or if it would just be another source of confusion. He has expounded on this topic. Feel free to weigh in on the discussion. That and more can be seen here. Jonathan Tomczak of TZWorks sbag has also confirmed that efforts are being made to address the sbag issues noted in this post.
----------------------------------

Digital forensic investigators can be dangerous; one poor assumption could lead to several false accusations. Because of this, proper interpretation of forensic artifacts is paramount in any investigation.

At face value, shellbags artifacts seem pretty simple. They serve as great indicators of which folders were accessed on a system, and they even preserve the MAC times of said folders*. In addition to this, the tools that handle shellbags aren't too cryptic at all -- pretty straightforward stuff. However, if one were to delve deeper into how shellbags actually function, one may be persuaded to believe the contrary...

I will be focusing less on the structures of these artifacts and more on the practical interpretation of the existence of these artifacts. But, as always, you can find a comprehensive list of references at the bottom of this page for more details on the specifics. Be sure to check out Chad Tilbury's article, Yuandong Zhu's DFRWS 2009 paper, Willi Ballenthin's programmer perspective post, Jamie Levy's Volatility post, Harlan Carvey's two posts, and Joachim Metz's shell item format document.

With that, let's recap what we already know.



Shellbags Overview (or What We Already Know)
  • Purpose is to keep track of Windows shell (Explorer) window sizes, views, positions, etc.
  • Located in user-centric registry hives.
    • Windows XP:
      • NTUSER.DAT\Software\Microsoft\Windows\Shell
        • stores references to network folders
      • NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam
        • stores references to local folders
      • NTUSER.DAT\Software\Microsoft\Windows\StreamMRU
        • stores references to removable device folders
    • Windows 7: 
      • NTUSER.DAT\Software\Microsoft\Windows\Shell
      • UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell
        • Majority (if not all) found in this hive (local, network, removable).
  • Each bullet point entry above contains two relevant subkeys:
    • "BagMRU"
      • Shows us the actual directory structures of which folders were accessed in the format of numbered subkey/value hierarchies.
        • e.g. the Windows 7 registry path UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\0\0\2\0\1 translates to Desktop\MyComputer\K:\Documents\Personal\PDFs
        •  
        • Each numbered subkey contains a NodeSlot value. This [decimal] value points to the folder's corresponding view settings (view mode, icon size, etc.) found in the Bags subkey. So if the NodeSlot value in the "Personal" subkey (BagMRU\0\0\2\0) is 0x0000000B, you would find its folder view settings within the Bags\11 subkey.
        • Each numbered subkey contains a MRUListEx value. This value tells you which child folder (in the current subkey) was most recently accessed. THIS IS EXTREMELY IMPORTANT. (more on this later in the post)
        • The BagMRU subkey itself contains values just as its numbered subkeys do. These values are the folders that are found on the user's desktop. These include the virtual folders pointing to locations such as "My Computer," "Network," and the user's personal folder (e.g. C:\Users\SomeUser).
    • "Bags"
      • Contains numbered subkeys for each hierarchical child subkey under BagMRU.
      • Laid out differently than BagMRU in that it is not hierarchical; numbered subkeys can reach 600+.
  • Keeps track of folders opened/closed/repositioned/resized -- per user.
    • able to see full paths of these folders
  • Preserves MAC times of folders.
  • Exploring zip files will also create shellbags artifacts.
    • Check the "New Findings" section for testing on this bullet point. Shellbags entries for zip file subfolders contain an additional timestamp in the shell item's binary data. This value represents the modified time of the folder, not the time that the zip subfolder was last explored.



Forensic Value (or Why It's Important)

We now know the basics of what Shellbags artifacts are...so how can we use them to our advantage? Through them, we can determine the following:
  • Which folders were accessed (via Explorer) on the local machine, the network, and/or removable devices.
  • Evidence of previously existing folders after deletion/overwrite.
    • e.g. if a folder is deleted, but it was accessed via Explorer before being deleted, the shellbag artifact (and thus, the full path + initial MAC times) for that folder will remain.
  • Historical MAC times of folders corresponding to the time that the folders were first accessed via Explorer.
    • Useful for determining whether or not folders were copied/moved to a new volume. 
  • Which user(s) accessed certain folders.
  • The means by which a folder was navigated (Did the user open the folder via Start > My Computer, via Start > %username%, or via Start > My Computer and then clicking a sidebar link to the folder? They all show up differently.)  
  • When certain folders were accessed.*****
Use this information if you are someone who wants to find...
  •  an attacker's/intruder's Explorer navigation (potentially find where malicious tools are/were stored)
    • applies if the attacker gained access via RDP or other VNC-based vectors.
  • a user's use of the system in question (absence of Shellbags entries may suggest system cleaning)
  •  a user's use of removable devices; what is/was stored on said devices*****
***** This is where the misconception comes into play. The "when" and "where" of the accessed folders are grossly oversimplified if you don't understand how this artifact works. What's even more interesting is that not every tool will give you completely accurate results. Ideally, this should never be the case, but alas, it is. You'll see what I mean in the "Testing" section of this post. If a forensic investigator were to take the output of almost any Shellbags parser at face value, he/she would most likely misinterpret its meaning. This is because there is so much more to this artifact than it seems.



The Misconception / Pre-Testing (or What To Expect And Why)

Below is some sample output from one of the more popular Shellbags parsers: TZWorks sbag.

Fig. 1 - There are two additional columns not pictured here that correspond to the file size and the type of shell item [dir, file, etc.] for each entry. While these columns could be valuable in other instances, they don't add much to this post, so I have omitted them.

Our output is pretty simple; for each entry, we've got 1) date/time from the registry, 2) MAC date/time, 3) corresponding subkey number under the Bag subkey, and 4) the full path. But what do these values really mean? It's great that this tool can pull this information. After all, some of the evidence we need sits comfortably under that "full path" column -- clear as day.

Without knowing much about Shellbags except for the fact that this tool exports the values, investigators could assume (and have assumed) that the regdate is the last time the folder was opened. While this statement holds true on its own, it is NOT entirely true in the overall scheme of things. Here's why:

The "regdate" refers to the LastWrite time for each registry subkey under (and including) the BagMRU subkey. It is essential to know how and when these times are updated. This can get really complicated really quickly, so if you don't understand this right away, that's fine; it will be explained further in the "Testing" section of this post. To make this easier to understand, let's use the visual from the "Shellbags Overview" as an example (replicated below).

Fig. 2 - Example BagMRU subkey layout. Each subkey represents a folder that was explored via Explorer.

Remember: every subkey under (and including) BagMRU contains numbered values that correspond to said subkey's nested subkeys. Every one of these subkeys contains numbered values except for the last child in each branch. Based on the above example, BagMRU will contain only one numbered value: 0. This is because the only [virtual/special/system] folder that has been explored is MyComputer. Here's how the BagMRU subkey would look in a registry viewer (e.g. regedit):

Fig. 3 - Values found in BagMRU subkey. Do not worry about the NodeSlots and MRUListEx values just yet.

We see one numbered subkey: 0. This value corresponds to the BagMRU subkey's only direct child subkey (i.e. BagMRU\0 -- i.e. "Desktop\MyComputer"). So the fact that there is a value named "0" within the BagMRU subkey means that there is going to be only one direct child subkey (labeled "0") under BagMRU.

Continuing on down the hierarchy, we can see that BagMRU\0 (i.e. "Desktop\MyComputer") only has one direct child subkey, as well. Its contents will look similar to Fig. 3 in that there will only be one numbered value: 0. This value corresponds to the only other subkey found under Desktop\MyComputer (i.e. BagMRU\0): the next nested 0 subkey that stands for drive letter "K:" (i.e. BagMRU\0\0). If we were to view the binary data of the BagMRU\0@0 value (i.e. the value named "0" within the "Desktop\MyComputer" subkey), we would be able to see plaintext ANSI equivalent "K:" somewhere in the binary data:

Fig. 4 - Regedit.exe: Binary data of the value named "0" within the BagMRU\0 subkey (i.e. Desktop\MyComputer)

Common Binary Data For Special Folders

Note that you will NOT see plaintext ANSI equivalent translations in the binary data for Windows special folders (MyComputer, UserLibraries, etc.). Instead, you will see what looks like random data. This data is, in fact, not random, but quite the opposite. Shellbags entries for special folders will have bits of recognizable binary data in their values. For example, if you wanted to quickly identify the MyComputer subkey in a registry viewer (e.g. regedit), you would look for the following binary data within one of the values under the BagMRU subkey:

Fig. 5 - Common binary data of the "My Computer" value under the BagMRU subkey.

This type of system folder for this shellbags entry can be identified by a single byte within the binary data, which tools use to show us the translated, non-gibberish full paths of folders. In this case, that byte is 0x50 for "My Computer." We will see this a bit later in the post. Again, I am not going to get into the actual data structures, as this has already been covered in great detail by Joachim Metz. You can also find a nice list of System Folder Types in the "parseSystemFolderEntry" subroutine in Harlan Carvey's shellbags.pl RegRipper plugin (note that 0x50 is the identifier for "My Computer" in this example).

On that note, system folders are just one kind of shell item found in shellbags. For example, in Fig. 4, the 0x2F byte indicates that we're looking at a volume entry shell item. In Fig. 5, the 0x1F byte indicates a system folder entry shell item. Again, check the links by Joachim and Harlan for more on that. [UPDATE 12/6/2013]: As Joachim Metz has pointed out in the comments, there is much more to shell item folder identifiers (see here: https://code.google.com/p/libfwsi/wiki/ShellFolderIdentifiers).
_______
Now that we know that there will be a numbered subkey for every numbered value within a given parent subkey, can you guess how many numbered subkeys the BagMRU\0\0 (i.e. "K:") subkey will contain?

Fig. 6 - Values found in BagMRU\0\0 (i.e. Desktop\MyComputer\K:) subkey.

Per Fig. 6, there are three numbered values found within the "K:" (i.e. BagMRU\0\0) subkey and therefore, there will be three numbered child subkeys under it. Each of these values (and thus, each of the subkeys) represents a folder found in the root of the "K:" drive that has been navigated/explored via Explorer. By looking at the binary data of each of the values, we will be able to tell which subkey will represent each of the three folders (Pix, Songs, and Documents).

Let's say that we follow this all the way down to BagMRU\0\0\2\0\1 (i.e. "Desktop\MyComputer\K:\Documents\Personal\PDFs"). If you see the following in a given subkey, it means that the subkey is the youngest child folder in the branch. That is, there are no more folders that were explored under "K:\Documents\Personal\PDFs."

Fig. 7 - Values found in Desktop\MyComputer\K:\Documents\Personal\PDFs (i.e. BagMRU\0\0\2\0\1) subkey.

From this, we can note that not every subkey will have numbered values (specifically, the youngest child subkeys), but every subkey will have a NodeSlot (NodeSlots in the root BagMRU key) value and an MRUListEx value.

I will not be detailing the NodeSlot(s) value, but for the sake of comprehension, it is a value that points to the appropriate item's Bags subkey. That subkey contains the actual view settings for Explorer windows (window size, position, etc). The NodeSlots value (that is, the one with the "s") is only found in the root BagMRU subkey and is updated whenever a folder that has not previously been explored is explored (thus creating a new shellbags entry). This is why the BagMRU subkey sometimes has a registry LastWrite time of the latest folder exploration (more on this later in the post).

The more important (and arguably the most important) value found within each subkey is the MRUListEx value. The registry-related time ("regtime", "MRU time", etc.) that you see in shellbags tool output is based off of the modification of this value.

The idea behind the MRUListEx value is similar to other MRU-based registry items, such as RecentDocs. In Fig. 6, notice that MRUListEx exists among the other numbered values. Its purpose is to keep track of which numbered values were most recently used (i.e. which folder was most recently accessed in Explorer). Each entry in MRUListEx is 4 bytes long and is clearly marked. Fig. 6 shows us that the binary data of MRUListEx is "02 00 00 00 01 00 00 00 00 00 00 00." The first entry, value "2" (i.e. the "Documents" folder), was most recently opened. Before "2" was opened, the "1" value (i.e. the "Songs" folder) was opened and before that, the "0" value was opened (i.e. the "Pix" folder).

The LastWrite time of the subkey that stores all of these values (in our Fig. 6 example, this would be the BagMRU\0\0 [i.e. Desktop\MyComputer\K:] subkey) represents the last time that the first MRUListEx entry (remember, this is value "2" -- the "Documents" folder) was accessed via Explorer. We now know the time that the "K:\Documents" folder was last explored. We cannot, however, determine with certainty the time that values "1" and "2" (i.e. the "Pix" and "Songs" folders) were last explored, as they are not the first entry in MRUListEx.*
Determining First Explored Times of "Youngest Child" Subkeys

*Technically, we could determine the first explored times of "Pix" and "Songs" if they were the youngest child subkeys in the branch, but they are not. Per Fig. 2, we would be able to tell the times that the "Plans" and "PDFs" folders were first explored because no folders inside of them were explored. The subkeys representing both of these folders are therefore never updated (since they contain no numbered values and their MRUListEx is blank (i.e. FF FF FF FF); the LastWrite times stay the same as when the subkeys were first created -- that is, until the MRUListEx value is put into use and there is at least one numbered value present within the subkey.

As of the date of this post, no shellbags tool that I've used reports this. Therefore, these special cases must be reviewed manually.

In any case, the MRUListEx value is crucial in understanding how shellbags function. And, as we will see through testing, many tools/parsers unfortunately do not factor it into their output. Although there is a ton of information being offered by shellbags up front, much more can be discovered by looking at this artifact from all angles. With that, let's test.



Testing (or How It Really Looks In Practice)

Tests were run to determine the forensic implications of shellbags artifacts as well as to see how they function on an event-by-event basis. A folder structure containing multiple layers of subfolders was created and then navigated. After each step of navigation, shellbags artifact changes were recorded.

There were two phases of testing. Phase A tested the folder structure from the user's Desktop. Phase B tested the folder structure from a removable USB device.

For both phases, folders were structured as follows:

_______
Additional folders created/deleted throughout testing are noted in their respective event section.

The latest versions of two tools were used to pull shellbags data: TZWorks sbag (x64 v.0.33.win) and RegRipper's shellbags.pl plugin (v.20130102). Each tool was run on the same data sets after each event occurred. For each event listed below, the output for these tools will be listed, followed by a short description of what we can gather from it. When reading each tool's output, reference the following legend to determine the meaning of certain colors/highlights:

Red borders also indicate existing entry changes

Also, feel free to follow along with each step by downloading the UsrClass.dat files used in this testing. You can download individual hives by clicking the download link at the end of each event heading or download them all in .zip format using the links found in the "Validate My Testing" section toward the end of this post. All tests were run on a Windows 7 machine.

Note that the write-ups for Phase A and B are very lengthy. My goal was to make this as easy to read as possible by not requiring the reader to manually enlarge each image. I have included output for every action taken during testing -- this includes events that do not cause changes to shellbags artifacts. I did this to be thorough and to protect the integrity of the data at each step.



Phase A - Event 00: Baseline report; no actions taken on clean machine [download hive]

The user's UsrClass.dat hive was exported and both tools were run against it. No events related to shellbags have occurred at this point. Two terminal windows have been opened by clicking the Start menu, typing cmd, right-clicking "cmd.exe" and selecting "Run as administrator."

RegRipper's shellbags.pl Output

Note that a "Zip_Subfolder" column also exists in this output. Since we are not dealing with zip files in this post, I have omitted this column.

TZWorks sbag Output


As we can see, nothing has happened at this point. The registry was manually reviewed to ensure that no [non-default] shellbags artifacts have been created. We know that we are working with a clean slate.



Phase A - Event 01: Create CONFIDENTIAL folder structure on the desktop [download hive]

The folder structure for Phase A is created on the desktop. Each folder is created individually via the command line (using the mkdir command). Creating them separately (instead of all at once) will demonstrate how shellbags artifacts preserve MAC times. We will be able to see the different creation times of the folders in later events.

The time for each folder creation event was logged:

All folders were created on 11/3/2013

We now know that we should see these times in the "Created" or "ctime" columns of tool output when entries start populating.

RegRipper's shellbags.pl Output



TZWorks sbag Output


At this point, no shellbags artifacts exist.



Phase A - Event 02: Navigate to "CONFIDENTIAL\X\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From the desktop, each folder within the CONFIDENTIAL folder is explored until "CONFIDENTIAL\X\1\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output



TZWorks sbag Output


RegRipper shows that four entries have been created -- one for each folder explored. Golden text suggests a new entry. Note that the "Created" times are one second later than what is shown in the aforementioned folder creation times list. Harlan Carvey explains why this is the case in the last paragraph of his post. Essentially, time format conversion is taking place, causing these times to be one second off. Be aware of this in all future events.

TZWorks shows similar results. Therefore, we are seeing similar results from both tools, which is great. TZWorks includes the "Desktop" folder (i.e. BagMRU subkey) and its MRU time. Desktop is also a special/system folder, so it is not going to have MAC times associated with it.

A More Granular Test: Testing Each Folder Exploration

After performing the above test in Event #02, I wanted to know how each folder exploration would look instead of navigating several folders and then pulling results. A different test was done in which results were pulled after each folder in "CONFIDENTIAL\X\1\iii" was explored.

Note that these times are different from the above, as I ran this test days after completing everything. So, this is a completely separate test, done at a completely separate time. This will help in showing you what is going on behind the scenes at a more granular level.

The test was simple: navigate to each folder within the "CONFIDENTIAL\X\1\iii" path with a 1 minute interval. That is, at 2:18, folder "CONFIDENTIAL" was explored; at 2:19, folder "CONFIDENTIAL\X" was explored; at 2:20, folder "CONFIDENTIAL\X\1" was explored; and at 2:21, folder "CONFIDENTIAL\X\1\iii" was explored. Here are the results:



Event 2:18 - Explore the "CONFIDENTIAL" folder [download hive]

RegRipper's shellbags.pl Output



TZWorks sbag Output



New shellbags entries are created as a result of the "CONFIDENTIAL" folder exploration.



Event 2:19 - Explore the "CONFIDENTIAL\X" folder [download hive]

RegRipper's shellbags.pl Output


TZWorks sbag Output






A new shellbags entry is created as a result of the "X" folder exploration. The MRU times for the "CONFIDENTIAL" folder (and the Desktop in TZWorks) are updated.



Event 2:20 - Explore the "CONFIDENTIAL\X\1" folder [download hive]

RegRipper's shellbags.pl Output


TZWorks sbag Output







A new shellbags entry is created as a result of the "1" folder exploration. The MRU times for the CONFIDENTIAL folder (and the Desktop in TZWorks) are updated.



Event 2:21 - Explore the "CONFIDENTIAL\X\1\iii" folder [download hive]

RegRipper's shellbags.pl Output


TZWorks sbag Output







A new shellbags entry is created as a result of the "iii" folder exploration. The MRU times for the CONFIDENTIAL folder (and the Desktop in TZWorks) are updated.



Special Case: Potentially "Inaccurate" Output for Direct Subkeys of BagMRU

One thing must be noted after reviewing each of the above events: the "CONFIDENTIAL" folder's MRU time is updated every event. But why? Well, this is a special case. To explain what is going on here, let's take a look at a segment of shellbags.pl's source code:

if ($mru != 4294967295 && ($v == $mru)) {
             $item{mrutime} = $key->get_timestamp();
             $item{mrutime_str} = $key->get_timestamp_as_string();
             $item{mrutime_str} =~ s/T/ /;
             $item{mrutime_str} =~ s/Z/ /;
         }


This segment of the code determines whether or not to pull the MRU time for a given subkey. It essentially checks to see if a given numbered value is also set as the first entry in the MRUListEx value. If it is, AND MRUListEx is not blank (4294967295 translates to hex "FF FF FF FF"), it pulls the subkey's LastWrite time and outputs it as the "MRU time" for that shellbags resource entry. In the case of the "Desktop\CONFIDENTIAL" folder, it works like this:
  1. Reads the "0" value within BagMRU (the 0 value represents the "CONFIDENTIAL" folder)
  2. Sees that the MRUListEx matches "00 00 00 00" (i.e. the "0" value) and does not equal "FF FF FF FF"
  3. Pulls the LastWrite time of the subkey in which the "0" value is stored, which in the case of the CONFIDENTIAL folder is the BagMRU subkey LastWrite time.
Herein lies the issue.  The BagsMRU subkey has something none of its children subkeys have: a NodeSlots value. That's Nodeslot with an "s." I touched upon this earlier in the post by explaining that every time a new folder is explored (that is, a folder that has not been previously explored via Explorer), the NodeSlots value is updated. What happens here is that a byte of data (0x02) is appended to the Nodeslots value for each of these new folders. To confirm this, compare the total amount of numbered subkeys in the Bags subkey with the total number of "0x02" bytes within the Nodeslots value. They will be the same. So if 664 folders have been explored on a machine, there will be 664 numbered subkeys in your Bags subkey and there will be 664 "0x02" bytes in the NodeSlots value.

Fig. 8 - Contents of the BagMRU subkey after one folder has been explored

Fig. 9 - Contents of the BagMRU subkey after two folders have been explored

Since, in our example of the "Desktop\CONFIDENTIAL" folder, we are exploring a new folder for each event, the NodeSlots value is going to be updated for each event. This means that the LastWrite time of the BagMRU subkey is also going to be updated. If a folder that already has a shellbags entry is explored, NodeSlots is not updated and therefore, the BagMRU subkey LastWrite time is not updated.

The point is, if a folder that hasn't been explored before is explored, the direct subkeys of BagMRU are going to show updated MRU times in tool output. If a folder that already has a shellbags entry is explored, the direct subkeys of BagMRU will NOT show updated MRU times. In a sense, tools will therefore report "false" MRU times (for BagMRU's direct child subkeys) when a new folder is explored. Because, in reality, the CONFIDENTIAL folder wasn't explored for every event, but the tool output (as well as the BagMRU key itself) seems to tell us differently.

This is not a flaw in the tools, though; there simply isn't an easy way (that I can think of) to determine whether the most recently explored folder was a newly explored folder unless 1) you are doing step by step testing or 2) you correlate the BagMRU subkey's LastWrite time to the LastWrite time of the highest numbered subkey in the Bags subkey to see if they match. If they do, a new folder was explored and you can confirm the false times. But even then, you will only be able to confirm this based on the most recently explored new folder. That is, if two new folders are explored in succession, you will know that the direct subkeys of BagMRU are showing false times, but you won't know that they were showing false times before the second new folder was explored (without going way above and beyond typical analysis).

Simply put, the last time we explored the CONFIDENTIAL folder was at 2:18. But for every event after that, we see its MRU time change. The NodeSlots value is to blame for this. As complex as it seems, this is definitely something to keep in mind during analysis so that you avoid reporting inaccurate MRU times the best that you can.


Phase A - Event 03: Close the "CONFIDENTIAL\X\1\iii" folder [download hive]

Simply close the window displaying the "CONFIDENTIAL\X\1\iii" folder. There are changes made to subkeys within the Bags subkey, but nothing that affects what we would see in tool output. To be thorough, I will replicate the tool output even when there are no changes henceforth.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 04: Navigate to "CONFIDENTIAL\X\2\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From the desktop, each folder within the CONFIDENTIAL folder is explored until "CONFIDENTIAL\X\2\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Here is where we start to see a difference in how these tools work. As expected, two new entries are created, reflecting the exploration of two previously unexplored folders. And, per the granular test, we also know why the CONFIDENTIAL folder MRU time is being updated in both tools. But note the changes in MRU times. In shellbags.pl, the MRU time for the CONFIDENTIAL\X\1 folder is now blank. In sbag, that same folder now has a populated, and updated MRU time. Why is this?

This is what I really like about shellbags.pl. It doesn't populate the MRU time field unless it is, in fact, the most recently explored folder in a given subkey. Remember when we looked at that segment of shellbags.pl code in the granular test? We determined that shellbags.pl does a check to see which numbered value in a given subkey is also set as the first entry in the MRUListEx value for that subkey (in this case, the subkey that represents "Desktop\CONFIDENTIAL\X"). It will only report an MRU time for the first entry in MRUListEx. This is absolutely crucial. Let's look at the sbag output to see why.

The sbag output shows us that both "CONFIDENTIAL\X\1" and "CONFIDENTIAL\X\2" have the same MRU time. Remember what action has just been taken: we navigated to "CONFIDENTIAL\X\2\iii." Even though we haven't touched "CONFIDENTIAL\X\1," the MRU time for it is still updated. This is because TZWorks sbag does not check to see whether or not the value for "CONFIDENTIAL\X\1" within the subkey representing "Desktop\CONFIDENTIAL\X" is the first entry in its respective MRUListEx value. 

This raises a very big problem when reviewing shellbags artifacts. As I mentioned earlier, many investigators unfamiliar with the innards of shellbags will assume that the MRU time (i.e. reg-UTC time) represents the most recent time the folder was explored. But this is only true for the first entry in a subkey's MRUListEx. With the way sbag represents the data, there is no telling which entry is reporting the correct time. Now imagine this on a larger scale; you have hundreds of folders located in the "CONFIDENTIAL\X" folder. Every one of those folders is going to have the same MRU time because a check isn't made to see if that folder is in fact the last folder to have been explored.

We will see this in a larger capacity in later events. It will make more sense once more shellbags entries are populated in the output.

When I ran these tests, I used sbag v0.33. Since then, v0.34 has been released, but the problem remains. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue.



Phase A - Event 05: Click the "back" button in Explorer to go back to "CONFIDENTIAL\X\2" [download hive]

With the "CONFIDENTIAL\X\2\iii" folder opened, the "back" button is clicked within Explorer. This takes us back to "CONFIDENTIAL\X\2."

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 06: Close the "CONFIDENTIAL\X\2" folder [download hive]

Close the window displaying the "CONFIDENTIAL\X\2" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 07: Navigate to "CONFIDENTIAL\Y\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From the desktop, each folder within the CONFIDENTIAL folder is explored until "CONFIDENTIAL\Y\1\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Three additional entries are created to account for the previously unexplored folders. Again, we see shellbags.pl only report the the MRU time for "Desktop\CONFIDENTIAL\Y," as it (and not "Desktop\CONFIDENTIAL\X") is the most recently explored folder within the "Desktop\CONFIDENTIAL" folder.



Phase A - Event 08: Close the "CONFIDENTIAL\Y\1\iii" folder [download hive]

Close the window displaying the "CONFIDENTIAL\Y\1\iii" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 09: Delete the "CONFIDENTIAL\X" folder via cmd.exe [download hive]

The "Desktop\CONFIDENTIAL\X" folder branch is deleted via cmd.exe using the command rd /s /q .\CONFIDENTIAL\X. The only remaining folder branches that exist in the CONFIDENTIAL folder are "Y" and "Z."

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 10: Navigate to "CONFIDENTIAL\Z\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From the desktop, each folder within the CONFIDENTIAL folder is explored until "CONFIDENTIAL\Z\2\i" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


The idea behind deleting the "X" folder branch was to see what would happen to its shellbags artifacts after it had been deleted. We see that three new entries are created as a result of traversing "CONFIDENTIAL\Z\2\i." RegRipper's shellbags.pl notices that the most recently explored folder within "Desktop\CONFIDENTIAL" is now "Z," so it doesn't report an MRU time for "Y" anymore. This is great. Now there is less chance that we get confused.

TZWorks sbag, however, not only updates the "Y" MRU time, it also updates the MRU time of "Desktop\CONFIDENTIAL\X." Remember: we just deleted that folder; it's not even on the system anymore. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue.

Clearly, this could get an investigator in trouble. We will see how in Phase B's events 16 and 18.

Special Case: Re-Exploring a Folder that has an Existing Shellbags Entry: Will It Update?

Almost all of the testing performed in the main threads of Phase A and B is based on previously unexplored folders on the system. For the most part, the way in which MRU times are updated are similar regardless of whether a shellbags entry for a given folder already exists. However, there is a special case in which the MRU time of a previously explored folder (i.e. a folder with an existing shellbags entry) is not updated.

If you explore a folder that has been previously explored (and thus has an entry in shellbags) AND there is only one numbered value within its subkey (i.e. if a previously explored folder has only one previously explored direct subfolder in it), there is no reason for the LastWrite time of the subkey to update. Since there is only one direct subfolder that has been previously explored, there is no point in writing to the MRUListEx value for the subkey. That one folder is already in the first entry of the MRUListEx value. If the MRUListEx value is not written to, the subkey LastWrite time doesn't get updated. Here's an example.

Event A - After exploring "Desktop\CONFIDENTIAL\Z\1\iii"


Event B - After exploring "Desktop\CONFIDENTIAL\Y\1\iii"


In event A, we see that all of the listed entries have been explored. That is, there are shellbags artifacts for every entry in event A. The last explored folder is "Desktop\CONFIDENTIAL\Z\1\iii." In event B, at 4:53, the folder "Desktop\CONFIDENTIAL\Y\1\iii" was traversed. However, only one of the folders is updated -- the "Y" folder.

If we look into the "Desktop\CONFIDENTIAL" subkey, we will see three numbered values: one for "X," one for "Y," and one for "Z." Before event B, "Z" was the most recently explored folder in this subkey. After event B occurs, the MRUListEx value in this subkey will have to be updated so that "Y" becomes the first entry in MRUListEx. MRUListEx has to change because we have three folders that have already been explored (and thus have shellbags entries) within the "Desktop\CONFIDENTIAL" folder. When you only have one folder that has been explored (and thus only has one numbered value in its respective subkey), MRUListEx does not need to be updated.

We can see this demonstrated with the MRU times of "Desktop\CONFIDENTIAL\Y\1" and "Desktop\CONFIDENTIAL\Y\1\iii." We have only explored one folder within the "Desktop\CONFIDENTIAL\Y" and only one folder in "Desktop\CONFIDENTIAL\Y\1." Therefore, if these folders are explored, their MRU times are not going to be changed; the MRUListEx value in each one of these folders' respective subkeys does not need to be changed, as they are already set as the first entry. This results in the subkey's LastWrite time not being updated.




Phase A - Event 11: Close the "CONFIDENTIAL\Z\1\iii" folder [download hive]

Close the window displaying the "CONFIDENTIAL\Z\1\iii" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 12: Copy file.doc to "CONFIDENTIAL\Y\2\ii" via cmd.exe [download hive]

The document "file.doc" was copied to "Desktop\CONFIDENTIAL\Y\2\ii" via the cmd.exe copy command. This will be used to test the effects of navigating folders via a program's Open dialog. (A post by David Cowen that I unfortunately cannot locate influenced this step).

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 13: Install Microsoft Word Viewer [download hive]

The program used to test how the Open dialog affects shellbags artifacts is Microsoft Word Viewer. In this event, it is simply downloaded and installed.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase A - Event 14: Click "Open" in Word Viewer [download hive]

Microsoft Word Viewer is run and the "Open" button is clicked. Upon clicking this button, the Open dialog appeared in a new window showing the user's "Documents" folder by default.

RegRipper's shellbags.pl Output


TZWorks sbag Output


No further action was taken past clicking the "Open" button and letting the Open dialog default to "Documents." We see that the most recently explored folder is no longer "Desktop\CONFIDENTIAL," but "Desktop\MyComputer" and then some. Many new entries are created including a fully traversed path to the user's "Documents" folder. It's interesting to note that respective Bags subkeys were not created for most of these new entries (the subkey created under the Bags subkey is numbered 13 for the "Documents" folder). Also note that we can now see that these tools have translated the System Folder type found within each appropriate entry's numbered value, as mentioned earlier in this post. That is, we can see the text "My Computer" clearly in the output.



Phase A - Event 15: In Word Viewer Open dialog, Click "Desktop" link in left sidebar; Navigate to "CONFIDENTIAL\Y\2\ii\file.doc" [download hive]

While still in the Open dialog of Word Viewer, continue on by clicking the "Desktop" link in the left sidebar. Navigate to "CONFIDENTIAL\Y\2\ii\file.doc" as usual.

RegRipper's shellbags.pl Output


TZWorks sbag Output


We see quite a few things happen here. Two new entries are created and the most recently explored folder directly under the BagMRU subkey is now "CONFIDENTIAL" again (and not MyComputer). Again, we wouldn't be able to tell that this was the case by only looking at the sbag output. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue.



Phase A - Event 16: Open mspaint.exe from Run... Dialog, Click File > Save As... [download hive]

Microsoft Paint is opened to test interaction with the Save dialog. Click File and then Save As... to open the Save dialog. By default, it opens up to the user's "Pictures" folder. The event is stopped here.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Just as what happened with the Open dialog, a folder is opened by default. This time, it's the user's "Pictures" folder. Note that shellbags.pl specifies which folder in the user's Libraries is explored.

Determining How A Folder Was Launched; Gain More MRU Times

There is a way to determine how a given folder was being explored on a system. As an example, say that the folder "C:\Users\someUser\Documents" exists.

If the user navigates to this folder by clicking Start > Computer > C: > Users > someUser > Documents, shellbags artifacts will show an entry for "Desktop\My Computer\C:\Users\someUser\Documents."

If the user navigates to this folder by clicking Start > someUser > Documents, shellbags artifacts will show an entry for "Desktop\Users\someUser\Documents."

If the user navigates to this folder by clickin Start > Documents, shellbags artifacts will show an entry for "Desktop\Libraries\Documents Library."

The great thing about this is that not only can you see the different ways a folder was explored, you can also observe three different MRU times for when this folder was explored (given that special cases are ruled out). This essentially gives you more information to work with to discover the true last time that the folder may have been explored.




Phase A - Event 17: In mspaint.exe Save dialog, Click "Desktop" link in left sidebar; Navigate to "CONFIDENTIAL\Z\2\i\Untitled.png [download hive]

While still in the Save dialog of mspaint, continue on by clicking the "Desktop" link in the left sidebar. Navigate to "CONFIDENTIAL\Z\2\i\" and save it as "Untitled.png."

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of which we haven't seen in previous events; some new entries are created and updates are made to MRU times as expected. A weird thing that happens is that the sbag output shows a Bags subkey for "Desktop" now. Remember: "Desktop" is the root BagMRU subkey. (check subkey "17" under the Bags subkey; it only contains a subkey for ComDlg. This goes for subkey "16" as well, since both of those events involved an Open/Save dialog).

This concludes Phase A of testing. Phase B continues where Phase A left off, leaving all previous shellbags artifacts intact. Phase B works off of a USB flashdrive instead of the Desktop.



Phase B - Event -01: Confirmation of same data where Phase A left off [download hive]

As a sanity check, a test is made to ensure that the data from which we left off Phase A is the same data we're working with now.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Everything checks out and nothing has changed since Phase A.



Phase B - Event 00: Create FAT32 8GB flashdrive E: with label "FLASHDRIVE" [download hive]

An 8GB FAT32 volume is inserted into the machine. It has been initialized and formatted as drive E: and is labeled "FLASHDRIVE." This will be used to perform testing similar to that of Phase A. The difference here is that we are not using a folder placed directly on the desktop, but from a removable device. This will demonstrate how shellbags artifacts can be used to identify explored folders from media that is no longer available to the investigator. E.g. Someone steals documents by copying them to the flashdrive, then opens the flashdrive folders on the same machine.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 01: Re-create deleted "CONFIDENTIAL\X" folder structure on Desktop [download hive]

Since we are working off of the data from Phase A, and we deleted the "X" folder structure back then, we need to recreate it. It is first recreated in the CONFIDENTIAL folder located on the desktop. This was done with the following command via cmd.exe:
C:\Users\4n6k\Desktop>mkdir CONFIDENTIAL\X\1\i CONFIDENTIAL\X\1\ii CONFIDENTIAL\X\1\iii CONFIDENTIAL\X\2\i CONFIDENTIAL\X\2\ii CONFIDENTIAL\X\2\iii CONFIDENTIAL\X\3\i CONFIDENTIAL\X\3\ii CONFIDENTIAL\X\3\iii

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 02: Drag/drop CONFIDENTIAL folder from Desktop to root of (Start > My Computer) E:\ [download hive]

I wanted to put the same folder structure from the desktop onto the E: flashdrive. This was done by opening Start > Computer, dragging the "CONFIDENTIAL" folder from the desktop, and dropping it onto the E: drive icon. At this point, the CONFIDENTIAL folder structure also exists on the flashdrive. 

RegRipper's shellbags.pl Output


TZWorks sbag Output


The only change made here is that the MRU time of "My Computer" is updated. Otherwise, nothing has changed.



Phase B - Event 03: Navigate to "E:\CONFIDENTIAL\X\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder within the CONFIDENTIAL folder is explored until "E:\CONFIDENTIAL\X\1\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


From here on in, we shouldn't see any of the entries above the "My Computer" entry get updated. We are not going to touch the folders on the desktop anymore. In this event, we see five new entries as a result of the traversal of the "E:\CONFIDENTIAL\X\1\iii" folder. Again, note that sbag is updating the MRU time of the CONFIDENTIAL folder on the desktop and the UserLibraries folder even though we didn't do anything with them. It's doing this because the associated "Desktop\My Computer," "Desktop\{CLSID_UserLibraries}", and "Desktop\CONFIDENTIAL" subkeys are direct subkeys of the BagMRU subkey. It is pulling the BagMRU subkey's LastWrite time -- which is normal -- but it is not checking to see which one is the first entry in MRUListEx. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue.

Another quick thing to note here is that the time granularity of the access times for the entries of this flashdrive. Remember that it is formatted as FAT32, so we're going to see an access time granularity of 1 day. Since I am in central time and FAT32 is recorded in localtime, we are seeing an accessed date of 6:00:00 instead of the UTC 12:00:00.



Phase B - Event 04: Move window of "E:\CONFIDENTIAL\X\1\iii" to the right [download hive]

A test was run to see what would change if the opened window was moved/positioned slightly to the right. The window displaying "E:\CONFIDENTIAL\X\1\iii" was left-clicked, held down, and dragged slightly to the right.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts. There were changes to the respective Bags subkeys, as the folder's position had changed, but nothing was changed in regard to BagMRU.



Phase B - Event 05: Close the "E:\CONFIDENTIAL\X\1\iii" folder [download hive]

Close the window displaying the "CONFIDENTIAL\X\1\iii" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts. There were changes to the respective Bags subkeys, as the folder's position had changed, but nothing was changed in regard to BagMRU.



Phase B - Event 06: Navigate to "E:\CONFIDENTIAL\X\2\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder within the CONFIDENTIAL folder is explored until "E:\CONFIDENTIAL\X\2\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


At this point, we are running similar tests that were previously performed in Phase A. Two new entries are created and some MRU time updates are made to reflect folder exploration. Nothing too new here.



Phase B - Event 07: Click the "back" button in Explorer to go back to "E:\CONFIDENTIAL\X\2" [download hive]

With the "E:\CONFIDENTIAL\X\2\iii" folder opened, the "back" button is clicked within Explorer. This takes us back to "E:\CONFIDENTIAL\X\2."

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 08: Close the "E:\CONFIDENTIAL\X\2" folder [download hive]

Close the window displaying the "CONFIDENTIAL\X\2" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 09: Navigate to "E:\CONFIDENTIAL\Y\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder within the CONFIDENTIAL folder is explored until "E:\CONFIDENTIAL\Y\1\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Again, nothing new here. We have seen this behavior before. New entries created, some MRU times updated. This will be the case until we reach the later events.



Phase B - Event 10: Close the "E:\CONFIDENTIAL\Y\1\iii" folder [download hive]

Close the window displaying the "CONFIDENTIAL\Y\1\iii" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 11: Delete the "E:\CONFIDENTIAL\X" folder via cmd.exe [download hive]

The "E:\CONFIDENTIAL\X" folder branch is deleted via cmd.exe using the command rd /s /q E:\CONFIDENTIAL\X. The only remaining folder branches that exist in the E:\CONFIDENTIAL folder are "Y" and "Z."

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 12: Navigate to "E:\CONFIDENTIAL\Z\1\iii" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder within the CONFIDENTIAL folder is explored until "E:\CONFIDENTIAL\Z\1\iii" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Just as in Phase A, we see sbag update the MRU time of "E:\CONFIDENTIAL\X" even though it no longer exists on the flashdrive. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue. Behavior for the rest of the event is reported as expected: three new entries; MRU time updates of affected folders explored.



Phase B - Event 13: Close the "E:\CONFIDENTIAL\Z\1\iii" folder [download hive]

Close the window displaying the "CONFIDENTIAL\X\1\iii" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 14: Remove current E:\ HDD; insert new 16GB HDD and assign to E:\ (format as NTFS this time) [download hive]

Remove the flashdrive currently assigned E:, insert a new 16GB flashdrive, initialize it, but format it as NTFS this time. This was done to demonstrate how the initial MAC times of these entries will not change. It was also done to test how the entries react to similarly named items on a completely different device.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 15: Create "E:\NEW_HDD\docs" & "E:\CONFIDENTIAL\new_hdd_data\files" [download hive]

Folders were created on the new NTFS flashdrive: "E:\NEW_HDD\docs" and "E:\CONFIDENTIAL\new_hdd_data\files." This was done using the mkdir command via cmd.exe.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 16: Navigate to "E:\NEW_HDD\docs" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder is explored in the NEW_HDD folder until "E:\NEW_HDD\docs" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder. (Thanks to Peter Tees for sniping a typo in this event)

RegRipper's shellbags.pl Output


TZWorks sbag Output


[UPDATE #04 01/14/2014] The issues described below have been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address the issue.

This is where we run into big trouble when using TZWorks sbag. As we can see from both outputs, two new entries are created for the newly explored folders. But take a look at the MRU times in sbag's output. It has updated the MRU time of E:\CONFIDENTIAL. Remember: we explored E:\NEW_HDD\docs and nothing else. The new E:\CONFIDENTIAL folder has not been explored. And even if it didn't exist on the drive (i.e. if E:\CONFIDENTIAL\new_hdd_data\files was never created in Event 15), sbag's regtime for E:\CONFIDENTIAL would still be updated.

If one were to base a case on what sbag is reporting, an investigator could incorrectly assume that there was an explored CONFIDENTIAL folder on this new USB device. And if there wasn't an E:\CONFIDENTIAL folder on the new USB device at all, it would be even worse: the MRU time would be updated for a folder that was never even on the drive. Even if one were to use other artifacts such as USB connection times, the investigator would still see that the device that was last connected right before the MRU time was the NEW flashdrive assigned to E: and NOT the flashdrive that actually has the explored CONFIDENTIAL folder on it.

Now, playing this out a little in an example scenario, let's say that the investigator [incorrectly] concludes that there used to be a CONFIDENTIAL folder on this new flashdrive assigned to E: (for the sake of this scenario, let's assume that E:\CONFIDENTIAL has never existed on the new drive (i.e. that event 15's mkdir E:\CONFIDENTIAL\new_hdd_data\files command never happened). The custodian in question is then required to hand over the new USB device (because we confirmed by serial number that it was the last-connected USB device right before the CONFIDENTIAL folder's MRU time, remember?). You are given the USB device and you find no traces of a CONFIDENTIAL folder anywhere. This could end in two ways: 1) you look incompetent for previously concluding that there was a CONFIDENTIAL folder where there wasn't one or 2) you say that the CONFIDENTIAL folder was deleted and overwritten (whether you believe it or not), further fueling the fire that is your initial, incorrect assumption. Of course, the ethical thing to do here would be to admit you were wrong and revisit the initial assumption.

Of course, the above is a massive dramatization of what could happen, but it certainly is possible.

The point is, sbag's MRU time reporting could be misleading and could potentially lead to incorrect assumptions. In the end, though, you can't blame a tool for an irresponsible investigator. It is up to the investigator to know what he/she is seeing. Again, don't blindly trust a tool; know how it works and how to interpret its output. This is also why it is so important to look at more than one or two artifacts when working a case. In the scenario above, shellbags and USB connection times weren't enough to give us the right answer. The investigator should be looking at so many other things like LNK files showing what was opened from the E: drive and when, historical VSC Usrclass.dat hives showing earlier shellbags and USB connection states, INDX files on the removable devices you have in your possession, time correlation of all of these events, etc. (technically, in this example, we could also potentially support the theory that this is a different drive based on 1) the shellbags "atime" and 2) when the new flashdrive's $MFT was created).

We can completely avoid the above scenario by looking at shellbags.pl's output. Confusion is minimized and we only see the most recently explored folder's MRU time.

With that said, let's move on and see another example of this in event 18.



Phase B - Event 17: Close the "E:\NEW_HDD\docs" folder [download hive]

Close the window displaying the "E:\NEW_HDD\docs" folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Nothing of significance to report; this event does not cause changes to BagMRU shellbags artifacts.



Phase B - Event 18: Navigate to "E:\CONFIDENTIAL\new_hdd_data\files" via Explorer; double-clicking each folder approximately 2 seconds apart [download hive]

From Start > Computer > E:\, each folder within the CONFIDENTIAL folder is explored until "E:\CONFIDENTIAL\new_hdd_data\files" is reached. This is done by double-clicking a folder, waiting about 2 seconds, then exploring the next folder.

RegRipper's shellbags.pl Output


TZWorks sbag Output


Going along with what we saw in event 16, we again see some new entries created. It is important to note that this CONFIDENTIAL folder is not the same one that was on the 8GB FAT32 flashdrive. This CONFIDENTIAL folder was created on the new 16GB NTFS flashdrive. It just so happens to have the same name. (And while we're at it, let's assume it's not called CONFIDENTIAL, as that is usually a dead giveaway as to what a former employee is not supposed to have in their possession).

We also see a few MRU time updates in the sbag output. This time, we also see updates for subfolders within the E:\CONFIDENTIAL folder (e.g. X, Y, Z). On that note, we also see shellbags.pl update the E:\CONFIDENTIAL folder's MRU time. This makes sense, though, because we are exploring a folder with the same exact path of a folder we have previously explored.

Note that, throughout all of these tests, the MAC times have never changed from their initial values. Even after we visited the same folder (e.g. E:\CONFIDENTIAL) -- first from a FAT32 drive and then from an NTFS drive -- the MAC times from the folder on the FAT32 drive remained.



New Findings

So far, we can gather the following from earlier in the post:
  • The first explored time of some folders can be determined
  • Some tools might not be showing you unassuming MRU times
  • The means by which a folder was accessed can potentially be determined
There was one other finding that I found to be pretty interesting. While testing, it occurred to me that Acronis True Image files (.tib) are very similar to zip files in terms of interacting with the Windows Explorer shell. That is, just as you can double-click a zip file to explore its contents via Explorer (granted 7zip or WinRAR isn't the default viewer), you can double-click a .tib backup and do the same. However, doing so results in a slightly different looking shellbags artifact.

Fig. 10 - If Acronis True Image is installed, a user can double-click a .tib file to explore it.

I wanted to see what exploring this .tib file would look like in shellbags, so I started by first traversing the .tib a few folders deep. The full path of the .tib file in this instance was C:\My backups\My Documents\My Documents_full_b1_s1_v1.tib. The full, traversed path within the .tib file was C:\Users\a\Documents\Stolen Stuff\CONFIDENTIAL\Contact.Lists. I thought it would be a good idea to throw them into the two tools I had been using previously. Here is what is reported by RegRipper's shellbags.pl and TZWorks sbag:

[download hive]

RegRipper's shellbags.pl Output



TZWorks sbag Output


As we can see, shellbags.pl doesn't recognize the class type indicator of 0x52, so it defaults to "Unknown Type." [UPDATE #01 12/16/2013]: RegRipper's shellbags.pl is on track to support the 0x52 shell item type. I have confirmation from Harlan Carvey that these entries are parsed correctly. Although entries are a bit lengthy, TZWorks sbag seems to be able to output some readable paths, which is nice. But something still seems a bit off there. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! Paths are now parsed correctly.

In the case of shellbags.pl, I was able to review the source and see why this shell item type wasn't being parsed. I cannot stress enough how necessary and convenient it is to be able to review the source of a tool to see how something works. It is through these open source tools that the community learns, making the forensics space a more exciting one for those who take the time out to actually review them.

As a disclaimer, I question whether or not this is a completely new shell item type, as there are some similarities between this and shellbags artifacts of traversed zip subfolders. Though, there is enough that isn't the same that makes me think this is something completely different. For one, entries with this type do not have embedded last modified dates* (they aren't as clear as the embedded datetime in zip subfolder entries, if there are). Also, unlike zip subfolder entries, they have a 0x52 class type indicator for every subfolder under the root .tib

Extra Timestamp Found In Zip File Shellbags Entries

*There seems to be some confusion as to what the extra embedded timestamp inside of zip subfolder shell items represents. In the description of the "parseZipSubFolderItem()" subroutine in shellbags.pl, it says that this embedded time seems to represent the time at which the subfolder was accessed/opened. On the surface, I wasn't seeing this in my testing. So I went ahead and ran a more controlled experiment.

I created a .zip file from folders that were last created and modified years ago. I traversed some of the zip file's subfolders and then ran shellbags.pl against it. Here are the results:

Aside: shellbags.pl seems to tack on "\Wallpapers" to the end of the path. That folder doesn't exist. It seems to be adding the "current directory" (as we will see explained in the .tib shell item structure section below) to the end of the path.

The Zip_Subfolder column is populated with the additional timestamps found in this unique shell item. I wanted to see exactly which timestamp this represents, so I looked at the MAC times of the three original, unzipped folders that I explored:

Fig. 11 - FTK Imager showing MAC times of the three original, unzipped directories

The folder "G:\Pix\Screen\Wallpapers" has a modified and access time of 9/2/2013 7:48:55 AM. Apply the Central time zone change and you get 1:48:55AM. This time is one second later than the time reported in the shellbags.pl output. The same goes for the "G:\Pix\Screen\Wallpapers\Mine" and "G:\Pix\Screen\Wallpapers\Quality" folders. We know that the time being represented in the shellbags.pl output is the modified date because it is the only one that matches (or is very close to) a unique MAC time in the case of the "Quality" folder.

 Fig. 12 - A registry viewer (WRR) showing the embedded modified time in the numbered value for the zipped, "Quality" subfolder. This value is used in the "Zip_Subfolder" column of shellbags.pl.

As a sidenote, when I look at which times are available within the subfolders of the zip file (via FTK Imager), I see the exact times that are shown in the shellbags.pl output:

Fig. 13 - FTK Imager showing MAC times of the three zipped directories. The timestamps of these directories were stored within the zip file in Central time, not UTC.

In all honesty, that one-second discrepancy is odd. I would have expected the shellbags output to be one second later than it should be if anything. If anyone can explain this, I would love to know. In any case, this still shows us that it's the last modified time that is embedded into zip subfolder shell items.

Anyway, below are some details on this new (?) shell item type. Fig. 14 shows the BagMRU subkey along with the expanded branch related to the above animated gif. That is, this registry branch basically shows us each folder within Desktop\C:\My backups\My Documents\My Documents_full_b1_s1_v1.tib\My Documents\C:\

Fig. 14 - Expanded view of the branch containing the Acronis .tib file

As a guide, below is what I have been able to identify in this new shell type. Take these highlights with a grain of salt, as I admittedly do not know for sure if they are as accurate as they can be.

Offset 0x00 = item size
Offset 0x02 = class type indicator
Offset 0x32 = current folder
Offset 0x?? = full path up to current folder
 

A
0000 0000:  19 00 2f 43 3a 5c 00 00  00 00 00 00 00 00 00 00  ../C:\..........
0000 0010:  00 00 00 00 00 00 00 00  00 00 00                 ...........



Drive/Volume entry shell item. Stores a "0" value containing the above binary data.

B
0000 0000:  5a 00 31 00 00 00 00 00  74 43 f2 26 10 00 4d 59  Z.1.....tC.&..MY
0000 0010:  42 41 43 4b 7e 31 00 00  42 00 08 00 04 00 ef be  BACK~1..B.......
0000 0020:  74 43 f2 26 74 43 f2 26  2a 00 00 00 d6 bf 00 00  tC.&tC.&*.......
0000 0030:  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
0000 0040:  00 00 4d 00 79 00 20 00  62 00 61 00 63 00 6b 00  ..M.y. .b.a.c.k.
0000 0050:  75 00 70 00 73 00 00 00  18 00 00 00              u.p.s.......



Folder entry shell item. Stores a "0" value containing the above binary data.

C  
0000 0000:  5e 00 31 00 00 00 00 00  74 43 10 27 10 00 4d 59  ^.1.....tC.'..MY
0000 0010:  44 4f 43 55 7e 31 00 00  46 00 08 00 04 00 ef be  DOCU~1..F.......
0000 0020:  74 43 f2 26 74 43 10 27  2a 00 00 00 c8 c0 00 00  tC.&tC.'*.......
0000 0030:  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
0000 0040:  00 00 4d 00 79 00 20 00  44 00 6f 00 63 00 75 00  ..M.y. .D.o.c.u.
0000 0050:  6d 00 65 00 6e 00 74 00  73 00 00 00 18 00 00 00  m.e.n.t.s.......



Another folder entry shell item. Stores a "0" value containing the above binary data.

D
0000 0000:  86 00 32 00 00 14 00 00  74 43 10 27 20 00 4d 59  ..2.....tC.' .MY
0000 0010:  44 4f 43 55 7e 31 2e 54  49 42 00 00 6a 00 08 00  DOCU~1.TIB..j...
0000 0020:  04 00 ef be 74 43 10 27  74 43 10 27 2a 00 00 00  ....tC.'tC.'*...
0000 0030:  3b f5 00 00 00 00 03 00  00 00 00 00 00 00 00 00  ;...............
0000 0040:  00 00 00 00 00 00 4d 00  79 00 20 00 44 00 6f 00  ......M.y. .D.o.
0000 0050:  63 00 75 00 6d 00 65 00  6e 00 74 00 73 00 5f 00  c.u.m.e.n.t.s._.
0000 0060:  66 00 75 00 6c 00 6c 00  5f 00 62 00 31 00 5f 00  f.u.l.l._.b.1._.
0000 0070:  73 00 31 00 5f 00 76 00  31 00 2e 00 74 00 69 00  s.1._.v.1...t.i.
0000 0080:  62 00 00 00 1c 00 00 00                           b.......



One more folder entry shell item before we get into the new shell item type. Stores a "0" value containing the above binary data.

E
0000 0000:  a6 00 52 67 b1 ac 01 00  00 00 00 00 00 00 00 00  ..Rg............
0000 0010:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
0000 0020:  03 de 3d 27 74 42 00 00  00 00 00 00 00 00 25 00  ..='tB........%.
0000 0030:  00 00 30 00 43 00 32 00  46 00 34 00 45 00 45 00  ..0.C.2.F.4.E.E.
0000 0040:  42 00 2d 00 30 00 42 00  30 00 39 00 2d 00 34 00  B.-.0.B.0.9.-.4.
0000 0050:  43 00 39 00 32 00 2d 00  39 00 30 00 44 00 31 00  C.9.2.-.9.0.D.1.
0000 0060:  2d 00 34 00 31 00 39 00  31 00 30 00 41 00 31 00  -.4.1.9.1.0.A.1.
0000 0070:  41 00 41 00 46 00 42 00  33 00 00 00 0d 00 00 00  A.A.F.B.3.......
0000 0080:  4d 00 79 00 20 00 44 00  6f 00 63 00 75 00 6d 00  M.y. .D.o.c.u.m.
0000 0090:  65 00 6e 00 74 00 73 00  00 00 01 00 00 00 00 00  e.n.t.s.........
0000 00a0:  01 00 00 00 00 00 00 00                           ........



The first two bytes indicate the size of this particular item. This will vary. 0x52 is the class type indicator. Tools can use this as a type of identifying byte when determining which type of shell item to parse. "My Documents" was the name of the backup and if my identification is correct, it is also the full path traversed inside of the .tib starting from its root. I am not sure what the number before it is (0C2F4EEB-0B09-4C92-90D1-41910A1AAFB3), but it looks like a CLSID. This entry and the next one are a bit odd-looking.

F
0000 0000:  52 00 52 67 b1 ac 02 00  00 00 00 00 00 00 00 00  R.Rg............
0000 0010:  00 00 16 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
0000 0020:  00 00 00 00 00 00 00 00  00 00 00 00 00 00 03 00  ................
0000 0030:  00 00 43 00 3a 00 00 00  03 00 00 00 43 00 3a 00  ..C.:.......C.:.
0000 0040:  00 00 03 00 00 00 43 00  3a 00 00 00 01 00 00 00  ......C.:.......
0000 0050:  00 00 00 00                                       ....



For some reason, there is an extra "C:" instance here.

G
0000 0000:  60 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  `.Rg............
0000 0010:  00 00 11 00 00 00 00 00  63 d9 09 a1 73 42 00 00  ........c...sB..
0000 0020:  63 d9 09 a1 73 42 00 00  00 00 00 00 00 00 06 00  c...sB..........
0000 0030:  00 00 55 00 73 00 65 00  72 00 73 00 00 00 01 00  ..U.s.e.r.s.....
0000 0040:  00 00 00 00 09 00 00 00  43 00 3a 00 2f 00 55 00  ........C.:./.U.
0000 0050:  73 00 65 00 72 00 73 00  00 00 01 00 00 00 00 00  s.e.r.s.........
0000 0060:  00 00                                             ..



We start to see some more normal-looking data in that the current folder and the full path up until the current folder are pretty clear and consistent. All of the following examples are pretty standard and follow this pattern (i.e. "Users" is the current folder and "C:\Users" is the full path so far).

H
0000 0000:  5c 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  \.Rg............
0000 0010:  00 00 10 00 00 00 00 00  35 35 3c 27 74 42 00 00  ........55<'tB..
0000 0020:  35 35 3c 27 74 42 00 00  00 00 00 00 00 00 02 00  55<'tB..........
0000 0030:  00 00 61 00 00 00 01 00  00 00 00 00 0b 00 00 00  ..a.............
0000 0040:  43 00 3a 00 2f 00 55 00  73 00 65 00 72 00 73 00  C.:./.U.s.e.r.s.
0000 0050:  2f 00 61 00 00 00 01 00  00 00 00 00 00 00        /.a...........



I
0000 0000:  80 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  ..Rg............
0000 0010:  00 00 11 00 00 00 00 80  b0 10 3d 27 74 42 00 80  ..........='tB..
0000 0020:  b0 10 3d 27 74 42 00 00  00 00 00 00 00 00 0a 00  ..='tB..........
0000 0030:  00 00 44 00 6f 00 63 00  75 00 6d 00 65 00 6e 00  ..D.o.c.u.m.e.n.
0000 0040:  74 00 73 00 00 00 01 00  00 00 00 00 15 00 00 00  t.s.............
0000 0050:  43 00 3a 00 2f 00 55 00  73 00 65 00 72 00 73 00  C.:./.U.s.e.r.s.
0000 0060:  2f 00 61 00 2f 00 44 00  6f 00 63 00 75 00 6d 00  /.a./.D.o.c.u.m.
0000 0070:  65 00 6e 00 74 00 73 00  00 00 01 00 00 00 00 00  e.n.t.s.........
0000 0080:  00 00                                             ..



J
0000 0000:  a0 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  ..Rg............
0000 0010:  00 00 10 00 00 00 00 80  97 a6 3d 27 74 42 00 80  ..........='tB..
0000 0020:  97 a6 3d 27 74 42 00 00  00 00 00 00 00 00 0d 00  ..='tB..........
0000 0030:  00 00 53 00 74 00 6f 00  6c 00 65 00 6e 00 2e 00  ..S.t.o.l.e.n...
0000 0040:  53 00 74 00 75 00 66 00  66 00 00 00 01 00 00 00  S.t.u.f.f.......
0000 0050:  00 00 22 00 00 00 43 00  3a 00 2f 00 55 00 73 00  .."...C.:./.U.s.
0000 0060:  65 00 72 00 73 00 2f 00  61 00 2f 00 44 00 6f 00  e.r.s./.a./.D.o.
0000 0070:  63 00 75 00 6d 00 65 00  6e 00 74 00 73 00 2f 00  c.u.m.e.n.t.s./.
0000 0080:  53 00 74 00 6f 00 6c 00  65 00 6e 00 2e 00 53 00  S.t.o.l.e.n...S.
0000 0090:  74 00 75 00 66 00 66 00  00 00 01 00 00 00 00 00  t.u.f.f.........
0000 00a0:  00 00                                             ..



K
0000 0000:  ba 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  ..Rg............
0000 0010:  00 00 10 00 00 00 00 00  c9 40 3d 27 74 42 00 00  .........@='tB..
0000 0020:  c9 40 3d 27 74 42 00 00  00 00 00 00 00 00 0d 00  .@='tB..........
0000 0030:  00 00 43 00 4f 00 4e 00  46 00 49 00 44 00 45 00  ..C.O.N.F.I.D.E.
0000 0040:  4e 00 54 00 49 00 41 00  4c 00 00 00 01 00 00 00  N.T.I.A.L.......
0000 0050:  00 00 2f 00 00 00 43 00  3a 00 2f 00 55 00 73 00  ../...C.:./.U.s.
0000 0060:  65 00 72 00 73 00 2f 00  61 00 2f 00 44 00 6f 00  e.r.s./.a./.D.o.
0000 0070:  63 00 75 00 6d 00 65 00  6e 00 74 00 73 00 2f 00  c.u.m.e.n.t.s./.
0000 0080:  53 00 74 00 6f 00 6c 00  65 00 6e 00 2e 00 53 00  S.t.o.l.e.n...S.
0000 0090:  74 00 75 00 66 00 66 00  2f 00 43 00 4f 00 4e 00  t.u.f.f./.C.O.N.
0000 00a0:  46 00 49 00 44 00 45 00  4e 00 54 00 49 00 41 00  F.I.D.E.N.T.I.A.
0000 00b0:  4c 00 00 00 01 00 00 00  00 00 00 00              L...........



L
0000 0000:  d8 00 52 67 b1 ac 03 00  00 00 00 00 00 00 00 00  ..Rg............
0000 0010:  00 00 10 00 00 00 00 80  94 68 3d 27 74 42 00 80  .........h='tB..
0000 0020:  94 68 3d 27 74 42 00 00  00 00 00 00 00 00 0e 00  .h='tB..........
0000 0030:  00 00 43 00 6f 00 6e 00  74 00 61 00 63 00 74 00  ..C.o.n.t.a.c.t.
0000 0040:  2e 00 4c 00 69 00 73 00  74 00 73 00 00 00 01 00  ..L.i.s.t.s.....
0000 0050:  00 00 00 00 3d 00 00 00  43 00 3a 00 2f 00 55 00  ....=...C.:./.U.
0000 0060:  73 00 65 00 72 00 73 00  2f 00 61 00 2f 00 44 00  s.e.r.s./.a./.D.
0000 0070:  6f 00 63 00 75 00 6d 00  65 00 6e 00 74 00 73 00  o.c.u.m.e.n.t.s.
0000 0080:  2f 00 53 00 74 00 6f 00  6c 00 65 00 6e 00 2e 00  /.S.t.o.l.e.n...
0000 0090:  53 00 74 00 75 00 66 00  66 00 2f 00 43 00 4f 00  S.t.u.f.f./.C.O.
0000 00a0:  4e 00 46 00 49 00 44 00  45 00 4e 00 54 00 49 00  N.F.I.D.E.N.T.I.
0000 00b0:  41 00 4c 00 2f 00 43 00  6f 00 6e 00 74 00 61 00  A.L./.C.o.n.t.a.
0000 00c0:  63 00 74 00 2e 00 4c 00  69 00 73 00 74 00 73 00  c.t...L.i.s.t.s.
0000 00d0:  00 00 01 00 00 00 00 00  00 00                    ..........



M
Youngest child subkey; no numbered values.

For what it's worth, this kind of shell item can tell us what was potentially in backups made by Acronis True Image. I would imagine there are more programs that allow for file traversal like this, as well. [UPDATE #03 12/28/2013]: Nicole Ibrahim wrote a nice shellbags post focused upon MTP devices.



Caveats

As we can see from the above testing, shellbags artifacts aren't as simple as they may seem. There are many caveats and special cases to take into consideration during analysis. To sum up some of the main caveats from analysis and testing:
  • Deleted folders' shellbags entries can be updated if new folders share the same name/path.
  • MRU times for folders that have previously been explored (i.e. have shellbags entries) and only have one direct subfolder will not get updated. 
  • Not all shellbags parsers are created equal.
  • MAC times contained within each shellbags entry will not update after a folder's first exploration.
  • When a folder that previously had not been explored is explored, the root BagMRU subkey's LastWrite time will get updated, causing direct child subkeys to report an updated MRU time.
The main takeaway from all of this is just to be careful when analyzing this artifact. As with everything else, it is not the only artifact that you can rely on in an investigation.



Further Research

As this post winds down, it's important to note that there is more that can be done to document the behavior of shellbags. And although this post covers quite a bit, there is still a lot more out there to be discovered and analyzed.

Joachim Metz has done a great job keeping tabs on shell item types. More focus on this kind of work would allow for better understanding of shell item structures and thus, a better understanding of the artifact as a whole.

As with other artifacts, behavior within Windows 8 is still (as far as I can tell) untested. We have seen some changes to certain artifacts under Windows 8, such as new timestamps introduced in Prefetch files. It would be interesting to see what changes Windows 8 has in store for shellbags artifacts (if any).

It would also be interesting to see what could be gleaned from the positions and sizes of windows, if anything. I largely focused on the BagMRU subkey and didn't really venture into the Bags subkey. Could we potentially tell if someone purposefully manipulated certain folder views from their defaults (if there are any), proving intent?

There are some things I would like to see implemented in existing shellbags parsers, too. If the 0x52 shell item type is worth looking into, it might be a good addition to some existing tools. Also, adding a column for shellbags entries that are able to have their "first explored" time determined (that is, the youngest child subkeys in a given path) would be a useful feature, as well.

In the same vein, I'd like to see TZWorks sbag work with the MRU time issue that is referenced a few times in this post. I know that a lot of investigators rely on the TZWorks tools for analysis, so making sure the right data is reported is important. [UPDATE #04 01/14/2014] This has been fixed in TZWorks sbag v0.35! An MRU indicator column has been added to address this issue. As a whole, I've had good experiences with TZWorks utilities, so seeing an explanation as to why the tools acts this way or if a fix is viable would be great.

And as a quick aside, Volatility is still working its magic, as per usual, and is now able to glean some shellbags information from user hives in memory. I thought this was pretty interesting, but had nowhere to really mention it.

It should be noted that having open source code available to me during these tests made it much easier to understand what I was seeing. By reviewing the source, determinations on exactly how the output is formed could be made. The usual, often frustrating blackbox testing was minimized -- at least in the case of RegRipper's shellbags.pl. By having the source code for a tool, I can vouch for a given tool's reliability. Without open source tools, a good amount of this post would cease to exist. With that said, I encourage people to really delve into these tools and if you have some of your own, consider making them open source.



Validate My Testing

It wouldn't be true testing without having other people work with your data set. It is for this reason that I have made all of the UsrClass.dat hives used at every step in this testing available for download. You can download individual hives by clicking the download link at the end of each event heading or download them all in .zip format using the following links:

Shellbags-Phase_A.zip
Shellbags-Phase_A_Granular.zip
Shellbags-Phase_B.zip
Shellbags-Acronis_0x52_Shell_Item_Type.zip

Following along with each step will help in understanding exactly how this artifact works. I highly recommend taking a look through the hives to become familiar with what you will run into during analysis.



Closing Remarks

On a more informal note, the only true way to know how something works is to experiment with it yourself. If you read something or are told something, don't just blindly believe it. Challenge it and do the work on your own to confirm or deny someone else's claim. No need to reinvent the wheel, just use what's available to you and test. With the amount of information available to anyone with an internet connection, there's no excuse not to research that of which you are unfamiliar.

This stuff takes time; you won't be able to cover everything at all times. And occasionally you'll be wrong. But that shouldn't stop you from continuing to research and learn. Fail, learn from it, and keep going.

Anyone can run a tool. It's knowing what the tool is doing, how to interpret the output, and how to use it effectively that makes you a reliable investigator.

All of these artifacts work together; shellbags do not stand alone. You can't solve a puzzle with one piece.

-Dan Pullega (@4n6k) || LinkedIn || Email



References
01. Computer Forensic Artifacts: Windows 7 Shellbags (by Chad Tilbury)
02. Windows Shellbag Forensics (by Willi Ballenthin)
03. Windows Shell Item Format v0.0.21 (by Joachim Metz)
04. Using Shellbag Information to Reconstruct User Activities (by Yuandong Zhu)
05. Windows Forensic Analysis Toolkit 3E (by Harlan Carvey)
06. ShellBag Analysis (by Harlan Carvey)
07. Shellbag Analysis, Revisited...Some Testing (by Harlan Carvey)
08. Shell Item Artifacts, Reloaded (by Harlan Carvey)
09. Windows Shellbag Parser: sbag (by TZWorks)
10. MoVP 3.2 Shellbags in Memory, SetRegTime, and TrueCrypt Volumes (by Jamie Levy)
11. Shellbags Description (by Microsoft KB)
12. NTFS INDX Parsing (by Willi Ballenthin)
13. RecentDocs Artifact (by Joe Garcia) 
14. MTP Device Shellbags (by Nicole Ibrahim)