Event Log Dissection

You can use a script to compile log info into a file for closer examination.

• By Chris Brooke
• April 01, 2004

Boss: We have a problem. Some sensitive material was leaked to our competitor.

You: That’s terrible!

Boss: Yes. We need you to go through the server logs and find out if anyone has been trying to access restricted files. We’ve got these files spread out over several servers, and you need to complete this investigation by close of business today. Can you do it? (In other words, the mayor called the chief, the chief called the deputy chief, and the deputy chief just chewed me out! Now it’s all on you!)

You: You can count on me! (Geez, how the heck am I going to get this done?)

Get It All, Get It Fast
The problem with event logs is that there’s so much data. Poring through it all to get what’s needed is tedious at best. Add to that, the fact that the event logs of several different servers must be checked, and you can see that this isn’t a “get it done by COB”-type of task. Or is it?

Geek Alert! Geek Alert!
In the Star Trek: The Next Generation episode “Relics,” Captain Scott (Scotty, from The Original Series) tells Geordi that (paraphrased), “The secret to pleasing the boss is to tell him something will take a long time, then use all your skill to get it done quicker—thus, causing him to think of you as a ‘miracle worker.’” (End Geek Alert.)

As luck would have it, you can use scripting to aggregate the information from a variety of logs and put it into a file for closer scrutiny. Because you’re only looking at certain events, the list is much shorter and you can actually get the information you need when your boss needs it.

<package>
<comment>
Retrieve specific events from event log
</comment>
<job>
<object id="objFSO"
progid="Scripting.FileSystemObject"/>

<script language="VBScript">
strComputer = "Server1"
Set objFile=objFSO.CreateTextFile _
("c:\MyEventLogInvestigation.csv")
Set objWMIService = GetObject _
("winmgmts:{impersonationLevel=impersonate, " _
& "(Security)}!\\" & strComputer & "\root\cimv2")
‘Category ‘3’="Object Access"
Set colLoggedEvents = objWMIService.ExecQuery _
("Select * from Win32_NTLogEvent Where " _
& "Logfile = 'Security' AND Category = '3'")

'Set up headings for CSV file...
objFile.WriteLine "User, Time Written," _
& " Computer Name, Event Type"
'Cycle through desired events & write to file...
For Each clsEvent In colLoggedEvents
objFile.WriteLine clsEvent.User _
& "," & clsEvent.TimeWritten _
& "," & clsEvent.ComputerName _
& "," & clsEvent.Type
Next

objFile.Close
</script>
</job>
</package>

In order to minimize the amount of information returned, we configured the script to only look for certain events—in this case, the Object Access category of the Security log. This is, of course, just what the boss asked for. However, we can use WMI to filter for a variety of events. We can even use it to review events in the System or Application logs. I’ve also set it up to only look at one server at a time (hardwired into the script). You can easily modify the script to get a list of servers from a file and cycle through them one at a time. Or, better yet, use Active Directory Service Interfaces to retrieve a list of all servers. (Just make sure you put in some error handling in case one or two servers listed in AD happen to be offline.)

Also, to make reviewing these logs easier, we’ve only captured some of the properties of each logged event. Because the goal is to look for unauthorized access, it’s not really necessary for us to read the entire Event Message. We’re just interested in who’s looking, when and where they’re looking, and whether or not the attempt succeeded or failed.

It’s important to remember that you must, obviously, have auditing enabled on these servers. But of course, like any good admin, you set this up when you built the servers, correct? To not do so would be ridiculous.

In Windows, there are always at least three ways of accomplishing a particular task. Auditing is no exception. While this script saves a great deal of time, there are other ways of reviewing event logs. For instance, rather than use the script to dump the log data to a CSV file, you can manually dump each log and then consolidate them into one file. Sure, it’ll take longer and involve more work, but it’s an option. (I didn’t say it was a better option!) Also, for those of you who like to work at the command line, you might want to look at Log Parser. This utility comes with the IIS 6.0 Resource Kit Tools and is designed primarily for extracting information from Web server logs. However, it does work with Windows event logs. The cool thing about Log Parser is that it’s packaged as a command-line utility that you pass information to with flags (just like C:\> dir /s), and also as a COM component that you can access from a script. Perhaps in a future column, I’ll take a look at the Log Parser component and see how it compares to the WMI method used in this month’s script.

The more observant among you may have spotted a trend toward security-related scripts the last couple of months. We’re going to continue along this path next month and look at additional ways that we can use scripts to help keep our networks secure. After that, I’d like to move on to some topics that are near and dear to you. So shoot me an e-mail with your suggestions for future columns. Would you like to learn more about logon scripting with Kixtart? How about other scripting languages like JScript, Perl or Python? Shoot me an e-mail with your suggestions.