Event Log Managment

Logs .. Logs and More Logs

Do you need to track who/where/when for activities done against the OU’s in your AD?

With Windows 2003 those were difficult questions to answer, we could get some very basic information from Directory Services Auditing; but it was limited and you had to read through several cryptic events (id 566).  With the advanced auditing settings with Windows 2008 R2 you can get some better information (you can do this same thing with Windows 2008 but it has to be done via command line and applied every time servers restart).

I don’t want to bore you with Windows 2003 auditing or the command line options for Windows 2008 Domains (if you need them, I will get you the information).  So let’s just jump right to using Windows 2008 R2, because we can now apply the advanced auditing settings via Group Policy.

Now when you turn on the Advanced Audit Policy Configuration you are turning OFF the basic or standard Audit Policies.  The Advanced Audit Policy Configuration allows you to control what AD will audit at a more granular level.  Now for the focus of this discussion we are only going to talk about setting up auditing for activity on our Domain Controllers, the other systems in your environment will be a different discussion.

So where do we start so that we can answer our question at the top of this discussion?

First, turn on the correct auditing.  Open up Group Policy Management Editor and drill down as seen in Fig 1.  **Take note of the green highlight.

GPO to Track OU changesFig 1

For this discussion we are focusing on DS Access and its subcategories.  We only want to turn on Audit Directory Service Changes, see Fig 2.  This category only generates events on domain controllers and is very useful for tracking changes to Active Directory objects that have object level auditing enabled. These events not only tell you what object and property was changed and by whom but also the new value of the affected properties.

GPO part 2Fig 2

Now that we have step 1 completed, setting up AD for auditing, it’s time to configure WHAT we want to audit.  This next step is done via Active Directory Users and Computers.  Open up the properties of your AD and drill down to setup the auditing for Create and Delete Organizational Unit objects as seen in Fig 3.

Fig 3

Now we need to add more granularity so we need to do this process 1 more time and this time instead of checking boxes on the Object tab we are going to check 2 boxes on the Properties tab, see Fig 4.

Fig 4

Now that our auditing is setup what type of events can we expect to see?

Here are a few examples:

In this example (Fig 5), id 5137, we see an OU being created by the Administrator.

Fig 5

Figure 6 shows a Sub OU being created.

Fig 6

Figure 7 shows id 5139, an OU being moved.

Fig 7

Now for the best one, this one comes as a pair of messages – OU rename, part of id 5136.

Figure 8 shows the first part of the rename process.

Fig 8

Figure 9 shows the second part of the rename process.

Fig 9

Now let’s contrast all of this with an event that is part of the good old standard auditing.   Let’s take moving an OU; with the Advanced Auditing we get id 5139 (fig 7), nice and easy to read and understand.  Now here is id 4662 that you would get for the same thing with standard auditing, fig 10.

Fig 10

With standard auditing some of the other items that we looked at would be next to impossible with auditing, such as tracking when an OU is renamed and as you can see from fig 10 hard to read and understand if you did get an event.

Now if your AD is in Mixed Mode (W2k8 and W2k3) you are stuck with standard auditing.


August 16, 2012 Posted by | Audit Policy, Audting, Directory Services, Event Log, Windows 2008 | , , , , , , , , , | Leave a comment

Logging, Logging

Here lately we’ve been hearing a lot about Stuxnet and Duqu.  Well this week is no different, but there is some insight into how one of these could have been slowed down if not prevented.  In an article released on Nov 30, 2011 at eWeek.com, Duqu Attackers Wiped All Linux CandC Servers to Cover Tracks, there are some good insights even though it’s almost just a side note.  The article mainly discusses what the Duqu attackers did to help cover their tracks.  The part of the article that caught my eye was the last paragraph.

Even though there was a possibility of a zero-day, the researchers thought it was more likely that the servers’ root passwords were brute-forced, based on a log of a user attempting to log in as root multiple times over an 8-minute period from an IP address in Singapore before finally succeeding.

It all comes down to logging and then doing something with those logs.  Having a solution (www.logrhythm.com) that can help point out these types of items is critical.  Just to have logging turned on gets you nothing, you need to do something with these logs.  Having a solution in place and watching for anomalies like this could have helped to slow Duqu down.  Logs won’t stop the attackers but if we are being proactive and watching (with the correct solution) we would at least slow them down some.

