Auditing can be used to find out who deleted a file from a server. Auditing is not as easy as simply turning on some security policy. You must work backwards from the deletion. 2. There is no single event that will tell you everything.
Original Description:
Original Title
Tracking a Remote File Deletion Back to the Source
Auditing can be used to find out who deleted a file from a server. Auditing is not as easy as simply turning on some security policy. You must work backwards from the deletion. 2. There is no single event that will tell you everything.
Auditing can be used to find out who deleted a file from a server. Auditing is not as easy as simply turning on some security policy. You must work backwards from the deletion. 2. There is no single event that will tell you everything.
Tracking a Remote File Deletion Back to the Source
Ned here again. A long time ago, I blogged about how to track down file deletions in FRS and DFSR. At the end I casually mentioned that auditing should be used if you really want to see who deleted a file from a server. Its not as easy as simply turning on some security policy, so today I will go into the technique. Background As weve discussed previously, Windows Server 2003 (or older) and Windows Server 2008 (or newer) have very different auditing systems. Win2003s was based on the auditing introduced in Windows NT 3.5 and works at a very macro level. Win2008s was based on Vistas system, and features very granular subcategory-based tracking. Im not covering how to enable auditing in great detail here, its well-documented: Windows Server 2003 Windows Server 2008 The key in Win2003 is that you audit categories Logons and Object Access. In Win2008 youll want to audit sub- categories Logons, File System, and File Share. For the actual folders, we only need SUCCESS auditing here (who cares if someone cant delete a file), and it should be done for the built-in EVERYONE group.
2
Analysis So youve got your auditing enabled and you get the fateful call someone has deleted an important file. This is no big deal from a data standpoint because you have a backup to restore (right?), but you need to find out who needs a talking to. Here are the important things to understand: 1. You must work backwards from the deletion. 2. There is no single event that will tell you everything. Windows Server 2003 Audit Trail 1. First you must find the file being accessed for deletion it will be an event 560 and contain the full file name and path on the server. On the file server you open eventvwr.exe and filter on ID 560 and provide the deleted file path as part of the description: 3
The file to be deleted is accessed with a DELETE flag but this does not guarantee it is going to be deleted! Note that you now have the user and the unique Logon ID, plus you have a specific file Handle ID, path, and access flag: Event Type: Success Audit Event Source: Security Event Category: Object Access Event ID: 560 Date: 7/16/2009 Time: 3:41:08 PM User: INTRANET\Administrator Computer: 2003-X64-04 Description: Object Open: Object Server: Security Object Type: File Object Name: C:\temp\working.cap Handle ID: 1924 Operation ID: {0,2159437} Process ID: 4 Image File Name: Primary User Name: 2003-X64-04$ Primary Domain: INTRANET Primary Logon ID: (0x0,0x3E7) Client User Name: Administrator Client Domain: INTRANET Client Logon ID: (0x0,0x20F206) Accesses: DELETE ReadAttributes Privileges: - 2. Next we filter on event ID 564 and a description of the Handle ID. We see that the file is truly deleted. So this Handle ID was our baby, which means the 560s info is accurate on who did this. Event Type: Success Audit Event Source: Security Event Category: Object Access Event ID: 564 Date: 7/16/2009 Time: 3:41:08 PM User: INTRANET\Administrator Computer: 2003-X64-04 Description: 4
Object Deleted: Object Server: Security Handle ID: 1924 Process ID: 4 3. So knowing all that, now you go backwards to see where the user came from. You have the unique Logon ID from the 560 event. So now if you filter on event 540 and the Logon ID, you get the user, the computer IP address, and the Logon ID: Event Type: Success Audit Event Source: Security Event Category: Logon/Logoff Event ID: 540 Date: 7/16/2009 Time: 3:40:59 PM User: INTRANET\Administrator Computer: 2003-X64-04 Description: Successful Network Logon: User Name: Administrator Domain: INTRANET Logon ID: (0x0,0x20F206) Logon Type: 3 Logon Process: Kerberos Authentication Package: Kerberos Workstation Name: Logon GUID: {edaa0263-3264-463b-838a-6b65c3757482} Caller User Name: - Caller Domain: - Caller Logon ID: - Caller Process ID: - Transited Services: - Source Network Address: 10.10.0.159 Windows Server 2008 Audit Trail 1. First you must find the file being accessed for deletion it will be an event 4663 and contain the full file name and path on the server. On the file server you open eventvwr.exe and filter on ID 4663,4624,5140, and 4660.
5
Then in the results you can use the Find command in eventvwr to look for the actual file path, which gives you the 4663 event. The file to be deleted is accessed with a DELETE flag but this does not guarantee it is going to be deleted! Note that you now have the user and the unique Logon ID, plus you have a specific file Handle ID, path, and access flag: Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2009 9:20:30 AM Event ID: 4663 Task Category: File System Level: Information Keywords: Audit Success User: N/A Computer: 2008f-x64-01.humongousinsurance.com Description: An attempt was made to access an object. Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467 Object: Object Server: Security Object Type: File Object Name: C:\temp\repreport.cmd Handle ID: 0x754 Process Information: Process ID: 0x4 Process Name: Access Request Information: Accesses: DELETE 2. Next we find the Handle ID matching on event ID 4660. We see that the file is truly deleted. So this Handle ID was our baby, which means the 5663s info is accurate on who did this. Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2009 9:20:30 AM Event ID: 4660 Task Category: File System Level: Information Keywords: Audit Success User: N/A Computer: 2008f-x64-01.humongousinsurance.com Description: An object was deleted. Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467 Object: Object Server: Security Handle ID: 0x754 Process Information: Process ID: 0x4 Process Name: 3. For more info, we can examine the 5140 event for this Logon ID. That lets us know the share that was used to access the file (this step is optional, obviously we can likely derive the share from knowing where the file was deleted). Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2009 9:20:24 AM Event ID: 5140 Task Category: File Share Level: Information Keywords: Audit Success User: N/A Computer: 2008f-x64-01.humongousinsurance.com 6
Description: A network share object was accessed. Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467 Network Information: Source Address: 10.90.0.102 Source Port: 56897 Share Name: \\*\C$ 4. So knowing all that, now you go backwards to see where the user came from. You have the unique Logon ID from the 4660 and 4663 events. So now if you find the 5140 event for that Logon ID, you get the user, the computer IP address, and the Logon ID: Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 7/16/2009 9:20:24 AM Event ID: 4624 Task Category: Logon Level: Information Keywords: Audit Success User: N/A Computer: 2008f-x64-01.humongousinsurance.com Description: An account was successfully logged on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 New Logon: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467 Logon GUID: {20451c9b-2fcb-ea46-8e09-32a702a1828a} Process Information: Process ID: 0x0 Process Name: - Network Information: Workstation Name: Source Network Address: 10.90.0.102 Source Port: 56897 Detailed Authentication Information: Logon Process: Kerberos Authentication Package: Kerberos Transited Services: - Package Name (NTLM only): - Key Length: 0 Summary And now you know who, when, where, and what. All thats left is to sit down with that user and demand the why. :-) - Ned Polygraph Pyle