Tools
Didier has released an updated version of an older viewer that he'd written, called InteractiveSieve.  Based on the description of the viewer, this looks like an excellent tool for performing timeline analysis.

Here's what I would do...may times, I will want to look at a particular date range, so I would run the parse.pl script to extract just that date range from my events file.  I would then open the resulting mini-timeline in Didier's viewer and go about deleting those things that I didn't want to see, and colorize things that might be important, or interesting but not specifically relevant without further investigation.

AppCompatCache
The folks over at Mandiant posted to the M-unition blog regarding the Application Compatibility Cache, which is maintained in the Registry (see their paper).  They've released a free tool to view this data, and in less than 30 minutes, I wrote up a RegRipper plugin to parse this data.  The first test data that I had available was 32-bit XP, so it's limited, but it's a start, and I think that it really shows the power of open source.  I don't say this to take anything away from the efforts of the Mandiant folks...rather, I thank them for their willingness to share the results of their research with the community at large.  I provided a copy of the plugin to the SANSForensics team, and gave them permission to post the code via the SANS Case Leads.  Rob contacted me with the test results, which weren't good.  It appears that the module I use has an issue, which I describe below in the "Troubleshooting" section.

Now, how is this information useful?  Check out Mandiant's paper...this particular data source is very rich in data, and I'll be updating the plugins once I get the module "fixed".

Open Source
I had posted to the Win4n6 Yahoo group some thoughts I had on the power of open source tools, with respect to the information Mandiant released.  The purpose of the post was not to say, "hey, look at me...I wrote another plugin!!", but rather to demonstrate the power and flexibility of open source tools, and how they can be quickly be extended to provide a capability that might take days or weeks for commercial applications.  Andrew provided another example, one that involved extending Volatility during Stuxnet analysis.  As someone who's done DFIR work for a long time, I really appreciate having the ability to decide what analysis I will do, rather than being penned in by a commercial tool or framework.

Troubleshooting
Okay, back to the information Mandiant provided regarding the Registry value...one of the members of the Win4n6 group (Ben) sent me a Windows 7 System hive...I have several, which I had opened in MiTeC's WRR and found the value in question to be all zeros...yet Mandiant's free tool pulled a great deal of data from the hive.  I checked again, and sure enough, the value in both ControlSets was all zeros.  So, based on a suggestion from Ben, I tried Yaru from TZWorks, and found all of the data.  I also wrote up a quick Perl script to extract the data from the value and place it into a file; from there, I opened up the file in a hex editor and could easily view the data.  It turns out that the issue is that Yaru is apparently the only tool of those I looked at that correctly handles 'db' node types within the Registry.  I have attempted to contact the author of the Parse::Win32Registry module about this, in hopes that it's an easy fix.

Registry Unallocated Space
Another interesting aspect of TZWorks' Yaru is that when you load the hive, it indexes the contents of the hive...and finds deleted keys.  Pretty cool!

I wanted to see how that compared to regslack, so I ran regslack against the same hive and got a bit different information; I got the same deleted key that Yaru found, plus one other, and I also got a LOT of unallocated space!  The web page for Yaru says that finding deleted keys is an experimental capability, which is great...it's also great that someone else is working on this topic.  Yolanta's work and release of regslack were a significant milestone for Registry analysis (here is one of my first blog posts on the topic).

The description of Yaru also states that you can view "cell slack", or unused "key value data space"...that's something else that might be very interesting to look into, although I'm not completely clear on what value there may be in data included in cell slack.

A while back, while I was involved in PCI forensic assessments, I used our documented process once I was back in the lab, and my scan for CCNs with an acquired image turned up hits within the Software and NTUSER.DAT hives on a system.  I thought that was odd...looking at the data surrounding the hits, it wasn't 100% clear to me that these were actual CCNs; that is, there were no indications that this was track data.  So I exported the hives and ran searches across the "live" Registry...and got nothing.  It turned out that the CCNs were part of unallocated space within the hive files...so understanding that there is unallocated space within a hive file can mean the difference between saying, "CCNs were found in the Registry", and actually providing accurate information in your report (as it can affect your customer).

Malware Persistence
The MMPC site has a description of Trojan:Win32/Reveton.A,which provides a good deal of information about this bit of ransomware.  Apparently, this baddie locks the infected system and displays a warning to the user that they've been reported to authorities as possessing illicit material.

Okay, so what is the persistence mechanism?  This one creates a Windows shortcut (LNK file) for itself in the Windows Startup folder.  Since the malware arrives as a DLL, it uses rundll32.exe to launch itself via the shortcut.

So what this gives us is some very good info to add to our malware detection checklist, doesn't it?  Not only should we check the Startup folders shortcuts (easy check; can accomplish this with a simple 'dir' command), but we might want to get some additional information via Prefetch analysis, particular of Prefetch files that start with "rundll32.exe".

"Community"
There's a new post up over on the Hexacorn blog, and comments are turned off, so I can't comment there...so let's do it here.  ;-)  Overall, let me say that I find most of the posts here interesting, and this one is no exception, but in this case, I'm only interested in four words from the post:

Like many before me...

I think that what a lot of us loose sight of is the fact that with few exceptions, there's probably someone out there who has faced the same challenges we've seen, and had to deal with the same...or at least very similar issues, as we have.  So, when faced with these challenges, we have options...we can seek help, or (if we're racing the clock to get stuff done) we can try to muddle through things and figure things out for ourselves.  I've heard people say this...that they want to wrestle with the issue and try to figure things out for themselves...even though there are others willing to help, or material and documentation available.  This is very noble, but think about it...is there any wonder why we don't see anything from them about what they learned later?  It's probably because they spent so much time wrestling that they don't have much time for anything else.

Recently, Girl, Unallocated gave an excellent DFIROnline presentation that involved a spoliation case and CCleaner.  Now, I've had an opportunity recently to work with the latest version of this tool...not in a forensic analysis capacity...so I'm a little familiar with it.  However, not long ago, I dealt with a case that involved an older version of WindowWasher.  So this shows that in a lot of ways, there are very few "new" cases; that is to say, it's likely that technology aside (XP vs. Win7, for example), there are very few, "This is what I need to determine..." cases.

Need to recover Event Log records (or MFT records) from unallocated space on an XP workstation or Win2003 server?  Perform USB device analysis?  Determine if that malware on the system actually executed?  I'm sure that someone else has run into this before...probably many "somebodys".

So, what to do?  Well, we can start by recognizing that if we have a road block, there's a way around it that someone else may already have found.  Ask for assistance.  It's also helpful that (a) the response not be taken "off list", and (b) that when the dust has settled, there's some final feedback or closure.

Remember, no one of us is as smart as all of us together.

To close this out, I recently had an event that made the issue of "community" clear to me.  Back in 2009, I'd written a script to parse Windows XP Scheduled Task/.job files (pull out the command run, the last time the job was run, and the status), and I have it is part of my personal stash of timeline tools.  In recent weeks, I had two different people ask me for a copy of the script, which I was somewhat hesitant to do because of my past experience with doing this sort of thing.  I decided to give the first person a chance and sent them the script.  I was notified that they received it, but getting feedback on how well it worked was like pulling hen's teeth.  So the second person came along, and I was just gonna say, "No, thanks" to their request...but they had a compelling need.  And they ran into an issue with the script...during testing, I'd never encountered a .job file that had been created but never run.  Now, I simply don't have any of those types of files available...but I asked Corey for some help, and thankfully, he was able to provide a couple of files.  All in all, the script is working very well, and providing not just some useful output, but it will also provide that output in TLN format.  Thanks to Corey providing some sample files, that meant I didn't need to go find an XP install disk, set up a VM, etc., etc., and was able to provide a solution much sooner.

Based on some comments I received from folks who reviewed WFA 2/e, I am strongly considering writing a book on Windows Registry Forensic Analysis...and I'll probably use that as the title! ;-)

I'm working on a proposal now, and one of the things I'm doing is including those things from previous books that have been successful...in particular, writing style, use of demonstrations, short case studies, and generally trying to show how this information can be used to further an investigation. My goal is to be a thorough as possible, providing information on format and structure, how to monitor the Registry, and provide as much information as I can with respect to keys and values that are (should be) of interest for examinations.

One of the issues I'm sure I'll run into is that same one I've run into with respect to WFA 2/e...there are folks out there who expect certain things to be in the book, but don't (a) realize that I can't do everything without assistance, or (b) don't voice that expectation until after the book is published.

So, here's your chance...if you were shopping for a book on Registry Analysis, what would you be looking for with respect to content?

I've already received emails from folks who say that they're looking for information on P2P applications, without saying which ones. There's already information available on a lot of topics such as P2P artifacts, and I understand that part of the problem is that this information isn't all in one place...but the way to make things like this a real success is to get input from folks in the community. As was discussed at the Summit last week, there really hasn't been a great number of requests for plugins or anything over at the RegRipper site...

First...you've GOT to see this. Tell me that the main character doesn't look surprisingly like Marcus Ranum.

Second, a huge shout out to JT for her work on regslack.pl, which is available in the Downloads section of RegRipper.net. I was running a search across an image recently for some important data, and surprisingly, I got several hits in Registry hive files; specifically, the Software hive, a couple of NTUSER.DAT files, and even in some UsrClass.dat files. This was odd, so I opened up a couple of the hive files in UltraEdit to view the guts of the hive files and didn't see any key value structure information anywhere near the entries. To be sure, I ran JT's regslack.pl against the hive files...I had done so previously to check for some of the hive files for deleted keys...and was able to verify that the sensitive data was, in fact, part of the unallocated space within the hive file and NOT part of any Registry structures. If you've ever found hits for your keywords within Registry hive files, you'll know that having this kind of definitive information can make a HUGE difference!

Rich over at HBGary showed me a neat trick for tracking down data in memory dumps. In this same engagement, I had collected a memory dump from a Windows 2003 system using Fast Dump Pro, and had used some of the same tools I use to search images for sensitive data on the memory dump...and found stuff. Well, the next step was to nail this down to a specific process. Unfortunately, within Responder Field Edition, you can export the executable image for the process but not the memory pages it uses. That's where Rich came to the rescue...he told me to right-click on the imported memory snapshot, choose View Binary from the context menu, and after the binary contents of the memory dump appeared in the right-hand view pane, click on the binoculars at in the menu bar above the memory dump and enter my search terms. I did this, and based on the output, was able to determine that the data I was searching for was not associated with a specific process. Interestingly, the strings associated with the process itself had not contained the information I was looking for (based on my search terms) and that served to corroborate my findings. Thanks to Rich with for his helping hand in showing me how to ring just a little bit more out of Responder!