Scripts for parsing the Registry

I was working on a script recently to expand the reach of the Registry Analysis material in my upcoming book, and I thought it would be a good idea to implement something that would parse the audit policy from a system. So I wrote poladt.pl, a Perl script that uses the Parse::Win32Registry module to extract the necessary value from the raw Security file and parse it, displaying the audit policy as shown below:

G:\perl>poladt.pl d:\cases\security
LastWrite: Fri Sep 9 01:11:43 2005 (UTC)
Auditing was enabled.
There are 9 audit categories.

Privilege Use..............None
Object Access..............None
Account Logon Events.......Both
System Events..............Both
Policy Change..............Both
Logon Events...............Both
Account Management.........Both
Directory Service Access...None
Process Tracking...........None

Note: I added the little dots so that the output would line up better and be easier to read; formatting in the blog is a little beyond my current skillset.

Pretty neat, eh? You can compare this to the contents of the Event Logs (I still use the File::ReadEvt module that I wrote to do this, as the Event Viewer still reports the files as corrupted sometimes when you extract them from an image and try to import them into the Event Viewer on your analysis system). If I get any information about other values to parse out of the raw Security file, I'll add that to a script and call it "SECParse".

This script is will be found in the Bonus section of the DVD that comes with my book. Look for Windows Forensic Analysis from Syngress later this spring.

EventLog Analysis

In my book, I covered the Windows 2000, XP, and 2003 EventLog file header and event record structure in some detail. There's also a Perl script or two on the DVD that accompanies the book that let you parse an Event Log without using the Windows API, so that you avoid that pesky message about the Event Log being corrupted.

I've since updated one of the scripts (changing the name to evt2xls.pl), so that now it writes the information that it parses from the Event Log file directly into an Excel spreadsheet, even going so far as to format the date field to that it "makes sense" to Excel when you want to sort based on the date. I've found that writing the data directly to a spreadsheet makes things a bit easier for me, particularly when I want to sort the data to see just certain event record sources, or perform some other analysis. I've also added some functionality to collect statistics from the Event Log file, and display information such as total counted event records, frequency of event sources and IDs, etc., in a separate report file. I've found these to be very useful and efficient, giving me a quick overview of the contents of the Event Logs, and making my analysis of a system go much smoother, particularly when combined with Registry analysis (such as parsing the Security file for the audit policy...see the Bonus directory on the DVD for the Perl script named poladt.pl and its associated EXE file). One of the things I'm considering adding to this script is reporting of successful and failed login attempts, basing this reporting in part on the type of the login attempt (ie, Service vs Local vs Remote).

Here's something to think about...there is sufficient information in the book, and Perl code on the DVD, such that you can create tools for parsing of event records from other sources, such as RAM dumps, the pagefile, and even unallocated space. I'm considering writing a couple of small tools to do this...not search the files, specifically (I can add that to the code that parses RAM dumps) but to start by simply extracting event records given a file and an offset within the file.

But what about actual Event Log analysis? What about really using the Event Log to get some insight into activity on the system? What can we look for and how can we use it?

Here are some tidbits that I've come across and use...please don't consider this a complete list, as I hope that people will contribute. This is just to get folks started...

Stephen Bunting has a great write-up that explains how to use the Event Log to track time change events, such as when someone alters their system time.

The Application Event Log is a great place to look for events generated by antivirus applications. This will not only tell you if an antivirus application is installed on the system (you can also perform Registry analysis to determine this information), but perhaps the version, when it was active, etc.

In the System Event Log, Event ID 6161 (Source: Print) tells you when a file failed to print. The event message tells you the name of the file that failed to print, the username, and the printer.

Also in the System Event Log, Event ID 35 (Source: W32Time) is an Information event that tells you that your system is sync'ing with a time server, and provides the IP address of your system. This can be very useful in a DHCP environment, as it tells you the IP address assigned to the system (actually, the interface) at a particular date and time.

Windows Defender (Source: WinDefend) will generate an event ID 1007 when it detects malware on a system; the event strings contain specific information about what was found.

Whenever you're doing Event Log analysis, be sure to go to EventID.net for help understanding what you're looking at. Most of the listed event IDs have detailed explanations of what can cause the event, as well as links to information at MS.

Again, this is not a complete list of items that you may find and use in your analysis...these are just somethings that come to mind. And remember, you get a bit more out of Event Log analysis when you combine it with Registry analysis, not only of the audit policy for the system and the settings for the Event Logs, but with other sources, as well.

Links
EventLog Header structure
Event Record structure
EventLog EOF record structure
EventLog File Format