Investigating File Deletion from Windows File Servers - Part II

This article is the continuation of Part I, where I provided a network capture file in pcap format (file_deletion_full_trace.cap) and asked a few questions about the deletion of some files from a Windows file server:

Q1 - How many files were deleted?
Q2 - When?
Q3 - How?
Q4 - Who did it?
Q5 - From where?

First of all, let me thank those of you who submitted responses even though there was no prize. Thank you so much for sharing! Most of you, though, only included straight answers and not so much information about how you obtained them. That's OK, but if you did things differently than I'll be showing, please leave a comment with your method so we all can learn from it! There's usually more than one way to do... about everything!

OK, let's go for it. In this article I'll be addressing questions Q1 and Q2 and I'll leave the rest for a future article.

Q1 - How many files were deleted?

A quick method to find out which files were deleted through SMB is using wireshark's display filter "smb.disposition.delete_on_close==1" either in the GUI or with "tshark", wireshark's command line version. Note that I'll be showing tshark (text) output to make the post as light as possible, but you are welcome to use the same filters in the GUI if you want to follow along.

Again, using that filter:

C:\> tshark -nn -r file_deletion_full_trace.cap \
-R smb.disposition.delete_on_close==1 -t ad

1707 2007-03-23 09:45:55.436826  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
2694 2007-03-23 09:51:29.713222  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001

We see that two files were marked for deletion. The way file deletion works in SMB is a two step process: first, the file is marked for deletion when closed, then, when the client closes the file the server proceeds to delete it. If we want to see the actual moment of the deletion we can show the "close" commands too:

C:\> tshark -nn -r file_deletion_full_trace.cap \
-t ad -R "smb.disposition.delete_on_close==1 or \
(smb.cmd==0x04 and (smb.fid==0x8004 or smb.fid==0x8001))"

1707 2007-03-23 09:45:55.436826 10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
1709 2007-03-23 09:45:55.444123 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004
1722 2007-03-23 09:45:58.063573 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001
2694 2007-03-23 09:51:29.713222 10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001
2696 2007-03-23 09:51:29.717148 10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001

Frame 1707 marks file 0x8004 for deletion and frame 1709 closes that file, finally provoking its deletion. The same goes for file 0x8001 on frames 2694 and 2696. Frame 1722 shows another close command for a file also identified as 0x8001, but that corresponds to a different file since file identifiers get reused after the previous file has been closed.

Now we need to map those file identifiers to file names. That's easy since Wireshark can tell us if only we ask for payload decoding (option -V in tshark; output trimmed for clarity):

Frame 1707
[...]
      Tree ID: 2051
          [Path: \\SERVER1\PROJECT1]
          [Mapped in: 1659]
      Process ID: 1440
      User ID: 2049
      Multiplex ID: 5504
  Trans2 Request (0x32)
[...]
      SET_FILE_INFO Parameters
          FID: 0x8004
              [File Name: \file4.txt]
              [Opened in: 1704]
          Level of Interest: Set Disposition Information (1013)
[...]
          .... ...1 = Delete on close: DELETE this file when closed
[...]
Frame 2694
[...]
      Tree ID: 2052
          [Path: \\SERVER1\C$]
          [Mapped in: 1767]
      Process ID: 348
      User ID: 2051
      Multiplex ID: 28674
  Trans2 Request (0x32)
[...]
      SET_FILE_INFO Parameters
          FID: 0x8001
              [File Name: \Shared Folders\Project1\file8.txt]
              [Opened in: 2691]
          Level of Interest: Set Disposition Information (1013)
[...]
          .... ...1 = Delete on close: DELETE this file when closed

Combining the tree paths and the file names we obtain the full network paths of the files being deleted:

FID 0x8004:  \\SERVER1\PROJECT1\file4.txt
FID 0x8001:  \\SERVER1\C$\Shared Folders\Project1\file8.txt

Note that although both files may have lived in the same directory in the server (that was the case in this particular case) they were accessed and deleted through different network shares (\\SERVER1\PROJECT and \\SERVER1\C$).

A question remains, though. How does Wireshark know what file name corresponds to which file identifier (FID) and network share? Hint: it's using the ID fields (Tree ID, Process ID, User ID, Multiplex ID). Yes, but how? Would you be able to verify whether Wireshark is correct by checking those fields yourself using appropriate filters without looking at Wiresharks' automatic decoding shown between square brackets? My recomendation: try it! It's fun and you'll learn a lot about SMB!

