1

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