SANS Forensic Summit

As the SANS Forensic Summit draws nigh, I've been preparing the demos for my presentation, Secrets of Registry Analysis Revealed. In addition to this presentation, I'll will also be participating in some panels. I've seen the current program, and there's even a panel on volatile data, which I think is very topical and very much needed. Also, Richard Bejtlich will be giving the keynote speech on the second day.

Part of my presentation will include demos (yes, Rob told me I can't just talk the whole time...) of RegRipper and rip.exe (CLI version of RegRipper), as well as a new tool I call ripXP. Before I say anything else about this, I have to say that ripXP was an idea that Rob had several months ago...he told me something like, "hey, wouldn't it be cool if you wrote a tool like RegRipper, only it would also run the plugin against the hive files in the XP Restore Points?" So, in my copious amounts of free time (HTML really needs a sarcasm or smart-@$$ tag), I put together ripXP.

Okay, so what IS ripXP? RipXP is similar to rip.exe, in that it is a CLI tool and that it uses the same plugins as RegRipper and rip.exe. You give ripXP (as command line arguments) the hive file, the directory where the Restore Points reside (more on that later), and a plugin to run. Once you have all this, ripXP will then:

-> Access the hive file and guess what kind (SAM, System, NTUSER.DAT, Software, or Security) hive file it is (if it's an NTUSER.DAT file, it will attempt to retrieve the user's SID

-> Compare the type of hive file to the hive file that the plugin was written for; that is, if you pass it a System hive file, it won't let you run a plugin meant for an NTUSER.DAT file (just like rip.exe, ripXP includes the "-l" option so you can list all available plugins)

-> Run the plugin against the hive file you selected

-> Access the System Restore RP directories, and run the plugin against the appropriate hive

All this happens automatically, and the output goes to STDOUT, so all you have to do is redirect the output to a file.

Oh, yeah...when ripXP accesses an RP directory, it also displays the Description, Type, and Creation Date of the Restore Point.

Okay, so besides being totally, AWESOMELY, AMAZINGLY cool...so what? Well, for the demos, I'm using Lance Mueller's practical images, so the number of RP directories is limited. However, in a real examination, a tool like this would allow you to see a historical progression of data. I've used only a couple of the plugins in my testing thus far, such as userassist, acmru, and a couple of others. But look at the MountedDevices key, or any of the MRU listings in the NTUSER.DAT file...this would allow you to see a historical progression over time of how the data changed.

Also, consider a Restore Point created one day, and then the following day, some data within that key was deleted by the user. Those historical artifacts would still exist in the hive files in the Restore Points, and would not only be accessible, but would also be visible sequentially.

Finally, like rip.exe, ripXP can be deployed within a batch file, and you could even create/use a Perl script to create that batch file, based on a standard methodology. Oh, yeah...the RP directories. So, you have an image...raw dd, split raw dd, EWF, whatever. What I did was open the image file in FTK Imager and export the RP directories to another location; in my case, D:\test\XP1. Then, because I wanted to use them easily and repeatedly, I burned them to CD, so I now access them as E:\XP1\RP1, RP2, RP3, etc. What I need to do is test them for use with SmartMount, and other tools like it. Yes, this will make the command line a bit longer, but it should work just fine. (Addendum: Testing using a mounted image is complete and extremely successful!)

Anyway, this will be one of my demos. If you're going to be at the Summit, be sure to stop by when we talk about Registry analysis.