This EnScript is designed 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, Windows 8.1 and Windows 10. The script does not support Windows XP.
Shellbags are used to store settings for folders that have been browsed by the user in the Windows GUI. Each 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.
Shell folders won't always be represented as a physical folder on disk. A good example of this might be a shell-folder representing control-panel categories or the results of a search.
Shellbag data is stored in the following Registry keys -
HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell (USRCLASS.DAT)
Both of the above keys will contain two sub-keys: Bags and BagMRU.
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 an example being the mode in which the contents of a folder were viewed, i.e. tiles, icons, details, etc., and the icon size (where relevant).
Slots are referenced by keys in the BagMRU hierarchy, which reflects 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.
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 script will produce up to five timestamps for each shell-folder. These will be displayed in the examiner's time-zone.
The first of the five timestamps is the Registry Created date. 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 date. 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. Note that Registry values do not have timestamps.
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.
When it comes to resolving the names of known folders (Documents, Pictures, Videos, etc.) the script uses an internal list, which it writes to a tab-delimited file called 'GUIDs.csv' in the same folder as the script. 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.
The script writes its output in the form of a tab-delimited spreadsheet and data bookmarks. Individual nodes within a data bookmark can be re-bookmarked and the individual bookmark columns shown or hidden as desired during that process.
There are a number of caveats that the examiner should be aware of when using this script.
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.
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 particularly useful when writing this EnScript.
YOU MAY ALSO LIKE