Event Log Managment

Logs .. Logs and More Logs

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 »

  1. […] 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 […]

    Pingback by More Info on Tracking Down File Deletes « Event Log Managment | August 5, 2009 | Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: