Tracking a Remote File Deletion Back to the Source

Tracking a Remote File Deletion Back to the Source

  • Comments 2
  • Likes

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.

image

image

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:

image

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 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:           INTRANET\Administrator
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:           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.

image

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 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:            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
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 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.