Auditing object deletions

Question

Hello!I'm having the following problem while trying to audit file/folder deletions:

Test 1: I delete the file locally from the D:\Test folder (locally here means "by using the path D:\Test[file to delete]"

Deleting the file 123-Copy.txt produces the following events (among others) in the Security log:

1. event 4663 - with Access mask = 0x1000 meaning the object was deleted...

...and

2)event 4660 - Object Deleted:

So far so good...exactly as it should work.

Test 2: I delete the file 123.txt from the file share using the UNC path \fs\Test[file to delete]".

As you know users usually work with their files/folders when they are placed in the servers' shares, not by accessing them locally on the servers' file systems so it's much more important to be able to trace object deletions when those objects are being accessed via file shares.

In this test I'm deleting the 123.txt file from the \fs\Test share while logged on to that same server (fs) - NOT from the client's workstation because the problem does manifest itself even when I'm accessing the file in the same folder, on the same server, but using another method (UNC path):

This time event 4663 does get logged but only with access mask = 0x80 and, of course, there will not be any 4660 even - therefore, this file deletion will be left untracked.

???

Thank you in advance,
Michael

Answer 1

P.S. I was not strictly correct saying "the problem does manifest itself even when I'm accessing the file in the same folder, on the same server, but using another method (UNC path):" - yes, it does, but not in the same way as when the share is accessed from a user workstation (not from the server itself): I've found out that

1. deleting a file located in a file share while you are logged on to that server produces neither 4660 event nor 4663 event with access mask =65536 (DELETE) - there will be no traces that a file has been deleted
2. deleting a file located in a file share from some other computer does not produce any 4660 events but does produce the event 4663 with Access Mask = 65536, for example:
   

• I deleted the file (New Bitmap Image.bmp) in the same share - \fs\Test - from another server :
  (you can make sure this was the "network" deletion by looking at the ProcessName field - it must be empty in that case)
  
• it means the number of 4660 events will not be equal to the number of 4663 events with Access mask=65536!

1. The number of events 4663 with AM=65536 (and - in theory - events 4660) may double on some servers:
   

I've never seen the problems described in 1 and 2 and am sure I can't count on such audit in production environment.

Now I see these problems (1-2) in Windows Server 2012R2, Windows Server 2019 and Windows Server 2022.

On Windows Server 2012R2 I've been able to see the two correct events 4660 when the files in the share were deleted from a client workstation - all other attempts (~10) were unsuccessfull (there were no 4660 events but all 4663 events with access mask 65536 were created).

You can find the scripts that were used to produce the txt-files mentioned in this post here:
Windows Audit Part 4: Tracing file deletions in MS PowerShell

Regards,
Michael

Answer 2

P.P.S. The situation when the log contains the event 4663 with Access Mask 65536 for some file but there is no corresponding 4660 event may be absolutely normal: it means users tried to delete a file/folder but failed for some reason - that was defenitely not the case in my tests - all the files and folders had been really deleted.

Answer 3

Hello

Thank you for posting in Q&A forum.

Based on the information above, I have done a similar test in my lab.

I have the exact same result as you.

After I delete the files locally, I can see event ID 4660 and 4663.
After I deleted the files on one client via UNC path, I can see only event ID 4663.

Here is the event ID 4663 after I deleted the files via UNC path on one client.

An attempt was made to access an object.

Subject:

Security ID:		A\Administrator2

Account Name:		Administrator2

Account Domain:		A

Logon ID:		0x3BFFB7

Object:

Object Server:		Security

Object Type:		File

Object Name:		C:\New folder\6.rtf

Handle ID:		0x1030

Resource Attributes:	S:AI

Process Information:

Process ID:		0x4

Process Name:		

Access Request Information:

Accesses:		ReadAttributes

			

Access Mask:		0x80  

You can try to not give the normal user permissions to delete file or sub folder on the root folder.

I hope the information above is helpful.

If you have any questions or concerns, please feel free to let us know.

Best Regards,

Daisy Zhou

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.

Answer 4

Hello Daisy Zhou,

Thank you very much for the confirmation!

"You can try to not give the normal user permissions to delete file or sub folder on the root folder." - mmm... of course it can be done but... do you really think it's normal for enterprise-grade OS???

Inability to audit the most dangerous user action when Object Access audit is fully enabled (all sub-categories are checked - it's by default when you enable the main audit category) is just a complete nonsense!

Furthermore, I didn't experience that issue in 2015 when I was writing the article mentioned above - just don't know what could have happend in various versions of Windows Server so that audit doesn't work any more...

Regards,
Michael Firsov