Event Log Managment

Logs .. Logs and More Logs

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

Auditing Drive Mappings

Windows does not track drive mappings for auditing out of the box. 

To audit drive mappings you will need to do the following steps:

1.       Turn on Object Access Auditing via Group Policy on the system(s) in question

You will need to perform the following steps on each system that you want to track the drive mappings

2.       Open the registry and drill down to HKEY_CURRENT_USER\Network

3.       Right click on Network and choose Permissions  (if you click on the plus sign you will see each of your mapped drive listed)

4.       Click on the Advanced button

5.       Click on the Auditing tab then click on the Add button

6.       In the Select User or Group box type in Everyone

7.       This will open the Auditing dialog box

8.       Select the settings that you want to audit for; stay away from the Full Control option and Read Control.  I recommend the following settings: Create Subkey, Create Link and Delete.

Windows will now generate event id 560, 567 and 564 when the drive mappings are added or deleted.  564 will be generated when a mapping is deleted, 567 will be created when a mapping is deleted or added and 560 will be generated both times as well.  Event ID’s 567 and 564 will not give you the full information that you are looking for, they will tell you what was done to the mappings but not WHICH mapping.  To determine which mapping you will need the Handle ID code that will be found in the event description on the 564/567 events.  The Handle ID will allow you to track back to the 560 event which will give you the mapping that is being added/deleted.  Event ID 567 will only be generated on Windows XP or Windows 2003 systems, Windows 2000 will not generate 567.

March 13, 2008 Posted by | Audit Policy, Audting, Event Log, Object Access | , , | Leave a comment

Tracking Down File Deletes

Recently I was asked to help a customer determine who deleted 300 Gigs worth of data.  Below is a copy of the email I sent them.  This type of question comes up quite often. 

I know you guys don’t want to hear “Microsoft doesn’t …” … but depending on what OS these files were deleted from will affect the information that can be extracted.

If the system was running Windows 2000 then you are going to have a long hard road, W2k only generates event ID 560 for Object Access.  The 560 event does not tell us what a user did but tells us what a user can do (what their object access is).  The 560 event will give us the path to the file that was touched.

Here are a few important notes from Eric Fitzgerald with the Windows Auditing Team: http://blogs.msdn.com/ericfitz/archive/2006/03/07/545726.aspx

Quick Overview of Object Access Auditing in Windows

A lot of people are unhappy with object access auditing on Windows, because what they want to know is “who touched the object and what did that person do”, but what Windows auditing tells you is actually “who touched the object and what did they ask for permission to do”. Note that event 560 does not record what was done to the object, only what accesses were requested to the object.  This is an important distinction.On Windows XP and Windows Server 2003 a new feature “Operation-Based Auditing” was added:Event 567 is recorded for the first instance of a specific access being performed against an open handle.  The event records the access(es) that were performed against the handle.

    • Due to a bug, remote accesses to files (via shares) do not cause event 567 until Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1.

 Now if you are running Windows 2003 SP1 on the system in question you can get most of the information you are looking for but will take some leg work.  Basically you have to look at this in reverse order.  1.      Do a Log Analysis from the EventTracker Console and search for event id 564.

2.      Once found you get it the following information:


Now from this event I know 2 things. 1st tpapa Deleted something and 2nd because the Image File Name is blank it was done via a network share.  If the file had been deleted locally then the Image File Name would contain something like: C:\Windows\explorer.exe (depending on how the file was deleted).

3.       Now do another Log Analysis and look for event id 560 and in the description field use the Handle ID value, which will produce the following:


4.       Based on the information from the 560 event I know the Object that was deleted as indicated by the Object Name field.  Also from the 560 event I can determine where tpapa is located (workstation).  Using the last part of the Client Logon ID, 0xAEE0AD2, do another Log Analysis using the Client Logon ID information in the description field.


5.       This search gives me the 540 event showing when tpapa “logged into” Burlywood, which is the system where the files were deleted.  Looking at this event I will get either the Workstation Name or the Source Network Address.  Then doing a nslookup on the IP address I know that his workstation is NavyBlue. 

6.      I started this search using event id 564 because I know the delete happened.  But If I’m not sure you can search for event id 567 with DELETE in the description field which will generate the following:


We can then start our reverse trace using the Handle ID given above.  

When you do the Log Analysis the output is in the same form as the EventTracker Console, to get this into a “report” you have 2 options.  1st click on the Printer icon in the upper left hand corner of the Log Analysis screen.  2nd you can have this information written to an XLS file, when you are entering your search criteria there is a button at the bottom that says “Save to File”.


Now the above example is based on a Windows 2003 system.  If the system Burlywood had been a Windows 2000 system I would not have the 567 or 564 events.  Then I would have to look at all of the 560 events and then make a best guess based on the Accesses listed in the description field, which will not be 100% accurate.

One final thing, all of this information also depends on what auditing setting you have on the folder/system in question.

September 6, 2007 Posted by | Event Log, Log Management, Object Access | , , | 1 Comment