As this also shows that attackers aren’t worried about people logging their activities because they know most organizations/admins aren’t doing anything with the logs until well after the fact.

One of the things that you need to be asking your SIEM/Log Management provider is how would they have picked up on something like this?  Can it be correlated/detected that it was coming from the same IP address and repeated attempts?  Most SIEM/Log Management vendors will tell you “sure we can do that”.  Well my next question would be: What if this was across multiple Operating Systems, could you detect it then?  Now for my shameless plug, with LogRhythm the answer is yes.  Some vendors expect you to be a subject matter expert across all Operating Systems, network devices and applications.  With LogRhythm you don’t need to be, our normalization handles that for you.  We can take being proactive to the next level with advanced correlation and SmartRemediation.

December 2, 2011 Posted by | Audting, Event Log, Hacking, Log Management, Uncategorized | , , , , , | Leave a comment

Event Triggers

I have been asked this question several times so I thought it would be a good time to answer it via a blog post for everyone to use.

“How can I set the Windows Event Viewer to trigger when a certain event happens?” 

Well if you want to set a trigger for something very simple such as ‘when anyone logs in’ or ‘when an account gets created’ that is very simple.  Just right click on the event in the EventViewer and select “Attach Task to This Event…”, then select if you want Windows to launch a program, send an email or display a message. 

It’s that quick and easy if you want to look for something simple.  Now the question “when anyone logs in” is not quite so easy.  Becuase if you recall from an earlier blog post, there are different types of logins.  So if we just look for logins we will be flooded with triggers because of all the network (type 3) and service (type 5) logins that happen all day everyday. 

 The question that arrises most often is “Can event viewer let me know when someone does a remote desktop to one of my servers?”  The answer to that is no.  Take the following screen shot for example.

Microsoft doesn’t give us the ability to look for anything in the event message body, such as the logon type.   But wait you say, EventViewer can do a trigger that will launch a program or script, we can just do it that way.  Not so fast, the program option doesn’t pass the event to the program or script.  So we are unable to parse the message for our logon type or other information.

So the next question comes, how can we trigger (alarm/alert) for specific information that is located in the event message.  Well you have 2 options, 1st is to write your own script (or get one from the internet) that will parse the Event Log and look for your information.  2nd would be to use a SIEM/Log Management tool such as LogRhythm.   Having done manual log management (and via scripts) for many years this could be a painful option.  I’ve been in the SIEM/Log Management business since 2004, I can tell you that many Admins have benefited from letting someone else doing all the heavy lifting of gathering the logs and then setting up alarms very quickly to do just what people have been asking me.

May 31, 2011 Posted by | Event Log, Log Management | , , , , | Leave a comment

Inside and Outside Hack Attempts

Over the last several years I have conducted quite a few webinars with Randy F. Smith on a variety of topics that relate to Windows Audit Policies and Log Management.  Two of these truly drive home the point about why you need to be looking at your logs (not just Windows but all sources; *NIX and Network Devices as well).  The first of these was conducted on Jan 20, 2009 entitled “Anatomy of a Hack: Tracking an Intruder with Security Logs” and most recently on Feb 4, 2010 entitled “Insider Gone Bad: Tracking Their Steps and Building Your Case with the Security Log “.

March 3, 2010 Posted by | Audit Policy, Audting, Event Log, Hacking, Log Management | , , , , , , , | Leave a comment

More Info on Tracking Down File Deletes

Quite awhile ago I wrote a blog entry on Tracking Down File Deletes, it continues to be one of my most read blogs.  I came across another blog entry that does a good job of explaining the same thing.  The author is Ned Pyle, in his post he covers not only the Windows 2003 but also the Windows 2008 auditing so I thought I would share it with you.

August 5, 2009 Posted by | Audit Policy, Event Log, File Deletes, Log Management, Object Access | , , , , , | Leave a comment

Monitoring Network Shares

I had a discussion today with a customer who was trying to monitor when their users tried to access network shares and failed.  He had all the correct accesses setup, removed “Everyone” and gave access to only those groups that needed access.  He even turned on the correct Object Access auditing, but his problem was that when anyone outside the correct groups tried to access the folder they got the message that ”  \\<server name>\<share> was not accessable.  You might not have permission … ” but the Audit Failure 560 events (his server is W2k3) were not being generated. 

