In my previouse post – Windows Audit Part 4: Tracing file deletions in MS PowerShell – I wrote about the problem I bumped into when searching for events 4660 in the Security log. I was not able to get an answer from MS so I did more testing on my own and would like to share with you my results in the new post.
TEST I) Real file deletion
Suppose you’ve been tasked to find all the files that have been deleted from the folder C:\Audit – here are the steps required to fulfil the task (I’ll delete the test file by myself from C:\Audit to illustrate the process):
According to the Process Name = C:\Windows\explorer.exe we see some file has been deleted locally, the next step is to find out which file has been deleted.
Both events – 4660 and 4663 show the same HandleID (0x2784) so any administrator parsing this log can come to the conclusion that the file TestC2.txt has been deleted from the folder C:\Audit at 3:33:43 AM on 7/22/2015 by the user DOMAIN\Michael. That’s exactly what’s expected.
TEST II) Saving a file – a ‘fake’ file deletion
The task is the same – to find out which files have been deleted – this time I’ll run my test on Windows Server 2016. But this time I will not delete anything:
Here are my steps:
1) I clear the Security log.
2) Several seconds later I save this Security log to C:\Audit.
I don’t expect having any instances of 4660 event since I havn’t deleted any files…
So the question: what reason(s) would make a person parsing this Security log NOT to think that SERVER2016\Administrator has deleted the C:\Audit\Log2016.evtx at 2:14:03 AM on 7/27/2015? Presumably the only way to differentiate the ‘real’ deletions from the ‘fake’ ones is to look at the Process Name field: any setting other than C:\Windows\explorer.exe for local deletions and ” (blank) for network deletions means a file probably has not been deleted.
In any case generating event 4660 in the Security log after any file saving operation contradicts the defenition of the 4660 event:As we have seen event 4660 can be logged when NO objects were deleted.
Counting 4660 events cannot be the answer to the question “How many files have been deleted?” – administrators should (supposedly!) rule out the events showing Process Name field other than “C:\Windows\explorer.exe” or blank.