Now, my setting up this site does not take anything at all away from the RegRipper Plugin Google Code site that Brett Shavers set up...in 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 there...you 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 information...it 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 appcompatcache.pl, 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
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 shellbags.pl, 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 shellbags.pl 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 shellbags.pl 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 comdlg32.pl 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 shellbags.pl 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 appcompatcache.pl 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.
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 appcompatcache.pl 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).
1 comment:
Really cool. Putting together these plugins was not a trivial task and I can only image how much time and work was involved. Thank you for doing this. One of the biggest benfits for me is that now I can use one tool (RegRipper) to extract this registry information when before it used to require three different ones.
Post a Comment