Windows Audit Part 5: Problems in tracing file deletions

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):

03-c-AUDIT

Deleting a file generates the following event in Security log:02-NADO-4660

1) My audit settings on HOST3:HOST3-Audit

2) C:\Audit‘s SACL:034-c-AUDIT-DeleteYES

3) I delete the file TestC2.txt from C:\Audit:035-c-AUDIT-DeleteYES-GOOD

4) Now I look for the event 4660 in the HOST3\Security log:036-c-AUDIT-DeleteYES-GOOD2-4660A

037-c-AUDIT-DeleteYES-GOOD2-Ev4660Again, why has this event been registered? Because a) the file has been deleted b) there’s the SACL on C:\Audit that makes any object acceess attempt be audited for the Everyone group.

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.

5) Event 4663 with the access mask set to 0x10000:038-c-AUDIT-DeleteYES-GOOD-Ev4663

039-c-AUDIT-DeleteYES-GOOD-Ev4663

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:

0

1

2

Here are my steps:

1) I clear the Security log.

2) Several seconds later I save this Security log to C:\Audit.

3

4

I don’t expect having any instances of 4660 event since I havn’t deleted any files…

5

…but I do see this:6

6-1

The corresponding event ID 4663/Access MASK = 0x10000 shows which file has been deleted:7

7-1

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:NADO-4660As we have seen event 4660 can be logged when NO objects were deleted.

Here’s another example:21 22 23 24 24-1 25

 

Summary:

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.

 

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: