Windows ShellBag Parser (sbag)
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::
- 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, and (c) whether to extract data from cell slack space (version 0.24+).
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. This is highlighted above. Starting with version 0.24, sbag can parse this slack space.
- 3. The Shell\BagMRU subkeys, while mainly containing folder metadata, can also contain file metadata, with complete MACB timestamps as well as size information. This is also highlighted above.
- 4. Starting with version 0.24, we decided to add some traceability to the output to show where the data was derived from. This is shown in the last column in the screenshot. 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.
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 sbag algorithm updates we internally perform regression testing as a normal course of action to verify the entries are valid. Likewise, it is highly recommended that any user of our tools do some sort of integrity validation to ensure the data reported is accurate. Below is a quick way of one way to verify the timestamps reported by sbag reflect the raw data.
One starts out by identifying where the source of an entry came from (shown as #1 in the diagram). This can be viewed in the last column of the sbag output. Next, one can use any registry viewer to extract the binary data from the appropriate cell value (shown as #2 in the diagram). For the example below we used yaru to extract and review the binary data. The timestamps embedded are DOS based (vice FILETIME based), and thus are four byte values. After locating the three DOS timestamps, one converts these timestamps into a readable form. Step #3 below shows a multipurpose utility we use to convert between various time formats, however, any trusted time-conversion tool that is available will suffice.
|32-bit Version||64-bit Version|
|Mac OS X:||sbag.v.0.29.osx.tar.gz||sbag.v.0.29.osx.tar.gz||md5/sha1|
|*32bit apps can run in a 64bit linux distribution if "ia32-libs" (and dependencies) are present.|