Forensic Analysis of Windows Shellbags
This is the fifth and final blog post in a series about recovering Business Applications & OS Artifacts for your digital forensics investigations.
What are Shellbags?
While shellbags have been available since Windows XP, they have only recently become a popular artifact as examiners are beginning to realize their potential value to an investigation. In a nutshell, shellbags help track views, sizes and positions of a folder window when viewed through Windows Explorer; this includes network folders and removable devices.
Why are Shellbags Important to Digital Forensics Investigations?
One might ask why the position, view, or size of a given folder window is important to forensic investigators. While these properties might not be overly valuable to an investigation, Windows creates a number of additional artifacts when storing these properties in the registry, giving the investigator great insight into the folder, browsing history of a suspect, as well as details for any folder that might no longer exist on a system (due to deletion, or being located on a removable device).
The Key Artifacts That Need to be Found When Investigating Shellbags
For Windows XP, shellbag artifacts are located in the NTUSER.dat registry hive at the following locations:
- HKCU SoftwareMicrosoftWindowsShell
- HKCUSoftwareMicrosoftWindowsShellNoRoam
For Windows 7 and later, shellbags are also found in the UsrClass.dat hive:
- HKCRLocal SettingsSoftwareMicrosoftWindowsShellBags
- HKCRLocal SettingsSoftwareMicrosoftWindowsShellBagMRU
The shellbags are structured in the BagMRU key in a similar format to the hierarchy to which they are accessed through Windows Explorer with each numbered folder representing a parent or child folder of the one previous. Within each of those folders are the MRUListEx, NodeSlot, and NodeSlots keys:
- MRUListEx contains a 4-byte value indicating the order in which each child folder under the BagMRU hierarchy was last accessed. For example if a given folder has three child folders labelled 0, 1, and 2 and folder 2 was the most recently accessed, the MRUListEx will list folder 2 first followed by the correct order of access for folders 0 and 1
- NodeSlot value corresponds to the Bags key and the particular view setting that is stored there for that folder. Combining the data from both locations, investigators are able to piece together a number of details around a given folder and how it was viewed by the user
- NodeSlots is only found in the root BagMRU subkey and gets updated whenever a new shellbag is created
Below is an output from the Windows Registry Editor showing shellbag data for a particular folder (My Computer:E:IEF – 64 – FOR508) as well as a number of additional folders stored under the user’s mounted E volume:
We can see that much of this data is stored in a raw hex format and needs to be formatted to understand the path and any additional details. You will need to collect data from each value in the hierarchy to piece together the path of the folder and then use data found in the Bags key to find additional details on the icons, position, and timestamp details.
Making Shellbag Analysis Easier With IEF
IEF can now take the above details from the NTUSER.dat and UsrClass.dat hives and organize the results into an easy to read and interpret format for investigators. This will help examiners understand what folders were browsed on a system through the Windows Explorer including any folders that might have been previously deleted or found on remote systems or storage:
- The path of the folder being analyzed
- The last write time of the BagMRU registry key
- The last write time of the Bags registry key
Additionally, shellbags provide the investigator with timestamp details including the last accessed times of the folders being examined, allowing investigators to potentially find out the last time a suspect viewed a particular folder. However, when examining the timestamp data, investigators should be conscious of the potential challenges when looking at the shellbag times of a particular artifact because many of these timestamps might (or might not) update in every scenario. Dan Pullega has done some excellent testing and analysis on these timestamps, and any investigator wishing to include this data in their analysis should read his work.
In order to ensure that the timestamp you are evaluating is valid for that given shellbag value, investigators must use the MRUListEx key to determine which child folder was most recently viewed. Currently IEF version 6.4.1 does not report the MRUListEx value for shellbags so the investigator must verify this with the registry manually, however, we will be adding this feature soon.
Adding shellbags to your analysis will help build a timeline of events, as a user might have traversed through a system going from folder to folder. It may also help refute claims that a suspect might not have known certain files or pictures were present on a system. While proper shellbag analysis can be challenging, the data included in the artifacts can be vital to investigations to determine what a user was doing on a system during a given incident.
As always, feel free to get in touch with me by emailing jamie.mcquaid@magnetforensics.com. Or, you can ask me a question here.
Related resources you might be interested in:
- Read other blogs we’ve written on Business Apps & OS Artifacts: Visit Our Resources Center
- See what IEF is all about: Attend a Demo
- Try IEF for Free:
- New to IEF: Request a 30 day trial
- Current customers: Request a 30 day trial of our Business Applications & OS Artifacts Module
Jamie McQuaid
Forensics Consultant, Magnet Forensics