This is something that I’ve seen quite often, the issue comes from the  Share Permissions that have been set.  Because he removed the Everyone group from the Share Permission the Audit Failure events for 560 (Object Access Auditing) were not being generated. 

So if you need to be able to track when unauthorized users are attempting to access shares for which they do not have access, leave the Everyone group with Read permission under the Share Permissions tab on the folder (as seen in the screen shot below). 

Share Permission


Now on the Security tab make sure that you turn on the correct Object Access auditing  (stay away from FULL CONTROL; you will flood yourself with noise events).  Now since in this example we want to track when people fail to open the network share, goto the Security tab, then click on the Advanced button, then the Auditing tab.  Click the add button and set this auditing for Everyone and check Traverse Folder and List Folder boxes under the Failed column.

Audit Settings

Now when users attempt to open this network share event id 560 Audit Failure event will be generated telling you who, what, when.  Now the from where is not going to be listed in the 560 event but can be tracked down by looking at the Client Logon ID hex code listed in the event description.

Looking at the Object Name will tell you what file/folder the user was trying to access.  If the Image File Name is blank then you know they were attempting to access the resource from the network, if this field has a value then they used the program listed to access the resource locally.  Client User Name will tell you who the user was if they accessed remotely (if they are accessesing locally then look at the Primary User Name).  The Client Logon ID (or Primary Logon ID) will help you link back to the logon event (528 or 540 in the case of W2k3 and older OS).  Looking at the Accesses list we can see the ReadData/ListDirectory which is what we are auditing for.

560 Failure

May 20, 2009 Posted by | Audting, Event Log, Object Access | , , , , | Leave a comment

Analyzing ID 537 and the Status Codes

When looking through the logs have you ever come across that generic login failure event id 537?  Doesn’t really give you much at first glance, 90% of the time the user name in description field is blank.  This event comes in 2 forms, the workstation version and the DC version.

First I’m going to show the workstation version followed by the DC version.

As seen in the security log from Wrkstation1:

Event Type:        Failure Audit

Event Source:    Security

Event ID:              537

User:                     NT AUTHORITY\SYSTEM

Computer:          Wrkstation1


Logon Failure:

                Reason:                                An error occurred during logon

                User Name:       


                Logon Type:       3

                Logon Process:  Kerberos

                Authentication Package:               Kerberos

                Workstation Name:       

                Status code:       0xC000006D

                Substatus code:                0xC0000133


As seen in the security log on DC1:


Event Type:        Failure Audit

Event Source:    Security

Event ID:              537

User:                     NT AUTHORITY\SYSTEM

Computer:          DC1


Logon Failure:

                Reason:                                An error occurred during logon

                User Name:       


                Logon Type:       3

                Logon Process:  Kerberos

                Authentication Package:               Kerberos

                Workstation Name:       

                Status code:       0xC000006D

                Substatus code:                0xC0000133

                Caller User Name:          

                Caller Domain:  

                Caller Logon ID:

                Caller Process ID:            

                Transited Services:         

                Source Network Address:  

                Source Port:       0



When you get the information from the DC you will be able to track down the system that generated the logon failure either by the Source Network Address or by the Workstation Name in the description field.  The part of this event that holds any real data is the status code (and thank you Microsoft for using HEX codes instead of plain English).

Most of the time you will beat your head against a wall trying to figure out what in the world these codes mean.

Well stop looking I have found a MSDN reference to the NTSTATUS codes. 


Now in the above 2 examples the Status code: 0xC000006D means that “The attempted logon is invalid. This is either due to a bad username or authentication information.”  Since we already know this look at the Substatus code:  0xC0000133 which means “The time at the primary domain controller is different from the time at the backup domain controller or member server by too large an amount.”  Now the “too large an amount” refers to 5 minutes.  Check the system time on the DC where the event happened and check the workstation (Source Network Address).


Hope this helps.

February 24, 2009 Posted by | Event Log | , , , | Leave a comment

Webinar hosted by Whitehatworld

The other day I conducted a webinar that was hosted by Whitehatworld.com.  I have been asked by several people if I would post a link to the recording, so click here to view the webinar.  The webinar topic was “Security Beyond the Windows Event Log – Monitoring Ten Critical Conditions”.

February 11, 2009 Posted by | Audting, Event Log | , , , , , | Leave a comment