Befriending Windows Security Log Events

Published: 2011-02-10
Last Updated: 2011-02-10 12:10:47 UTC
by Chris Mohan (Version: 1)
8 comment(s)


When a call starts off with "I think we've had an incident" or "something isn't right" actual proof of an event or incident has really occurred is a must*. If it's some odd happening on Windows, then it's time to look at the Windows event logs. Windows has three standard event logs: application, system and security. The one most security folks need to keep an eye on is the security event log.
Some questions to ask or ponder about your Windows security logs
  • Do you review or monitor them?
  • How big are the log files?
  • What happens when the log file are full?
  • Do you know if security audit policies in place?
  • Do you have different audit policies for certain systems?
  • Are all your machines using the same time reference?
  • Can you recognize the event ID that could mean trouble?
Each company has its own policies and procedures on how their systems are designed built, configured and managed, but as incident responders we should know these basic details about the security event log.
A common stumbling block for security teams is actually viewing the security logs on other computers. Access to the security logs, by default, is only to a user with local admin right on the machine. There is a nifty way to allow security staff to view them, while not give them full admin access to the remote machines and is recommended by Microsoft [1]. This avoids upsetting the Windows admin team - who are by now still deploying the latest Ms patches and thus pretty busy.
Microsoft has produced a number of helpful guides on how to configure and apply polices [2 & 3] and there are a large number of other references out there. Working with the Windows admin team help them identify some of the warning signs that appear in the security logs, such as multiple account lock outs, brute force account guessing attacks and what certain event ID are [4]
Let's say you have all the right audit policies in place and can view the security logs, but you're attempting to piece together an attack over 50 machines. Just viewing that many separate Windows event logs will make you go crazy. Jason Fossen, author of SANS Windows track, has a wonderful script [5] to convert event logs in to CSV files. Use tools, such as trusty old Ms Excel, to parser the data from CSV files and correlate them in to events timelines. This makes spotting trends, events or incidents much easier as you can look at the combined data and even turn it in to graphs.  
By having the correct information logged and access to the security logs it should take the guessing out of whether a dozen accounts have been locked out is a co-incidence or an actual security incident.
If you have any other suggestions or advice on using the Windows security logs, please feel free to add a comment.
[1] How to set event log security locally or by using Group Policy in Windows Server 2003 for non-admins to access them:
[2] Configuring Audit Policies Windows 2000/2003:
[3] Advanced Security Auditing in Windows 7 and Windows Server 2008 R2:
[4] My favourite place to find what Security Event ID mean:
[5] Dump Windows Event Logs to CSV Text Files
Recommended Event Logs sizes in windows:
* Gut feelings, aching bones, birds flying in weird formation or milk suddenly turning sour is all very nice, but isn't going to help prove an event or incident has taken place to others.

Chris Mohan --- ISC Handler on Duty

Keywords: Microsoft Windows
8 comment(s)


We use Snare to send Windows events to a Kiwi syslog server where we can search and correlate events in plain text.
When dealing with windows logs, there is a tool that you should ALWAYS have available: logparser. It's a MS tool that allows you to (among a number of other things) connect to several remote computer event logs and run SQL query against. It will spit out combined results in pretty much any format you want and since it uses SQL syntax, you can do really nice things with it.
Let me be the second person to say how wonderful LogParser is. It can read the logs live or read them from EVT files offline. There is even a book on it ( You can get LogParser here:
One of the first things that a hacker might try after gaining admin access would be to clear the logs, which is why is is good to store the logs externally, in real time. We use EventLog Analyzer by ManageEngine which pulls the event logs via WMI (more secure than UDP port 514). Alert profiles can be configured to email notifications on suspicious events. You can also apply filters to remove the noise. [I am not affiliated in any way with ManageEngine, just a customer]
We use Splunk for central logging. Its fantastic
(Now) OSSec and (earlier) NTSyslog. Both free.

BTW: I believe pulling the logs is less secure than realtime forwarding them using TCP-Syslog.
Microsoft provides system configuration data capture tools known as mpsreports here: .

These tools are part of Microsoft Platform Support Services. They are useful for documenting a system when run as well as digital forensics and data recovery if an partition table is subsequently lost. They also inadvertently document compromises by enumerating services and ports that may serve as covert channels. Mpsreports will not replace imaging a system directly, or serve as a "real" digital forensics tool since data is modified on the drive, but they can be used proactively and as a documentation tool.
They also grab the event logs and convert them to CSV format as well.

Diary Archives