Event Log Analysis
In keeping with the Getting Started posts, I wanted to include something that may be of interest with regards to finding corroborating artifacts when performing computer forensic analysis.
Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".
This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs aga
inst an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.
Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.
Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:
EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)
Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious
Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean
Many times, when performing CF analysis, we end up trying to find out when a particular user may have logged into a system, or into a Windows domain. There may be other artifacts, as well, that may lead us to the Windows Event Log (right now, I'm just talking about the Windows 2000, XP, and 2003 Event Logs). There are a number of different ways to go about this, using the commercial tools such as EnCase and ProDiscover, but sometimes the analyst may want to extract the .evt files from the acquired image and parse them. In such instances, the Windows API (used by the Event Viewer and a number of other tools) may report that the .evt file is "corrupted".
This has happened enough to others that I don't even bother any longer, and instead resort to tools such as EvtUI, a GUI-enabled Perl script based on the Evt2Xls Perl script that I wrote to parse .evt files on a binary basis, by-passing the MS API and producing something a bit more usable. EvtUI runs aga
inst an .evt file and parses out all of the event records into an Excel binary-compatible spreadsheet. The Time_Generated field of the event record structure is formated so that it can be used to sort on in the spreadsheet. EvtUI also produces a report file, which gives the analyst an overview of the .evt records based on the frequency of the various sources and event IDs. I found this particular functionality useful enough that I pulled it out into its own tool (I call it "evtrpt") and added a frequency count for event types (Info, Warning, Error, Success, and Failure). The report file also gives you the date ranges of all of the event records.Another thing that EvtUI lets the analyst do is enter exceptions. I've seen instances with really large .evt files (when combined with an extremely verbose audit configuration) where .evt file will have more than 65,535 records...and this is the limit of entries for Excel. So, the analyst can run EvtUI once, and then check the report...if there are more than 65,535 records, she can choose event IDs to enter as exceptions and then re-run EvtUI.
Now, once you've gotten this far, the question then becomes, how do you analyze the data you've got? Well, what you look for depends not only on your case, but what's being audited (which you can see very easily by parsing the PolAdtEv value from the Security Registry hive file. This is only a start, though...I suggest that anyone who does or wants to do Event Log analysis check out the following sites:
EventID.net (indispensable and well worth the $24/yr subscription)
Eric Fitzgeralds' blog
Rob "Van" Hensing's Blog
Windows 2000 Security Event Descriptions (pt 1, 2)
Tips
There was an intrusion investigation where the intruder was suspected of having created an account (done in many cases in order to maintain persistence) within the domain. Auditing for logon events was not enabled, but auditing for account management events was...and I was able to quickly find an event ID 624 record showing the creation of the suspicious
Other Resources
EventLogRecord structure
Windows Event Log Reference (Vista, 2008)
GrokEVT (Python-based)
ScreenClean
