Mo' Stuff

Man, there is just so much stuff sometimes, that it takes several posts to get it all in...

Perhaps one of the biggest things to come through my inbox lately has been that F-Response now has a scripting interface! That's right! According to Matt:

The F-Response Enterprise installation package now includes a partial implementation of the F-Response Enterprise Management Console in a language neutral fully scriptable COM object. This object will allow a technical user of F-Response Enterprise to script actions typically initiated manually in the FEMC.

Sweet! What this technical jargon amounts to is that F-Response EE can now be scripted through Perl! Imagine automating collection of system names from the network, pushing out F-Response EE, collecting information, disconnecting and moving on to the next system!

Here's an analysis tip that I picked up based on a question posted to one of the forums...when posting a question about time stamp oddities (in particular) on Windows systems, it helps to specify which version of Windows you're working with. For example, if you have a last modified date that is three days after the last accessed date on a file, and the system is Vista, then you may have encountered an artifact that has to do with the fact that by default, Vista does not update last access times on files. If the system is XP or Win2K3, you may want to check the NtfsDisableLastAccessUpdate value. Even variations within the same version of Windows (XP Professional vs. Home) can be important...and yes, you can use RegRipper to get this information for you.

Lee posted an excellent write-up regarding issues of MSOffice document metadata, along with an interesting example that many of us have likely run across. This is an issue that's been around for some time, and even though MS's updated the application itself, this is still something that can be very important during an examination, as Chris found out recently.

Are you tired of using RegRipper? Mark Woan has created RegExtract, which according to Mark, is based completely on RegRipper, and implements most of the plugins that are currently publicly available (I currently have 118, a few of which are proof-of-concept and for testing purposes only...) with RegRipper. I downloaded and installed RegExtract and took a look at it. It requires .NET 3.5, and it only runs on Windows (unless you can get .NET 3.5 installed on wine), but if you need a better looking UI and perhaps slightly faster processing, you should take a look at this. A couple of things I found with RegExtract is that while it can run all plugins designed for the NTUSER.DAT hive (or any other hive type) against that hive file, it doesn't appear to be able to automagically determine the hive type, or allow you to run only specific plugins in a predetermined order against the hive file. The results of the plugins are sent to a text field in the UI, and the user doesn't appear to have the ability...at least not obviously...to save the results to a file, for inclusion in a report (directly into the report, or an appendix). You can, however, select what you want from the text field, copy it to the Clipboard, and then paste it into a report or text file.

Finally, something else to consider...the plugins are compiled DLLs, and are not open. RegRipper's plugins are essentially text files that can be opened in Notepad or an editor of your choice (much like Nessus's plugins), so if you ever have any questions about what the plugin does or why it doesn't work, you can just open the plugin up and have a look-see.

Speaking of RegRipper, Rob posted the results of his updated research on USB devices to the SANS Forensic blog yesterday. This is an excellent bit of work that Rob's done and really taken the original work that Cory and I did oh, lo those many years ago to new levels. Drop by and check out the handouts Rob's put together. Based on an IM exchange with Rob, I've updated mountdev.pl a bit to pull out the sector offset information for the partitions, so that there's less confusion when you see two volumes or drive letters with the same disk signature or MBR disk identity (they're the same thing...the 4 bytes found at offset 0x01B8). The plugin now returns the same information seen when you open the image in FTK Imager and look at the start sector for the partition. With this new information, I need to clean up the plugin a bit to make the output a bit easier to understand.

Finally, Matthieu's been busy, it seems, working away on win32dd (now referred to as "windd") and looking for beta testers (ignore the "2008" in the changelog info...it's 2009). Take a look!