Microsoft's official enterprise support blog for AD DS and more
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. It’s not as easy as simply turning on some security policy, so today I will go into the technique.
Background
As we’ve discussed previously, Windows Server 2003 (or older) and Windows Server 2008 (or newer) have very different auditing systems. Win2003’s was based on the auditing introduced in Windows NT 3.5 and works at a very macro level. Win2008’s was based on Vista’s system, and features very granular subcategory-based tracking.
I’m not covering how to enable auditing in great detail here, it’s well-documented:
The key in Win2003 is that you audit categories Logons and Object Access. In Win2008 you’ll 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 can’t delete a file), and it should be done for the built-in EVERYONE group.
Analysis
So you’ve 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.
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:
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 AuditEvent Source: SecurityEvent Category: Object Access Event ID: 560Date: 7/16/2009Time: 3:41:08 PMUser: INTRANET\AdministratorComputer: 2003-X64-04Description: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 560’s info is accurate on who did this.
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 AuditEvent Source: SecurityEvent Category: Object Access Event ID: 560Date: 7/16/2009Time: 3:41:08 PMUser: INTRANET\AdministratorComputer: 2003-X64-04Description: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 560’s info is accurate on who did this.
Event Type: Success AuditEvent Source: SecurityEvent Category: Object Access Event ID: 564Date: 7/16/2009Time: 3:41:08 PMUser: INTRANET\AdministratorComputer: 2003-X64-04Description: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 AuditEvent Source: SecurityEvent Category: Object Access Event ID: 564Date: 7/16/2009Time: 3:41:08 PMUser: INTRANET\AdministratorComputer: 2003-X64-04Description: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 AuditEvent Source: SecurityEvent Category: Logon/Logoff Event ID: 540Date: 7/16/2009Time: 3:40:59 PMUser: INTRANET\AdministratorComputer: 2003-X64-04Description: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.
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: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:30 AMEvent ID: 4663Task Category: File SystemLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:An attempt was made to access an object.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Object: Object Server: Security Object Type: File Object Name: C:\temp\repreport.cmd Handle ID: 0x754Process 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 5663’s info is accurate on who did this. Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:30 AMEvent ID: 4660Task Category: File SystemLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:An object was deleted.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Object: Object Server: Security Handle ID: 0x754Process 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: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:24 AMEvent ID: 5140Task Category: File ShareLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:A network share object was accessed.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Network Information: Source Address: 10.90.0.102 Source Port: 56897Share 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:
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: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:30 AMEvent ID: 4663Task Category: File SystemLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:An attempt was made to access an object.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Object: Object Server: Security Object Type: File Object Name: C:\temp\repreport.cmd Handle ID: 0x754Process 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 5663’s info is accurate on who did this.
Log Name: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:30 AMEvent ID: 4660Task Category: File SystemLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:An object was deleted.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Object: Object Server: Security Handle ID: 0x754Process 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: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:24 AMEvent ID: 5140Task Category: File ShareLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:A network share object was accessed.Subject: Security ID: HI\administrator Account Name: Administrator Account Domain: HI Logon ID: 0x121467Network Information: Source Address: 10.90.0.102 Source Port: 56897Share 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: SecuritySource: Microsoft-Windows-Security-AuditingDate: 7/16/2009 9:20:24 AMEvent ID: 4624Task Category: LogonLevel: InformationKeywords: Audit SuccessUser: N/AComputer: 2008f-x64-01.humongousinsurance.comDescription:An account was successfully logged on.Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0Logon Type: 3New 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: 56897Detailed 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 that’s left is to sit down with that user and demand the why. :-)
- Ned ‘Polygraph’ Pyle
Hi Ned
What if I want to attach a task to one of these events and include actual information in, lets say, an email message. I have configured a couple of alerts for events like these, but I only got an email with the subject I configured and nothing in the body. I would like to receive the email with some of the important info in the body.
Any ideas?
What system have you used to send you alert emails? I need specific repro steps.
Outside of that, one way I could think of to do this would be to configure event subscriptions (if using Win2008 or 2008 R2) to forward you the events. To get reall fancy you could also have a scheduled task on your computer with a trigger that reads your forwarded events log and emails you when new events are added, so that you can examine the log data locally. Or have a scheduled task on the server itself that does the same, emailing you when an event of interest occurs.