Let’s assume you have a shared folder on a server which is accessible by all employees in your company. The users commonly copy some documents into this folder to let the others to work with these shared documents. One day you discover that some files unexpectedly disappeared from the shared folder. Usually this means that someone deleted these files (consciously or unconsciously). Now we need to detect the person who removed the files.
First, you need to setup Windows security auditing to monitor file access (and optionally logon) events. Of course, you should do it right after creating a shared folder and granting access to it (post factum setup won’t help you) . This article describes how to setup security auditing and audit file access and logon events.
If you correctly setup file access auditing for your shared folder, “File system” events will appear in Security log on every attempt to open file inside the folder.
So be sure that the maximum log size for Security log is set to a reasonable value (or you have a chance to lose old events). Microsoft recommends 4GB for most of Windows, but this depends on different factors – I prefer much smaller sizes with autobackup option.
Event 4660 occurs when someone removes a file or a folder. But its event description doesn’t contain the file name:
An object was deleted.
Subject:
Security ID: S-1-5-21-3946697505-1589476648-2597793080-1114
Account Name: mike
Account Domain: FSPRO
Logon ID: 0084C195
Object:
Object Server: Security
Handle ID: 00000AC8
Process Information:
Process ID: 00000004
Process Name:
Transaction ID: {00000000-0000-0000-0000-000000000000}
In fact, when a user deletes file, Windows registers several events: 4663 and then 4660. It can also register event 4656 before 4663).
Here is a sample of 4663 event description:
An attempt was made to access an object. Subject: Security ID: S-1-5-21-3946697505-1589476648-2597793080-1114 Account Name: mike Account Domain: FSPRO Logon ID: 0084C195 Object: Object Server: Security Object Type: File Object Name: C:\shared\Data\_DSC9978.JPG Handle ID: 00000AC8 Process Information: Process ID: 00000004 Process Name: Access Request Information: Accesses: DELETE Access Mask: 10000
You can notice that “Access Request Information” group contains Accesses: DELETE and Access Mask: 10000 parameters.
So we can just filter security event log by Event ID = 4663 and Access Request Information\Accesses = DELETE (and if you enabled auditing for several folders, but want to check a specific one, you should also add filter by Object\Object Name):
Now we can see all “file delete” events with file names.
This method works most of time, but I wouldn’t call it perfect. First, nobody guaranty that Accesses will be DELETE all the time (although you can try Access Request Information\Accesses Contains DELETE). Second, 4663 event occurs on access attempt. In some cases, e.g. if your file is protected, event 4660 won’t appear. So to get more accurate picture, we should rely upon 4663 events and get details from the previous events. Event Log Explorer features Linked Filter, which allows you to link events in security log by description parameter. Look again at 4660 and 4663 event samples. You can link them by Object\Handle ID parameter. Note that Linked Filter scans events from top to bottom, so make sure that you sorted events from new to old (our base event will be 4660).
Here I got the same result as before.
Now you can just display who deleted files. Event description keeps these details in “subject” group. I will use custom columns to show these details in the list:
Here is the result of adding custom columns:
You probably noticed that I added Logon ID along with User name. Using the Logon ID, we can detect from which machine user FSPRO\mike deleted files.
Just set a new filter for event id = 4624 (An account was successfully logged on):
And we are getting the machine name and its IP address
