Wednesday, August 15, 2012

ShellBag Analysis

What are "shellbags"?
To get an understanding of what "shellbags" are, I'd suggest that you start by reading Chad Tilbury's excellent SANS Forensic blog post on the topic.  I'm not going to try to steal Chad's thunder...he does a great job of explaining what these artifacts are, so there's really no sense in rehashing everything.

Discussion of this topic goes back well before Chad's post, with this DFRWS 2009 paper.  Before that, John McCash talked about ShellBag Registry Forensics on the SANS Forensics blog.  Even Microsoft mentions the keys in question in KB 813711

Without going into a lot of detail, a user's shell window preferences are maintained in the Registry, and the hive and keys being used to record these preferences will depend upon the version of the Windows operating system.  Microsoft wants the user to have a great experience while using the operating system and applications, right?  If a user opens up a window on the Desktop and repositions and resizes that window, how annoying would it be to shut the system down, and have to come back the next day and have to do it all over again?  Because this information is recorded in the Registry, it is available to analysts who can parse and interpret the data. As such, "ShellBags" is sort of a colloquial term used to refer to a specific area of Registry analysis.

Tools such as Registry Decoder, TZWorks sbag, and RegRipper are capable of decoding and presenting the information available in the ShellBags.

How can ShellBags help an investigation?
I think that one of the biggest issues with ShellBags analysis is that, much like other lines of analysis that involve the Windows Registry, they're poorly understood, and as such, underutilized.  Artifacts like the ShellBags can be very beneficial to an examiner, depending upon the type of examination they're conducting.  Much like the analysis of other Windows artifacts, ShellBags can demonstrate a user's access to resources, often well after that resource is no longer available.  ShellBag analysis can demonstrate access to folders, files, external storage devices, and network resources.  Under the appropriate conditions, the user's access to these resources will be recorded and persist well after the accessed resource has been deleted, or is no longer accessible via the system.

If an organization has an acceptable use policy, ShellBags data may demonstrate violations of that policy, by illustrating access to file paths with questionable names, such as what may be available via a thumb drive or DVD.  Or, it may be a violation of acceptable use policies to access another employee's computer without their consent, such as:

Desktop\My Network Places\user-PC\\\user-PC\Users

...or to access other systems, such as:

Desktop\My Network Places\\\\\c$

Further, because of how .zip files are handled by default on Windows systems, ShellBag analysis can illustrate that a user not only had a zipped archive on their system, but that they opened it and viewed subfolders within the archive.

This is what it looks like when I accessed Zip file subfolders on my system:


Access to devices will also be recorded in these Registry keys, including access to specific resources on those devices.

For example, from the ShellBags data available on my own system I was able to see where I'd accessed an Android system:

Desktop\My Computer\F:\Android\data well as a digital camera...

Desktop\My Computer\Canon EOS DIGITAL REBEL XTi\CF\DCIM\334CANON

...and an iPod.

Desktop\My Computer\Harlan s iPod\Internal Storage\DCIM

Another aspect of ShellBags analysis that can be valuable to an examination is by the analyst developing an understanding the actual data structures, referred to as "shell item ID lists", used within the ShellBag.  It turns out that these data structures are not only used in other values within the Registry, but they're also used in other artifacts, such as Windows shortcut/LNK files, as well as within Jump List files.  Understanding and being able to recognize and parse these structures lets an analyst get the most out of the available data.

Locating Possible Data Exfil/Infil Paths via ShellBags
As information regarding access to removable storage devices and network resources can be recorded in the ShellBags, this data may be used to demonstrate infiltration/infection or data exfiltration paths.

For example, one means of getting data off of a system is via FTP.  Many Windows users aren't aware that Windows has a command line FTP client, although some are; in my experience, it's more often intruders who are conversant in the use of the command line client.  One way that analysts look for the use of the FTP client (i.e., ftp.exe) is via Prefetch files, as well as via the MUICache Registry key.

However, another way to access FTP on a Windows system is via the Windows Explorer shell itself.  I've worked with a couple of organizations that used FTP for large file transfers and had us use this process rather than use the command line client.   A couple of sites provide simple instructions regarding how to use FTP via Windows Explorer:

HostGator: Using FTP via Windows Explorer

