Friday, January 30, 2009

Windows Event logs

In the past when I have had a need to parse Windows Event logs, I would usually use the built-in EnScript (case processor) or use the native Windows event log viewer (eventvwr). The latter does not work exceptionally well when you have fifty machines to look at. The following discussion and ideas are things that have worked for me in the past and some of the problems I have encountered. This discussion only applies to the traditional Windows event logs and not the BXML format used by Vista and new Microsoft Operating Systems.

The current version of the EnCase case processor script includes a module to parse Windows event logs. In the past, I have relied on this to parse many event logs. Currently, it seems to have some problems that cause it to fail to properly finish processing the event log files. It either hangs and never completes or crashes on some of my event logs.

Harlan Carvey recently released a Perl module named that can be used to parse Windows event logs using that perl module. he has made it available through his CPAN directory here. Using this module, you can list all the event and even customize your own perl script to parse multiple evt logs and output the data into whatever format you wish. The nice thing about this Perl module is it is can be used on any platform that supports Perl.

Mark McKinnon took this one step further in a post here that describes how to use Harlan's Perl module and a perl script to parse all the windows event logs and then dump them into a SQLite database. I have used this method as well and it is very handy when you have many logfiles and want to run different queries against all of them. The method Mark describes is very simple and straight forward and it works very well.

Harlan is soon to release a version that parses out the event logs to XLS spreadsheets (watch for it in his WFA 2nd edition). This option also works very well and creates a nice uniform output format that can be viewed by just about anyone. The only limitation I ran into here were event logs that generated more rows than the 65k row limit in Excel. You may need to download some required Perl modules to make this method work, but it's fairly simple and hassle free.

A quick shell script such as the one below and it will go through and parse as many .evt files as you need and kick out a corresponding XLS spreadsheet for each event log.

for file in `find . -type f -iname '*.evt' -maxdepth 10 -print 2>/dev/null`
echo $file
perl ./ -e $file -o $file.xls

In my case, I had 50+ machines, each with at least three event logs, some with more. Each machine had its own directory, so the shell script above recursed each directory parsed all the evt files and left the XLS spreadsheet with the same name as the original, in the same directory as the .evt file.

All of the above options parse the event logs in a 'dead' static state. While this is okay, there are some things you can potentially miss, most are contextual when using the above descibed method(s).

Windows event log entries contain references to messages and other important information that is pulled from .dll files and other sources when the system is running and the event log is viewed. So when looking at an event log entry using the techniques above, you may see the text "PSKILL" in the message field, and that it. If you were to actually look at that event in event viewer, it would parse that event fully and you would actually see other text in the message such as:

"The PSKILL service was successfully sent a start control"

Not this may seem subtle, but context is everything. So I find myself using the techniques above to help me locate log entries of interest, then viewing them in the windows event viewer application so I can make sure and see them in their native format.

Commonly, you will run into the the dreaded "corrupted windows event log" problem when trying to view an exported event log in the Windows event viewer. This is most commonly caused by imaging the system while live, or shutting the system down hard (pulling the plug) before imaging. There is a roaming header that is changed when the event logging system is active, and then changed again with the system is shutdown.

There is a pretty easy way to fix the corrupted logs with a simple hex editor, but again with 50+ machines, totaling over 150+ event logs, that did not seem appealing to me. So below is an EnScript that you can use to select (blue-check) all the event files you want repaired and it will do all the editing for you and export them into the default export folder. Each exported .evt event file will be sequentially numbered to avoid overwriting similarly named log files from multiple machines. You can then load them up in the native WIndows event viewer and see the entire native message(s).

Download here


Anonymous Friday, 30 January, 2009  

You might want to consider the following page for details on how to convert Vista style logs to the original format.

tk_lane Friday, 30 January, 2009  

This is the best software for reviewing event logs in my opinion. It deals with corrupted event logs as well.


Anonymous Friday, 30 January, 2009  

Lance, thanks for sharing the enscript.


Anonymous Sunday, 01 February, 2009  

There is also a free tool for fixing corrupt event logs here:

Anonymous Sunday, 01 February, 2009  

Thanks for the links to the great tools!

H. Carvey Sunday, 01 March, 2009  

Just a quick word here...often, Event Logs extracted from acquired images aren't actually corrupted, per se. I'm not 100% sure, but I tend to think that some of the "corrupted event log" messages result from the Event Viewer not being able to translate some strings because the message DLLs that were in use on the acquired system are not resident on the analysis system. Straight parsing w/ evt2xls or EventLogXP, without translating strings via msg DLLs, has been my preferred solution..."fixing" a "corrupted" Event Log seems hit-or-miss, and unnecessary much of the time.

Unknown Wednesday, 02 September, 2009  

Check out StealthAUDIT it has several data collectors that can tap into different logs plus any ODBC back end database.

Anonymous Tuesday, 30 July, 2013  

Not sure if you still read these comments, but how would you do this?

"There is a pretty easy way to fix the corrupted logs with a simple hex editor"

I only need to fix one log.

Lance Mueller Tuesday, 30 July, 2013


Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles