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 #14 08/18/2017]: A significant new finding has been discovered. Note that a shellbag entry is created upon simply clicking on a folder. You do not have to navigate into it for shellbag artifacts to populate.
[UPDATE #13 05/01/2015]: This post has been cited as a source in the"Windows Registry" section of Incident Response & Computer Forensics, 3rd ed. (p.399).
[UPDATE #12 10/01/2014]: Eric Zimmerman has released his new Windows GUI tool, Shellbags Explorer. It is my new go-to tool for shellbags analysis. Download it here.
[UPDATE #11 09/26/2014]: Big thanks to Sébastien Moulun (@SebMln), @binaryz0ne, and Mike Pilkington (@mikepilkington) for sharing some UsrClass.dat hives to further develop this research.
[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.
[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."
[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 MACE 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
- More network folders stored in this hive
- 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 interacted with 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 interacted with. 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/interacted with -- per user.
- able to see full paths of these folders
- Preserves MACE times of folders.
- *these embedded times do not get updated after shell item is first created
- these embedded times are pulled from the MFT (FILETIME format) and are translated into DOSDate time stamps
- [UPDATE 12/6/2013] As Joachim Metz has pointed out in the comments, this is not always the case. See his comment about file entry shell items.
- 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 interacted with.
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 interacted with (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 interacted with via Explorer before being deleted, the shellbag artifact (and thus, the full path + initial MACE times) for that folder will remain.
- Historical MACE times of folders corresponding to the time that the folders were first interacted with via Explorer.
- Useful for determining whether or not folders were copied/moved to a new volume.
- Which user(s) interacted with certain folders.
- The means by which a folder was interacted with (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 interacted with.*****
- 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*****
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) MACE 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 may hold 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 interacted with 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 interacted with 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:
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).
_______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 interacted with 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 interacted with 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 interacted with is interacted with (thus creating a new shellbags entry). This is why the BagMRU subkey sometimes has a registry LastWrite time of the latest folder interaction (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 interacted with 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 interacted with. Before "2" was interacted with, the "1" value (i.e. the "Songs" folder) was interacted with and before that, the "0" value was interacted with (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 interacted with via Explorer. We now know the time that the "K:\Documents" folder was last interacted with. We cannot, however, determine with certainty the time that values "1" and "2" (i.e. the "Pix" and "Songs" folders) were last interacted with, as they are not the first entry in MRUListEx.*
Determining "First Interacted" Times of "Youngest Child" Subkeys
*Technically, we could determine the first interacted 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 interacted with because no folders inside of them were interacted with. 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.
*Technically, we could determine the first interacted 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 interacted with because no folders inside of them were interacted with. 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)
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.
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 MACE 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 MACE 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:
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 interacted with, NodeSlots is not updated and therefore, the BagMRU subkey LastWrite time is not updated.
The point is, if a folder that hasn't been interacted with before is interacted with, 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 interacted with, 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 interacted with. Because, in reality, the CONFIDENTIAL folder wasn't interacted with 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 interacted with folder was a newly interacted with 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 interacted with and you can confirm the false times. But even then, you will only be able to confirm this based on the most recently interacted with new folder. That is, if two new folders are interacted with 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 interacted with (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.
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:
- Reads the "0" value within BagMRU (the 0 value represents the "CONFIDENTIAL" folder)
- Sees that the MRUListEx matches "00 00 00 00" (i.e. the "0" value) and does not equal "FF FF FF FF"
- 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.
Fig. 8 - Contents of the BagMRU subkey after one folder has been interacted with
Fig. 9 - Contents of the BagMRU subkey after two folders have been interacted with
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 interacted with, NodeSlots is not updated and therefore, the BagMRU subkey LastWrite time is not updated.
The point is, if a folder that hasn't been interacted with before is interacted with, 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 interacted with, 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 interacted with. Because, in reality, the CONFIDENTIAL folder wasn't interacted with 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 interacted with folder was a newly interacted with 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 interacted with and you can confirm the false times. But even then, you will only be able to confirm this based on the most recently interacted with new folder. That is, if two new folders are interacted with 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 interacted with (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 interacted with 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 interacted with. 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 interacted with.
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 interacted with 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 uninteracted with folder (i.e. a folder with an existing shellbags entry) is not updated.
If you interact with a folder that has been previously uninteracted with (and thus has an entry in shellbags) AND there is only one numbered value within its subkey (i.e. if a previously interacted with folder has only one previously interacted with 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 interacted with, 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 interacted with. That is, there are shellbags artifacts for every entry in event A. The last interacted with 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 interacted with 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 interacted with (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 interacted with, 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.
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 uninteracted with folder (i.e. a folder with an existing shellbags entry) is not updated.
If you interact with a folder that has been previously uninteracted with (and thus has an entry in shellbags) AND there is only one numbered value within its subkey (i.e. if a previously interacted with folder has only one previously interacted with 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 interacted with, 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 interacted with. That is, there are shellbags artifacts for every entry in event A. The last interacted with 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 interacted with 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 interacted with (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 interacted with, 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 interacted with 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 interacted with 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.
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 MACE 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 interacted with 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 MACE 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 MACE 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
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
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:
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 MACE times of the three original, unzipped folders that I explored:
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 MACE time in the case of the "Quality" folder.
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:
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.
*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 MACE times of the three original, unzipped folders that I explored:
Fig. 11 - FTK Imager showing MACE 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 MACE 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 MACE 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 0x02 = class type indicator
Offset 0x32 = current folder
Offset 0x?? = full path up to current folderA
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 ...........
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.......
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.......
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.......
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 ........
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 ....
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 ..
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...........
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 ..
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 ..
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...........
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 ..........
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 interacted with (i.e. have shellbags entries) and only have one direct subfolder will not get updated.
- Not all shellbags parsers are created equal.
- MACE times contained within each shellbags entry will not update after a folder's first interation.
- When a folder that previously had not been interacted with is interacted with, the root BagMRU subkey's LastWrite time will get updated, causing direct child subkeys to report an updated MRU time.
- These tests show folder exploration (i.e. double-clicking into a folder). This is a common user action, but not the only instance in which shellbag artifacts are created/updated. The trigger is the folder SELECTION, not the exploration. Keep this in mind.
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.
-4n6k
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)
13 comments:
Well done!
Dan, this is an incredible post. Your depth of testing and documentation is a resource we can all draw on to improve our analyses and reporting. This post is definitive proof that Shellbags really is one of the most complicated registry artifacts that we rely upon. Thank you for sharing your work!
This post provide invaluable information. Great work!
A nuance here:
"these embedded times are pulled from the MFT (FILETIME format) and are translated into DOSDate time stamps" for the file entry shell item it seems they are obtained from the Windows structure WIN32_FIND_DATA using corresponding WINAPI functions not directly from the MFT.
Very interesting write up thanks for putting the effort into this. I'll have a look at your samples and test cases and see what I additionally can find especially regarding class type indicator 0x52.
Regarding Shell Item folder identifiers there is more to it, see:
https://code.google.com/p/libfwsi/wiki/ShellFolderIdentifiers
Excellent post, and incredibly thorough testing! Interestingly enough, as much work as you've clearly put into this, it's only the beginning. There are other aspects of the shellbag artifacts (embedded DOSDate times) that are misunderstood and misinterpreted, and this information needs to be expanded to other shell item artifacts, as well. This is an incredible start, a first step into the pool. Thanks for the work that you've done and thanks for sharing not just the data, but your findings as well.
Excellent work! Thanks for sharing.
Finally getting around to responding to some of these comments.
@David & @JayGee: Thanks!
@Chad: Thanks. Shellbags artifacts truly are a complicated beast. I'm glad that people are finding this useful and more fully understand what is being seen in tool output. Testing and documentation is a huge part of understanding how something like this works. You never really know what's happening behind the scenes until you take some time out to analyze a given artifact's behavior.
@Harlan: You're most definitely correct in saying that there is more work to be done. There are some things that I have not covered in this post that really deserve some exposure. Like you said, there's still a lot out there that is either 1) misinterpreted or 2) still unexplored. More research on the embedded DOSDate times and the MFT record references/seq numbers would serve well in the future. I have you, Chad, Joachim, Willi, and others to thank for the research that has already been shared prior to this post.
@Joachim: Thanks for pointing out these nuances. The great thing about making a post like this is that others, like yourself, will not balk at making corrections to things that may be unclear or flat-out inaccurate. This is extremely helpful for both me and others reading the article, so thank you. I'll be making edits to the original post that reference you comments.
Very good write-up. Has to be one of the best examples of testing that I have seen reported. Your statement "In the end, though, you can't blame a tool for an irresponsible investigator." should be drilled into the heads of all forensic examiners.
Than you 4n6k for interesting article and your time with explanations/examples. It was a nice read. Though, correct me if im wrong, but in such scenarios no one would be able to track what folder were opened/copied/removed if i would do this via command line. I'm not sure if there are any other ways to track if it is done via cmd but in your scenarios via shellbags i suppose it won;t work. Thanks!
@Anonymous: That is correct. Shellbags only applies to directory traversal using Windows Explorer. Command line traversal would not result in any shellbags artifacts.
What does this error message mean?
i.imgur.com/y7Qhy5S.png
@4n6k , thanks for your hardwork on the Shellbags explorer. However, I have been facing issue on the time zone setting, I have tried many versions and I also changed the desired time zone before process the registry, but it still showing +00:00 as time zone. Kindly advise and Many Thanks!
Post a Comment