Interesting Event IDs

Every now and then, when I analyze a Windows box, the Event Logs end up being pretty important to the issue at hand, and not just because there's login information there. One of the things I tend to look for is Dr Watson events, indicating that there was a crash dump generated.

So, what other interesting things are there in the Event Log?

Steve Bunting has a great article on event IDs that correspond to changes in system time. You could correlate this to information found in the UserAssist key, as well. So, keep your eyes open for the event IDs 520 and 577, particularly if Privilege use is being audited.

Also, I recently exchanged email with a LEO, discussing the various event IDs associated with USB devices being connected to Windows systems. Win2K, for example, has event ID 134 for "arrival" events and ID 135 for "removal" events. This changed for XP, with a possible explanation here. Specifically, at the bottom of the KB article, it says, "After you install the hotfix, Netshell no longer listens for Plug and Play device arrival notifications. Therefore, you are not notified about new devices." Ah...okay.

What're some good ways to go about quickly locating these interesting event IDs in a .evt file?

I like to use the Perl module that I wrote called File::ReadEvt (I've blogged out it before). This module makes it really easy to gather statistics on what's in a .evt file, and it does so without using the MS API...yep, it can be run on a Linux or Mac OS/X box. It parses through the binary file and extracts information based on what it finds there.

The archive that contains the module includes a couple of scripts that allow you to either gather statistics about the .evt file in question, or simply dump the contents into something readable. This is particulary useful if you're following the methodology of loading the .evt file into the Event Viewer on a live machine...sometimes you may encounter an error message saying that the .evt file is "corrupt". Run the script against it, any you'll be able to pull out the information.

One cool thing about scripts like this is that I've used them in the past to locate event records that the MS API did not recognize, and didn't see. This kind of thing is pretty neat, and may be useful in the course of an investigation.

The module doesn't, however, correlate the data from an event to the message strings located in the message library (DLL file on disk). But that's not really an issue, because you can get a subscription to EventID.net and find out more than you ever wanted to know about a particular event ID.

Okay, so, like, how do I tell, from an image, like, what was being audited while the system was running?

Well, to answer that, we need to go to the MS KB article that addresses this issue exactly. This KB article is specifically for NT 4.0, but there's a blog post here that shows things pretty much stayed the same up through XP. As it happens, I have an image from a Windows system that I downloaded and like to use to test things out. I extracted the Security file from the image, and ran my offline Registry parser against it. The odd thing was this...the KB article never tells you what the data type (binary, dword, string, etc.) the value is; regp.pl told me that the type is "REG_NONE". Okay, so I made a quick modification to the script and reran it, and got the data for the value we're looking for:

01 17 f5 77 03 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00 09 00 00 00

What does this tell us? Well, first off, auditing was enabled...that's the "01" at the beginning. The next three bytes (17 f5 77) mean...well, I don't know at this point. The last octet specifies how many different fields there are...you'll notice that between the first and last DWORD (ie, 4-byte values) there are 9 DWORDs. From there we can map the different audit sections, and the auditing set for that section corresponds to 1 = success auditing, 2 = failure auditing, and 3 = both.

The blog article linked above provides a great way to perform some live testing, and you can use auditpol.exe (if anyone has a credible link to this tool, please share it) to verify this, as well.