Windows ShellBag Parser (sbag)

Introduction

sbag is a Windows registry parser that targets the Shellbag subkeys to pull useful directory and file artifacts to help identify user activity. There are binaries available for Windows, Linux and Mac OS-X. The Windows version allows one to parse hives resident from a live system.

As background, the ShellBag information is a set of subkeys in a user registry hive (eg. ntuser.dat and usrclass.dat files) used by the Windows operating system to track user window viewing preferences. It does this by storing various Windows Explorer settings that relates to dimensions, settings, etc. This allows one to reopen the same folder at a later time with the settings from the previous time. Each user will have separate preferences for folders, and therefore, these settings are stored in the appropriate user hive.

Since the ShellBag subkeys store various metadata on how Windows Explorer items were arranged, and since they are recorded for each user, from a computer forensics standpoint, one can parse the data and pull out various pieces of information that relate to user interaction. When combined with other available computer artifacts, it could provide a more complete picture of what files were accessed or deleted by the user and from what storage device they were accessing (could be either an internal, external or network storage device). The 'ShellNoRoam\BagXxx' key(s) has data for local folders and the 'Shell\BagXxx' key(s) has data for the remote folders.

The registry subkeys that sbag evaluates include the following::

• NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
• NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags
• NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam\BagMRU
• NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam\Bags
• UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
• UsrClass.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags
• UsrClass.DAT\Local Settings\Software\Microsoft\Windows\ShellNoRoam\BagMRU
• UsrClass.DAT\Local Settings\Software\Microsoft\Windows\ShellNoRoam\Bags

On Vista and Windows 7, the UsrClass hive is new and is located in the C:\Users\<user>\AppData\Local\Microsoft\Windows directory.

How to use sbag

sbag is a console application, and thus, to use this tool on a live system, one will need to open the command prompt with administrator privileges first. One can display the menu options by typing in the executable name with no parameters. A screen shot of the menu is shown below.

While the menu shows a number of different options, the only required parameter to pass in is the user hive one wishes to extract shellbag artifacts from. The available options include: (a) annotating username and/or hostname to the output (version 0.23+), (b) specifying what type of format one wishes to put the output data in, (c) whether to extract data from cell slack space (version 0.24+), and (d) miscellaneous and date/time format options (version 0.29+).

The output options include: (a) the default output, where each record is on a separate line and each field is separated by the pipe character, (b) the SleuthKit body-file format and (c) the log2timeline CSV (comma separated value) format.

Below is an example syntax of parsing a user hive in an off-line manner. For this example, it assumes a user hive was extracted to the c:\dump directory beforehand. To parse the hive, one could then invoke the following command:

         sbag c:\dump\ntuser.dat > results.txt

Since the output that is generated is very wide, it is recommended that one redirect the output of the command into a results file as show above. Then it can be reviewed in any text editor by turning off the word wrap option to see each record on a separate line. If one wants to take advantage of the Comma Separate Value (CSV) format that is easily opened with any spreadsheet application, one could use the –csv option, like below:

         sbag c:\dump\ntuser.dat -csv > results.csv

The only difference in the results between the normal output and the CSV output is the CSV processed output is checked for any occurrences of commas. If any commas are found, they are changed into semicolons so as to not disrupt the CSV format for separating the fields. Thus, if one needs exact data without any possible modifications, one should choose the normal (default) output. The normal (default) output uses the pipe character '|' for a delimiter which does not conflict with any valid Windows filename syntax.

For processing shellbag artifacts on a live system, one can use the –livehives option to enumerate the available hives that sbag can process. Below is an example, with associated output, one can get when invoking this command.

Once the path of the location of the user hives are known, one can parse any of the desired hives by passing in the path of the active hive. For this type of live processing, sbag will take care of taking a snapshot of the requested hive by reading the appropriate raw NTFS clusters and then proceed to extract the artifacts from the snapshot.

Results of the Parsing

In previous versions of sbag (prior to version 0.24), the BagMRU and Bags datasets were separated into independent outputs. Since the BagMRU data primarily represents the folders (or directories) of the files and the Bags dataset primarily represents the files in the folders, it made sense to integrate like BagMRU\Bags datasets into one output. So, starting in version 0.24, this is now the baseline output. It happens, however, that multiple datasets can still be displayed, one for the Shell\[BagMRU | Bags] dataset and one for the ShellNoRoam\[BagMRU | Bags] dataset.

