Investigating File Deletion from Windows File Servers - Part III
This article is the continuation of parts I and II and it concludes this "Investigating File Deletion from Windows File Servers" series.
In Part I 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?
In Part II I answered questions Q1 and Q2. In this final article of the series I'll answer the remaining questions: Q3 to Q5.
Q3 - How?
From our previous investigation to answer Q1 we know that the files were deleted using the SMB protocol. OK, but what tool and/or procedure did the attacker use? Here we can only guess, since there are several SMB client applications out there and the attacker could have created and used his own. But we can try and do an educated guess.
By far the more widely spread SMB client applications is Windows' own "explorer.exe" (Windows Explorer), so we could ask ourselves: Is it possible that the attacker used plain old Windows Explorer and deleted the files by selecting them and pressing the "Del" key on the keyboard (or right-click>delete)? The best way to test this hypothesis would be to set up a test lab, follow the procedure just described while capturing the network traffic and then compare the network trace with the capture file being studied. If you do that you will see that the network traces, in terms of SMB messages, are almost identical. That would allow us to conclude that most probably that was the tool and procedure used by the attacker to delete the files: Windows Explorer, select a file, right-click > delete.
In fact, that's exactly how these particular files were deleted. I know because I did it :-).
Q4 - Who did it?
We know the files were deleted through an SMB session (potentially, each file from a different SMB session) from IP address 10.10.10.11. So we could be tempted to answer right away Q4 and Q5 saying that the files were deleted by whoever was sitting at 10.10.10.11 at that point in time. But we can do better.
When an SMB session is established the user accessing the server needs to prove his or her identity unless anonymous access is being used. In order to see who (which Windows user) was the owner of the session that deleted the files we need to find the corresponding session establishment and look at the authentication tokens.
Note: From now on (Q4 and Q5) I will be concentrating on the deletion of the first file only (\\SERVER1\PROJECT1\file4.txt, FID 0x8004). The same procedure could be applied to the other file (\\SERVER1\C$\Shared Folders\Project1\file8.txt, FID 0x8001) to obtain the corresponding answers for Q4 and Q5. I'll give the answers for that second file too, but I won't be showing the procedure again. Instead, I'll leave that as an exercise for the reader.
Let's start by selecting the packet where file ID 0x8004 was marked for deletion and let's check the SMB User ID in it:
The User ID (2049) is assigned by the server at session establishment (SMB Session Setup AndX Request/Response, smb.cmd=0x73) so let's look for those packets before frame 1707:
We see that the last time that UID is assigned before frame 1707 is on frame 1527, SMB Session Setup AndX Response. Let's find its corresponding request:
We see that the request was in frame 1525. Let's check out the authentication part inside that frame:
The request contains a Kerberos service ticket for service CIFS (SMB) at server "server1.sans.org". This doesn't identify the user yet, but we are getting closer. What we need to do now is see if we can find the request for this ticket to the Ticket Granting Service (TGS) that must have ocurred before, because that request must have contained the Ticket Granting Ticket (TGT) obtained by the user at logon.
Let us find all previous appearances of this service ticket by looking for the encrypted part (enc-part). Using the GUI (Wireshark) we can easily build a filter that will match the whole "enc-part" contents, but to avoid typing too much in the TUI (Text-based User Interface, Tshark) we'll just look for the first four bytes and hope there is no collision:
We see that the service ticket used in 3 different SMB session establishments and before that, on frame 824, we see the ticket in a response from the Ticket Granting Service. That's the frame we are interested on right now. Let us see its contents:
We see that the response indicates that the ticket was issued to client principal (user name) "david" of realm "SANS.ORG". That is, user "david" belonging to the Windows domain "sans.org" (david@sans.org).
That answers Q4 for file4.txt: it was "david@sans.org" or someone using his authentication credentials who deleted the file. If you apply the same procedure for file8.txt you will discover that it was deleted using a different identity, namely "user1@sans.org".
Q5 - From where?
We already know the deletions were performed from IP address 10.10.10.11, but can we identify the box that had that IP address at that time, like knowing its computer name or netbios name? The answer is yes, we can.
First, let us find the kerberos request to the TGS corresponding to the response we just saw (frame 824, see above):
That request must contain a Ticket Granting Ticket (TGT) of the user:
That TGT must have been obtained from the Authentication Service (AS) at some point:
We see it was obtained on frame 773. Let us find the corresponding request:
We see that frame 772 containes the kerberos request for the TGT. Let us see what this request contains:
Finally, we see that the request for a TGT contains not only the principal name (david@sans.org), which we already knew, but also the NetBIOS name of the computer from which the request was sent: "CLIENTXP1".
This answers our last question, Q5, for file file4.txt: the file was deleted from the computer CLIENTXP1, which happened to have IP address 10.10.10.11 at that time.
If you care to follow the same procedure for file8.txt you will be able to verify that the hostname from which user1@sans.org authenticated was the same, "CLIENTXP1". Actually, what I did to delete the second file was this: while still logged in as david@sans.org onto clientxp1 I used the "Connect using a different user name" option in Windows Explorer to map the second shared folder and provided the authentication credentials (username and password) of user1@sans.org. Then I proceeded like the first time: I selected the file and pressed Delete.
A final note: I have used the domain name "sans.org" all across the article and you will also find it in the network trace. This doesn't mean than any systems belonging to The SANS Institute (http://www.sans.org/) were actually involved in the test lab I set up nor in the real incidents I based this analysis on. It just happens to be the case that the machines I used in the test lab were two of the virtual machines I use when I teach SECURITY 505: Securing Windows.
All the best,
David
In Part I 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?
In Part II I answered questions Q1 and Q2. In this final article of the series I'll answer the remaining questions: Q3 to Q5.
Q3 - How?
From our previous investigation to answer Q1 we know that the files were deleted using the SMB protocol. OK, but what tool and/or procedure did the attacker use? Here we can only guess, since there are several SMB client applications out there and the attacker could have created and used his own. But we can try and do an educated guess.
By far the more widely spread SMB client applications is Windows' own "explorer.exe" (Windows Explorer), so we could ask ourselves: Is it possible that the attacker used plain old Windows Explorer and deleted the files by selecting them and pressing the "Del" key on the keyboard (or right-click>delete)? The best way to test this hypothesis would be to set up a test lab, follow the procedure just described while capturing the network traffic and then compare the network trace with the capture file being studied. If you do that you will see that the network traces, in terms of SMB messages, are almost identical. That would allow us to conclude that most probably that was the tool and procedure used by the attacker to delete the files: Windows Explorer, select a file, right-click > delete.
In fact, that's exactly how these particular files were deleted. I know because I did it :-).
Q4 - Who did it?
We know the files were deleted through an SMB session (potentially, each file from a different SMB session) from IP address 10.10.10.11. So we could be tempted to answer right away Q4 and Q5 saying that the files were deleted by whoever was sitting at 10.10.10.11 at that point in time. But we can do better.
When an SMB session is established the user accessing the server needs to prove his or her identity unless anonymous access is being used. In order to see who (which Windows user) was the owner of the session that deleted the files we need to find the corresponding session establishment and look at the authentication tokens.
Note: From now on (Q4 and Q5) I will be concentrating on the deletion of the first file only (\\SERVER1\PROJECT1\file4.txt, FID 0x8004). The same procedure could be applied to the other file (\\SERVER1\C$\Shared Folders\Project1\file8.txt, FID 0x8001) to obtain the corresponding answers for Q4 and Q5. I'll give the answers for that second file too, but I won't be showing the procedure again. Instead, I'll leave that as an exercise for the reader.
Let's start by selecting the packet where file ID 0x8004 was marked for deletion and let's check the SMB User ID in it:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "smb.disposition.delete_on_close==1 and smb.fid==0x8004"
1707 903.726800 10.10.10.11 -> 10.10.10.3
SMB Trans2 Request, SET_FILE_INFO, FID: 0x8004
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==1707" -V find "User ID:"
User ID: 2049
The User ID (2049) is assigned by the server at session establishment (SMB Session Setup AndX Request/Response, smb.cmd=0x73) so let's look for those packets before frame 1707:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==1707 or \
(frame.number<=1707 and smb.uid==2049 and smb.cmd==0x73)"
598 10.10.10.3 -> 10.10.10.11 SMB Session Setup AndX Response
828 10.10.10.3 -> 10.10.10.11 SMB Session Setup AndX Response
1527 10.10.10.3 -> 10.10.10.11 SMB Session Setup AndX Response
1707 10.10.10.11 -> 10.10.10.3 SMB Trans2 Request,
SET_FILE_INFO, FID: 0x8004
We see that the last time that UID is assigned before frame 1707 is on frame 1527, SMB Session Setup AndX Response. Let's find its corresponding request:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==1527" -V find "Response to:"
[Response to: 1525]
We see that the request was in frame 1525. Let's check out the authentication part inside that frame:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==1525" -V more
[...]
Ticket
Tkt-vno: 5
Realm: SANS.ORG
Server Name (Service and Instance): cifs/server1.sans.org
Name-type: Service and Instance (2)
Name: cifs
Name: server1.sans.org
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 5
enc-part: C26F4754CD8AEC79F9A8C095147CC075F6038D85074CC0E3...
[...]
The request contains a Kerberos service ticket for service CIFS (SMB) at server "server1.sans.org". This doesn't identify the user yet, but we are getting closer. What we need to do now is see if we can find the request for this ticket to the Ticket Granting Service (TGS) that must have ocurred before, because that request must have contained the Ticket Granting Ticket (TGT) obtained by the user at logon.
Let us find all previous appearances of this service ticket by looking for the encrypted part (enc-part). Using the GUI (Wireshark) we can easily build a filter that will match the whole "enc-part" contents, but to avoid typing too much in the TUI (Text-based User Interface, Tshark) we'll just look for the first four bytes and hope there is no collision:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "kerberos.ticket.data[0:4]==C2:6F:47:54"
824 10.10.10.3 -> 10.10.10.11 KRB5 TGS-REP
826 10.10.10.11 -> 10.10.10.3 SMB Session Setup AndX Request
1525 10.10.10.11 -> 10.10.10.3 SMB Session Setup AndX Request
2813 10.10.10.11 -> 10.10.10.3 SMB Session Setup AndX Request
We see that the service ticket used in 3 different SMB session establishments and before that, on frame 824, we see the ticket in a response from the Ticket Granting Service. That's the frame we are interested on right now. Let us see its contents:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==824" -V more
[...]
Source: 10.10.10.3 (10.10.10.3)
Destination: 10.10.10.11 (10.10.10.11)
[...]
User Datagram Protocol, Src Port: 88 (88), Dst Port: 1076 (1076)
[...]
Kerberos TGS-REP
Pvno: 5
MSG Type: TGS-REP (13)
Client Realm: SANS.ORG
Client Name (Principal): david
Name-type: Principal (1)
Name: david
Ticket
Tkt-vno: 5
Realm: SANS.ORG
Server Name (Service and Instance): cifs/server1.sans.org
Name-type: Service and Instance (2)
Name: cifs
Name: server1.sans.org
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 5
enc-part: C26F4754CD8AEC79F9A8C095147CC075F6038D85074CC0E3...
[...]
We see that the response indicates that the ticket was issued to client principal (user name) "david" of realm "SANS.ORG". That is, user "david" belonging to the Windows domain "sans.org" (david@sans.org).
That answers Q4 for file4.txt: it was "david@sans.org" or someone using his authentication credentials who deleted the file. If you apply the same procedure for file8.txt you will discover that it was deleted using a different identity, namely "user1@sans.org".
Q5 - From where?
We already know the deletions were performed from IP address 10.10.10.11, but can we identify the box that had that IP address at that time, like knowing its computer name or netbios name? The answer is yes, we can.
First, let us find the kerberos request to the TGS corresponding to the response we just saw (frame 824, see above):
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "udp.port==88 and udp.port==1076"
823 568.900098 10.10.10.11 -> 10.10.10.3 KRB5 TGS-REQ
824 568.901698 10.10.10.3 -> 10.10.10.11 KRB5 TGS-REP
That request must contain a Ticket Granting Ticket (TGT) of the user:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==823" -V more
[...]
Ticket
Tkt-vno: 5
Realm: SANS.ORG
Server Name (Service and Instance): krbtgt/SANS.ORG
Name-type: Service and Instance (2)
Name: krbtgt
Name: SANS.ORG
enc-part rc4-hmac
Encryption type: rc4-hmac (23)
Kvno: 2
enc-part: 92EF34EF9024B61AAD506AECE425F632D5958EED812718CD...
[...]
That TGT must have been obtained from the Authentication Service (AS) at some point:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "kerberos.ticket.data[0:4]==92:EF:34:EF"
773 10.10.10.3 -> 10.10.10.11 KRB5 AS-REP
774 10.10.10.11 -> 10.10.10.3 KRB5 TGS-REQ
776 10.10.10.11 -> 10.10.10.3 KRB5 TGS-REQ
796 10.10.10.11 -> 10.10.10.3 KRB5 TGS-REQ
823 10.10.10.11 -> 10.10.10.3 KRB5 TGS-REQ
We see it was obtained on frame 773. Let us find the corresponding request:
C:\>tshark -nn -r file_deletion_full_trace.cap -R "frame.number==773" -V more
[...]
Source: 10.10.10.3 (10.10.10.3)
Destination: 10.10.10.11 (10.10.10.11)
User Datagram Protocol, Src Port: 88 (88), Dst Port: 1069 (1069)
[...]
C:\>
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "udp.port==88 and udp.port==1069"
772 10.10.10.11 -> 10.10.10.3 KRB5 AS-REQ
773 10.10.10.3 -> 10.10.10.11 KRB5 AS-REP
We see that frame 772 containes the kerberos request for the TGT. Let us see what this request contains:
C:\>tshark -nn -r file_deletion_full_trace.cap \
-R "frame.number==772" -V more
[...]
Source: 10.10.10.11 (10.10.10.11)
Destination: 10.10.10.3 (10.10.10.3)
User Datagram Protocol, Src Port: 1069 (1069), Dst Port: 88 (88)
[...]
Client Name (Enterprise Name): david@sans.org
Name-type: Enterprise Name (10)
Name: david@sans.org
Realm: SANS.ORG
[...]
HostAddress CLIENTXP1<20>
Addr-type: NETBIOS (20)
NetBIOS Name: CLIENTXP1<20> (Server service)
Finally, we see that the request for a TGT contains not only the principal name (david@sans.org), which we already knew, but also the NetBIOS name of the computer from which the request was sent: "CLIENTXP1".
This answers our last question, Q5, for file file4.txt: the file was deleted from the computer CLIENTXP1, which happened to have IP address 10.10.10.11 at that time.
If you care to follow the same procedure for file8.txt you will be able to verify that the hostname from which user1@sans.org authenticated was the same, "CLIENTXP1". Actually, what I did to delete the second file was this: while still logged in as david@sans.org onto clientxp1 I used the "Connect using a different user name" option in Windows Explorer to map the second shared folder and provided the authentication credentials (username and password) of user1@sans.org. Then I proceeded like the first time: I selected the file and pressed Delete.
A final note: I have used the domain name "sans.org" all across the article and you will also find it in the network trace. This doesn't mean than any systems belonging to The SANS Institute (http://www.sans.org/) were actually involved in the test lab I set up nor in the real incidents I based this analysis on. It just happens to be the case that the machines I used in the test lab were two of the virtual machines I use when I teach SECURITY 505: Securing Windows.
All the best,
David
Labels: Incident Handling, Windows
posted by David Perez at 10:03 AM
1 Comments:
Rembrand asks:
What does it mean when Wireshark labels a packet with the following message?
"TCP segment of a reasemmbled PDU"
Answer:
Hi, Rembrand. It means that Wireshark has grouped together for display the payload of that TCP packet with that of (at least one) another TCP packet, so that it can show the decoding of the payload in a single place.
For example, in frame 523 of the capture file, Wireshark shows de payload and decoding of frames 517, 518, 519, 521, 522, and 523, all together as if it were a single packet with 8058 bytes of payload.
Regards,
David.
Post a Comment
<< Home