Tracking a Remote File Deletion Back to the Source

[Ned Pyle]

First published on TechNet on Aug 04, 2009
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:

• Windows Server 2003


• Windows Server 2008

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 .

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 Audit
Event Source:   Security
Event Category: Object Access
Event ID:       560
Date:           7/16/2009
Time:           3:41:08 PM
User:           INTRANETAdministrator
Computer:       2003-X64-04
Description:
Object Open:
Object Server:  Security
Object Type:    File
Object Name:    C:tempworking.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 Audit
Event Source:   Security
Event Category: Object Access
Event ID:       564
Date:           7/16/2009
Time:           3:41:08 PM
User:           INTRANETAdministrator
Computer:       2003-X64-04
Description:
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:           INTRANETAdministrator
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.

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:            HIadministrator
Account Name:           Administrator
Account Domain:         HI
Logon ID:               0x121467
Object:
Object Server:  Security
Object Type:    File
Object Name:    C:temprepreport.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 5663’s 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:            HIadministrator
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
Description:
A network share object was accessed.
Subject:
Security ID:            HIadministrator
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:            HIadministrator
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 that’s left is to sit down with that user and demand the why. :-)

- Ned ‘Polygraph’ Pyle