Here's what a URI entry looks like when parsed (obfuscated, of course):


One of the data types recorded within the ShellBags keys is a "URI", and this data structure includes an embedded time stamp, as well as the protocol (ie, ftp, http, etc.) used in the communications.  The embedded time stamp appears (via timeline analysis) to correlate with when the attempt was made to connect to the FTP site.  If the connection is successful, you will likely find a corresponding entry for the site in the NTUSER.DAT hive, in the path:


Much like access via the keyboard, remote access to the system that provides shell-based control, such as via RDP, will often facilitate the use of other graphical tools, including the use of the Windows Explorer shell for off-system communications.  ShellBag analysis may lead to some very interesting findings, not only with respect to what a user may have done, but also other resources an intruder may have accessed.

Like other Windows artifacts, ShellBags persist well after the accessed resources are no longer available.  Knowing how to parse and interpret this Registry data

Parsing ShellBags data can provide you with indications of access to external resources, potentially providing indications of one avenue of off-system communications.  If the concern is data infiltration ("how did that get here?"), you may find indications of access to an external resource, followed by indications of access to Zip file subfolders.  ShellBags can be used to demonstrate access to resources where no other indications are available (because they weren't recorded some where else, or because they were intentionally deleted), or they can be used in conjunction with other resources to build a stronger case.  Incorporation of ShellBag data into timelines for analysis can also provide some very valuable insight that might not otherwise be available to the analyst.

ForensicsWiki Shell Item page


Yogesh Khatri said...

Its most useful feature is getting details about accessed files/folders on networks \\xx.xx.xx.xx\C$\...
and removable drives

On the analysis side, one area where I haven't seen any research is the possible usefullness of the multiple timestamps in each entry. There is a timestamp for every folder leading up to the file. I believe there may be some useful insight gained by gathering all such timestamps for a single folder and comparing them.


H. Carvey said...


I'd love to hear your thoughts on this. I'm sure that the analysis could also be used across multiple LNK files in a similar fashion, particularly those that are in the same path.


Happy Monkey said...

One of my favourite uses for shellbags is to show the contents of encrypted volumes to which we don't have access. Being able to see the last-accessed times and matching the drive letter up with a mounted Truecrypt volume from elsewhere in the registry has provided some extremely compelling evidence on a number of occasions.

There's a handy tool called Windows Registry Analyzer floating around that does a pretty HTML report of shellbags. It was bought up by Paraben and withdrawn from the author's site, but if you can get hold of it it's another useful tool in the armoury.

Saad Kadhi said...

Thank you for this excellent blog post Harlan.

When I incorporated Windows Shellbags into my forensics routine sometime ago, this helped quite a lot and even confirmed some hypothesis that were made about "cold cases". On the tool side, I exclusively use TZWorks Shellbag Parser (sbag) which have worked reliably for me so far.


H. Carvey said...


Thanks for the comment.

I didn't write my own plugin in order to be different...I did so in order to better understand the nature of the structures, and in doing so I found out that there can be considerably more information available than what is provided by most tools.

Also, this allows me to rewrite the output of the plugin in order to more easily add it to a timeline, which has been extremely valuable just in the few times I've done that so far...

Ethan Fleisher said...

Despite the fact that I'm commenting a bit late on this, I read this post again today before starting to do some Windows 8 research into shellbags.

I am mainly commenting towards Saad,

On the tool side, I exclusively use TZWorks Shellbag Parser (sbag) which have worked reliably for me so far.

Although it has been extremely reliable, and maybe to date you have changed your technique, it never hurts to run pertinent items like Shellbags against multiple tools to validate the results. One scripts output may be incorrect, afterall.


A small side note, but your second summary sentence seems to be incomplete. Not a big concern considering, just thought I'd point it out since I noticed!

H. Carvey said...


First, thanks for the comment.

To Saad's comment, I just verified today that sbag64 v0.30 still misses some types of shell items, and when it hits those, it doesn't traverse the tree.

...never hurts to run pertinent items like Shellbags against multiple tools to validate the results..

I have a bit of an issue with using one tool to validate another...what if both are wrong, in the same way? What if both miss things, but different things?

I think that this form of tool validation is a myth-odology, one of those myths of DFIR work that is passed down so many times that it's assumed to be true...

Thanks again!