OK, Q1 solved. On to Q2.

Q2 - When?

This would seem trivial after having found all the information above. However, I don't think it is so much so. Let me explain why.

It might seem obvious that the files were deleted at the following dates and times:

\\SERVER1\PROJECT1\file4.txt:
2007-03-23 09:45:55.436826  (frame 1707)

\\SERVER1\C$\Shared Folders\Project1\file8.txt:
2007-03-23 09:51:29.713222  (frame 2694)

However, I have two problems with that statement.

For one thing, it can be argued that since these frames only contained the request for the files to be marked for deletion the files were actually deleted a little later, when the files were closed. Actually, it would be a little after that, when the server received the close command and then proceeded to delete them, but how long would that be if we want to be exact?

Let me add an additional piece of information to consider. Right after each deletion, we can see in the trace a message sent by the server to the client notifying that the deletion has been completed (filter "smb.nt.notify.action==2", frames 1711 and 2699). Combining this filter with the previous to show the mark for deletion, the close and the notify commands for each file we obtain this:

C:\>tshark -nn -r file_deletion_full_trace.cap -t ad \
-R "smb.disposition.delete_on_close==1 or (smb.cmd==0x04 and \
(smb.fid==0x8004 or smb.fid==0x8001)) or smb.nt.notify.action==2 \
and not frame.number==1722"

1707 2007-03-23 09:45:55.436826  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
1709 2007-03-23 09:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004
1711 2007-03-23 09:45:55.457336   10.10.10.3 -> 10.10.10.11
SMB NT Trans Response, NT NOTIFY
2694 2007-03-23 09:51:29.713222  10.10.10.11 -> 10.10.10.3
 SMB Trans2 Request, SET_FILE_INFO, FID: 0x8001
2696 2007-03-23 09:51:29.717148  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8001
2699 2007-03-23 09:51:29.718439   10.10.10.3 -> 10.10.10.11
SMB NT Trans Response, NT NOTIFY

Now we can be more precise and say that the files were deleted at some point in the following time intervals:

\\SERVER1\PROJECT1\file4.txt, between
 2007-03-23 09:45:55.444123  (frame 1709), and
 2007-03-23 09:45:55.457336  (frame 1711)

\\SERVER1\C$\Shared Folders\Project1\file8.txt, between:
 2007-03-23 09:51:29.717148  (frame 2696), and
 2007-03-23 09:51:29.718439  (frame 2699)

However, I still have a problem with those timestamps. Let us concentrate on the first frame (1709), for example. It was seen on the network at 09:45:55.444123 on 2007-03-23, right? OK, but 09:45 in Madrid, in New York, or where? Actually, those of you living in a different time zone than me and trying the above commands will already be seeing different timestamps for the same frame numbers! Stating a date and time without stating the time zone is ambiguous.

To make a long story short, pcap files contain timestamps in UTC and wireshark translates them to local time at display time. In wireshark's website you can find more information.

You can see the difference in the time displayed by changing the time zone in your computer. Try this:

C:\>systeminfo | find "Time Zone"
Time Zone: (GMT+01:00) Brussels, Copenhagen, Madrid, Paris

C:\>tshark -n -r file_deletion_full_trace.cap -t ad \
-R frame.number==1709

1709 2007-03-23 09:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004

Then, change your time zone to something different (e.g. GMT) and try again:
(tip: you can invoke the Date and Time control panel applet directly with "control timedate.cpl")

C:\>systeminfo | find "Time Zone"
Time Zone: (GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London

C:\>tshark -n -r file_deletion_full_trace.cap -t ad \
-R frame.number==1709

1709 2007-03-23 08:45:55.444123  10.10.10.11 -> 10.10.10.3
 SMB Close Request, FID: 0x8004

Obviously, the above output is from a Windows system. Unix folks will need to play with the environment variable "TZ".

Finally, bear in mind that the option to "Automatically adjust clock for daylight saving changes" also affects the output, although in this particular case it doesn't because the 23mar07 the time hadn't been yet changed for the summer.

With all this, we can conclude that the files were deleted in the time frames stated above (*around* 09:45:55 and 09:51:29 on 2007-03-23), those times being expressed in the timezone "(GMT+01:00) Brussels, Copenhagen, Madrid, Paris" with daylight saving changes enabled.

Answers to Q3 through Q5 to come in a future article...