If you have ever searched for anything along the lines of: "How do I discover who deleted a file", you will probably find a dozen articles or more telling you to check for Windows Event ID 4660.
Some examples of excellent search results and resources can be found below (lmgtfy):
- https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4660
- https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4660
- https://eventlogxp.com/blog/tracking-down-who-removed-files/
Then the article will most likely mention that Event ID 4660 lacks the object name (son of a biscuit!) and you will need to map the event using the handle ID to Event ID 4656 or Event ID 4663 (with an Accesses=DELETE). No problem, we've got this. But what do you do if 4660 is not always created? This can happen! (Dun... dun... duuuuunn.....)
Discovery
There are obviously multiple ways to delete a file such as the following:- Delete key
- Right Click > Delete
- "del" from a command prompt
- Shift + Delete
Every single method above generates a 4660 (and 4663) except the last one, Shift + Delete, which happens to be my personal favorite way to to delete a file. :-( Delete it like you mean it...
Test Methodology
- Enable all necessary auditing (lots of articles on this)
- Open Event Viewer > Windows Logs > Security > Filter Current Log > 4660 in the filter box
- Create 4 text files in which you will delete using the methods above
- Delete one file at a time and wait for Event Viewer to notify you of a new log
- Notice that Shift + Delete DOES NOT GENERATE A 4660!
Figure 1: Test methodology shown above with Event Viewer, filters, notifications, and four files to delete |
Conclusion
Sample Logs
Some sample logs from our friend Randy Franklin Smith:
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4660#examples
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4656#examples
No comments:
Post a Comment