Below is an annotated example of sbag's output rendered on a spreadsheet. The artifacts are extracted from an ntuser.dat file from a Windows 7 box. Each of the command line switches used in the example are explained in the readme file that is included as part of the download. Finally, all the timestamp information was truncated to highlight some of the other fields, and more specifically, some interesting items.

       Example: sbag c:\dump\ntuser.dat –base10 –inc_slack –csv > results.csv

Below are some observations one should note from the above snapshot:

• 1. One see that the value name Shell\Bags\<bag#>\Desktop\ ItemPos<screen resolution> contains the metadata associated with files that were part of the Desktop. However, not shown in the above snapshot, but based on empirical data, it can also contain metadata about folder data as well.
• 2. Since the ItemPosXxx registry value is a large blob of binary data, there are cases where there is sufficient cell slack space to pull out additional artifacts.
• 3. The Shell\BagMRU subkeys, while mainly containing folder metadata, can also contain file metadata, with complete MACB timestamps as well as size information.
• 4. The last column in the screenshot above shows where the data was derived from. As it happens, some of the folder/file data 'appears' to be redundant, so this last column adds more confidence to the results presented so as to identify the origins of the data. This more easily allows one to 'hand' parse the data to verify any of the results generated. We, in fact, use it to help verify our results as we make changes to the baseline software.
• 5.ShellBag data may contain an inode (MFT entry) and MFT sequence number to reference the target entry. One can use this inode/sequence number pair to help find the target entry, and if found, will yield additional metadata for the examiner.

sbag shows other data in the output as well. To highlight some of these other fields, we broke up the output with another example. This data was take from parsing a UsrClass.dat hive provided by Rob Lee which he uses as an exemplar in his SANS 408 Forensics classes.

The output fields we focus on in this example are the registry key timestamps for the parent BagMRU entries and the indicator to the right of these times to display which BagMRU entry is the last one associated with the registry time. This is known as the MRU (for Most Recently Used) entry.

Also shown in this example are Bag timestamps that are related to each BagMRU entry. Since each BagMRU points to a Bag entry, it is useful to these Bag timestamps to also correlate MRU times for those BagMRU entries that don't have one. This give one some additional data to help understand when a BagMRU entry was last updated. One should note, in some cases, sbag reports more than one Bag timestamp (as shown below). The reason for this is sbag extracts all the registry subkey timestamps for the parent Bag entry to identify the times this Bag entry (and thus related to the BagMRU entry) was updated as opposed to only the main one.

Finally, there is one last field that is of interest and can provide additional insight when populated. It is the metadata field. It is expanded from the previous example and three entries are highlighed to point out how much data portable devices can store in ShellBag entries. From this particular example, one can see the vendor and product identifier of the portable device, along with a serial number, security identifier, etc. All this is useful information from an investigator's perspective.

The case of the deleted shellbag entries

Occasionally sbag will come across entries in the shell bag hierarchy that are missing. This most likely occurs by deleting certain entries and leaving others. Empirical data suggests that the operating system does not do this. So when this occurs, it was most likely intentionally done with anti-forensics in mind. When considering these types of cases, there are two possibilities: (a) those that have subkeys that are deleted and (b) those that have values that are deleted. The graphic below shows both of these cases.

When a subkey is deleted, the rest of the entries are deleted as well. For recovery, one needs to rely on reconstructing the deleted subkeys from the registry unallocated hive space. While yaru can do this, sbag currently does not automatically do this. The second example is when one of the values is deleted. In this case, sbag can reconstruct most of the path while marking the deleted value in the path accordingly. Below is an example of the output for this second case:

Cell Slack Artifacts in Bags ItemPos Data

For cases where there is sufficient slack space available in the registry cell value data, sbag will try to parse this data into some intelligible output. Since this option is still experiment, it has been added as a separate option one can invoke. This allows one to isolate the option should it exhibit any instability, until sufficient testing has been done. To use this option use the –inc_slack switch.

For those wishing to analyze cell slack space in a hex dump view, one can use our yaru utility. Just navigate to a similar registry value that is shown below, and scroll to the end of the data output. If there is any slack space, it will be displayed at the end. The results of processing the slack space below was shown in the in the screenshot displayed above.

For more information

The user's guide can be viewed here

If you would like more information about sbag, contact us via email.

Downloads