Parsing Windows ShellBags Using the ShellBags Parser EnScript
Digital Forensics | Mar 30, 2015
ShellBags are used to store settings for shell-folders that have been browsed by the user in the Windows GUI. Each shell-folder is seen by the operating system as an item in the Windows shell namespace, the path to which starts with the user's desktop.
|Figure 1 - Viewing the Windows shell namespace in Windows Explorer|
Shell-folders won't always be represented as a physical folder on disk. A good example of this might be a shell-folder representing a control-panel category or the results of a search.
ShellBag analysis can be useful from a forensic point of view because it can give a strong indication as to what shell-folders were accessed and when. This can be particularly useful when it comes to shell-folders that have since been deleted or those that were located on a removable disk.
ShellBag Data-Location & Manual Examination
Under versions of Microsoft Windows operating systems starting with Vista, ShellBag data is stored in the following Registry keys -
- HKCU\Software\Microsoft\Windows\Shell (USER.DAT)
- HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell (USRCLASS.DAT)
Both of the above keys will contain two sub-keys: Bags and BagMRU.
|Figure 2 - Viewing ShellBag Registry keys in the Windows Regedit application on the author’s computer|
The settings for each shell folder are stored in a sub-key of the Bags key. These sub-keys are called 'slots' and organized in a flat list. Each slot is identified by an index number and will contain a number of settings such as the mode in which the contents of a folder were viewed (tiles, icons, details, etc.), and the icon size (where relevant).
Slots are referenced by keys and associated values in the BagMRU hierarchy. These keys reflect the user's shell-namespace. Each key represents the contents of a shell-folder. It will contain a NodeSlot value, MRUListEx value, and a binary-value and sub-key for each child shell-folder. The NodeSlot value specifies the slot in which the associated shell-folder's settings are stored. The MRUListEx value is an array of 4-byte integer-values terminated by 0xffff. This array represents the order in which the child shell-folders were last accessed, most-recent first.
The structure of the binary-value representing each shell-item will depend on the nature of that item. In some cases it might be a physical folder on disk; in others it might be a network location, control-panel item, search folder, user library or known folder identified by a GUID.
The following screenshot shows a ShellBags binary-value for a folder named 48, which exists in the Pictures folder for a computer-user called Rebecca Howe. The ShellBag path to this value is Desktop\4\1\1.
|Figure 3 - Viewing a ShellBag Registry value relating to a folder named 48|
If we look in the folder that has the same name as the binary-value, we can see that it contains a NodeSlot value of 70 –
|Figure 4 – Viewing the NodeSlot value for the folder ‘48’|
If we take a look at slot 70 we can see that it contains a Shell sub-folder, which in turn contains a sub-folder named using a GUID. The latter contains Registry values representing the logical view mode (3, which represents icon view) and icon size (96) –
|Figure 5 – Viewing the LogicalViewMode and IconSize settings|
ShellBag Analysis Using the ShellBag Parser EnScript
The ShellBag Parser EnScript was designed to make it easy in EnCase® to parse ShellBag Registry data from NTUSER.DAT and USRCLASS.DAT Registry hive-files. The script has been tested with data from Windows Vista, Windows 7 and Windows 8.1. Please note that the script does not support Windows XP.
|Figure 6 – Running the ShellBags Parser EnScript|
The script produces two types of output: a data bookmark for each Registry hive, and a tab-delimited spreadsheet containing the ShellBag entries from all hives.
The contents of the data bookmark for the UsrClass.dat hive that we parsed manually appears as follows. Note the entry for the 48 folder that we parsed earlier -
|Figure 7 – Running the ShellBags Parser EnScript|
The LogicalViewMode and IconSize values match those we observed earlier albeit in a more readable way. The MRU Index column indicates the order in which the shell-folders were accessed with a value of zero representing the folder that was most recently accessed. EnCase® will display the folders in order (most recent first) provided that the columns haven’t been sorted.
The script will produce up to five timestamps for each shell-folder, the first being the Registry Created timestamp. This originates from the BagMRU Registry key associated with the folder and typically represents the time the folder was first accessed (browsed).
The second timestamp is the Registry Last-Accessed timestamp. This originates from the last-written date of the parent BagMRU Registry key and is only available for the child shell-folder that was most recently accessed. The logic behind this is that the MRUListEx value would have been updated when that folder was last-accessed, which would have in-turn updated the parent Registry key's last-written timestamp (Registry values do not have timestamps – those shown in EnCase® belong to the parent Registry key). In this case the 48 folder does not have a Registry Last-Accessed timestamp because the sibling 2010-08-18 Antigua folder was the last folder to be accessed.
The Target Created, Target Last-Accessed and Target Last-Modified timestamps are self-explanatory. They originate from a block of data to be found in certain shell-item Registry streams that refer to physical folders. This block will also contain the MFT record and sequence numbers of folders located on NTFS volumes.
It’s worth noting that the timestamps for the target folder are stored in DOS GMT format, which has a two-second granularity. The timestamps themselves may not always be up-to-date; we can see an example of this if we take a look at the 48 folder itself.
|Figure 8 – Viewing metadata for the 48 folder|
The above screenshot confirms that the target folder’s MFT record and sequence number match those decoded from the ShellBags entry. The created timestamp is out by two seconds because of the DOS-timestamp granularity issue. The last-accessed and last-written/modified timestamps are not up-to-date, which is not always a bad thing - outdated timestamps can corroborate the time that other significant events took place on the system.
Having examined the bookmarks created by the script, the contents of the spreadsheet are straightforward and don’t really require any further elaboration.
|Figure 9 – Viewing the output spreadsheet (additional formatting has been applied)|
Resolving Known Folder GUIDs
When it comes to resolving the names of known folders (Documents, Pictures, Videos, etc.) the ShellBags Parser EnScript uses an internal list, which it writes to a tab-delimited file called GUIDs.csv in the same folder as the script.
|Figure 10 – Viewing the GUIDs.csv file as text|
Once extracted, the script will read the contents of this file the next time it runs. The examiner can modify the contents of this so as to add new GUIDs as and when they are encountered.
There are a number of caveats that the examiner should be aware of when using the ShellBags Parser EnScript.
First and most importantly, not everything is known about the shell-item structures stored in BagMRU entries and the operation of ShellBags in general. The script will do its best to parse these structures accurately but may encounter some that it can't parse at all and others that it won't interpret correctly. The examiner should never treat the findings of the script as the 'be all and end all' of everything and seek further corroboration whenever necessary. The author would appreciate being informed should the script be found to produce erroneous, incomplete or inaccurate data.
Secondly, the script does not currently support the recovery of deleted ShellBag data. Other tools are available that support this functionality.
The author wishes to acknowledge the excellent work and information made available by Joachim Metz, Chad Tilbury, Dan Pullega, Eric Zimmerman, and Nicole Ibrahim. Eric Zimmerman's ShellBags Explorer utility was a particularly valuable resource when it came to writing this EnScript.
Simon Key email@example.com
Course Developer III