Not too long ago, I blogged about using the Parse::Win32Registry module to parse raw Registry files, specifically the SAM file.

Since then, I've added to the code a bit, so that not only does it retrieve user information, but group membership info, as well. In this way, it's similar to the ProDiscover ProScript I use to do the same thing, only SAMParse works on the raw Registry file, and can be used when exporting the SAM file from your image. It also works on the SAM files located in the Windows XP System Restore Points. It's a useful tool and requires some additional testing, but for the most part it does provide me with a view into a Windows system that I wouldn't otherwise have.

As a side note, I've also written a tool that parses the audit policy from the Security file, returning information similar to what you can view on a live system using auditpol.exe. When combined with other information from the Registry, this lets me know what I should expect to see in the Event Logs.

Both of these scripts, and others, are provided on the DVD that comes with my upcoming book, "Windows Forensic Analysis", due out from Syngress/Elsevier this spring. The scripts will be provided as Perl code, as well as standalone executables 'compiled' using Perl2Exe.

Last week, I mentioned making adaptations to a tool to perform specific tasks. Specifically, adapting the Offline Registry Parser so that instead of dumping all of the stuff in a Registry file, dump specific keys, values and their data, and translate that data into something human-readable (and parsable), rather than simply spewing it to STDOUT.

Where I thought this might be useful is with the SAM file, to start. Run through the file and pull out all of the user information, group membership info, and even the audit policy (translated into something similar to auditpol.exe's output). A side benefit of this is that you could run it against the current SAM file, as well as any located in System Restore points, and get a rough timeline of when changes occurred.

This could also be done for the NTUSER.DAT files.

Another benefit of this is data reduction. Rather than dumping the entire contents of the Software hive, you could extract only those keys, values, and data that you would most usually be interested. From there, you'd have less to analyze, and still have the original data.