Monday, August 20, 2012


I like good stuff, interesting stuff.  I particularly like stuff that gets me to thinking, and gets me to thinking specifically about validating my analysis process.

I ran across SetRegTime today, from Joakim Schicht.  Basically, Joakim started from the perspective that, from his view and his reading on the Internet, modification of Registry key LastWrite times to arbitrary values was "not possible".  So, he set out to turn this line of thinking around, achieved it, and released a proof-of-concept tool to demonstrate the capability.

In my courses, I have specifically stated that I was not aware of any open, public APIs (such as the GetFileTime()/SetFileTime() functions) that allow for arbitrary modification of Registry key LastWrite times.  Now, thanks to Joakim, we all are. 

I greatly applaud and appreciate Joakim's efforts in producing and releasing SetRegTime, as it:

1.  Identifies the public API and increased the possibility (albeit not the likelihood) of this occurring.
2.  Illustrates the need for an overall analysis process.
3.  Illustrates the need for a greater understanding of the Registry as an investigative resource.
4.  Illustrates more than ever the need for timeline analysis.

So, the big question for most analysts will likely be...okay, so what does this do to my examinations?  I'm sure that the thought will be that it throws an additional level of uncertainty into the exams, but I would suggest that if you have an analysis process, then this won't be the case at all.  With an analysis process, you will likely find indications of this sort of activity occurring, particularly if you are using timeline analysis. 

In addition, when performing malware analysis, you would want to look for the use of the APIs that Joakim mentions (i.e., NtCreateKey, NtOpenKey, NtSetInformationKey, NtFlushKey), as well as the use of the Windows internal names for the Registry.  Behavior analysis of the malware will likely illustrate this activity, as well.

So, if you're "poking around" in the Registry and find something interesting, and rely on that one artifact or finding as the foundation for your case, you're likely going to be building a house of cards.  However, if you have an overall analysis process that incorporates multiple data sources and multiple artifacts to support your conclusions, then you're likely going to pick up on the use of this sort of software, and be able to address it accordingly.

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

Saturday, August 11, 2012

RegRipper Updates

In an effort to consolidate some of the information regarding RegRipper in one consistent location, I started the RegRipper Google Code site.  My hope is that this will provide a much more stable means for folks to find information regarding RegRipper.

Now, my setting up this site does not take anything at all away from the RegRipper Plugin Google Code site that Brett Shavers set fact, these two sites will support each other.  The RegRipper plugin site will continue to be the location to get the plugin distributions, as this is something that folks are likely to do much more often, once they have the RegRipper suite of tools.  However, the point is to have just these two sites so that there is no confusion as to where you can go to get the latest and greatest information about RegRipper, or distribution of RegRipper plugins.

The RegRipper site will be one consolidated location where you can go to get information regarding RegRipper.  For example, I've started adding pages to the wiki, such as this one describing the plugin architecture.  The benefit of this is that the pages are right don't have to search the blog, or via Google, to find what you're looking for.  Also, this allows the information to be updated, but you won't have to search through my blog or some other resource for the will be in one location.

Speaking of plugins, Hal Pomeranz sent me two plugins recently...I took a look at them and forwarded them on to Brett, and you should be seeing them shortly on the plugin site.  Hats off to Hal for recognizing that something he saw could be put into a plugin, and for putting forth the time and effort to write the plugins, and share them with the rest of the community.

Also, I've uploaded two plugins to the RegRipper site.  One is, which basically was developed from the information available in this Mandiant blog post.  Thanks to the great work, and the code that they provided, I was able to put together a RegRipper plugin to parse this same information.

Note: If you're going to use this plugin, and not use the EXE versions of the RegRipper tools (i.e., you're using the Perl scripts), be sure to update your copy of the Parse::Win32Registry module.  The easiest way to do this, if you're using ActiveState Perl, is to use PPM:

C:\perl>ppm update parse-win32registry

The other plugin I uploaded is, which is in an archive with a readme file...puh-lease read that file if you have any questions at all about the plugin.  This plugin parses the Shell\BagMRU shell item information from the USRCLASS.DAT hives from Vista, Win2008R2, and Win7 systems.  I had only a limited amount of testing data available (thank you to all of you who sent me samples) when developing this plugin, and most of it was from Win7 systems.  I happened to find a couple of hives from Vista systems and one from a Win2008R2 system, so testing was extremely limited.  As such, it might have some hiccups on various data types, particularly ones I have not yet seen in testing.  If you run into any issues, contact me at the email address listed in the header of the plugin.

The output from this plugin is similar to what you see when you use TZWorks' sbag prototype utility.  One notable exception is that when printing the Registry key LastWrite times in the far left-hand column (I call it "MRU time"), I apply that time only to the first value identified in the MRUListEx value immediately beneath that key.  Many thanks to Dave and Jonathan for providing their excellent tool.

In developing the plugin, I had access to a great deal of useful information to get me started.  I've begun linking to most of that information on the ShellBags page in the RegRipper wiki, but I do want to thank Willi, Andrew, Joachim, and Kevin for their assistance in this endeavor.  Without the foundation that they'd provided, developing this plugin would have been much more difficult.  However, the effort put into developing the plugin doesn't end here...the data structures used in the values beneath these keys are also used in other place throughout Windows systems, and not just in the Registry.  However, this does mean that I'll be able to finally finish the plugin updates.

In developing both of these plugins, I found some fascinating information.  After all, I was working at the binary level, dumping bits of the data to a hex editor-style format, and looking for patterns.  For example, when looking at some of the output of the plugin during development stages, I found that the data within URI types contains an embedded time stamp...including this in a timeline, along side information from the NTUSER.DAT hive from the same user profile proved to be extremely illuminating.

Okay, so why would you care about viewing/analyzing this "shell bags" information?  As mentioned here (albeit four years ago...), this information can point you toward a user's access to external storage devices, including external drives, shares, and network resources.  I've seen that it can also include devices such as iPods and digital cameras.  Fifth Sentinel talks about these artifacts here, and Alissa Torres has talked a great deal about these artifacts at SANS events.  If your case involves determining a user's access to resources, this information can be extremely valuable, not only in and of itself, but also when included in or acting as a pivot or reference point during timeline analysis.  Combine this information with other data, including documents/files that the user accessed, removable devices connected to the system, Jump Lists, etc., and you can build a pretty interesting picture of user activity.  Another thing I really like about this artifact, as well as what's provided via the plugin is that the data persists well after the original resource is no longer available, and some of the data structures include embedded time stamps.

If you have any questions about the two plugins I uploaded, or about RegRipper in general, please feel free to contact me (keydet89 at yahoo dot com).