SANS Network Forensic Puzzle #4

Okay, it's overdue and I'm getting further and further behind my usual walk through of the SANS forensics puzzles (This may be the last as I'm loosing interest.).  So here it is!  Please feel free to contact me if you have any questions or corrections.

1. What was the IP address of Mr. X’s scanner?

Using Wireshark, navigate to Statistics and select IP Addresses... ignore the Filter dialog and just click Create Stat

In this sample we can easily identify the top talker...

Judging by the high count of packets being generated by 10.42.42.253 it is very likely the source of the scanning activity in this PCAP.

2. For the FIRST port scan that Mr. X conducted, what type of port scan was it?

(Note: the scan consisted of many thousands of packets.) Pick one:

* TCP SYN
* TCP ACK
* UDP
* TCP Connect
* TCP XMAS
* TCP RST

This is where (in my humble opinion) a command line tool excels - to confirm what type of scan we need to systematically run throught the possibilities:

If you are unfamiliar with Wireshark/Tshark display filter syntax, a 1 indicates that the bit is set (true) and a 0 indicates that it is not set (false).  See references links at the end of this article to brush up on TCP flags and their values.

TCP SYN (0x02)- Search for segments containing only SYN flags from scanner

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags.cwr == 0 && tcp.flags.ecn == 0 && tcp.flags.urg == 0 && tcp.flags.ack == 0 && tcp.flags.push == 0 && tcp.flags.reset == 0 &&  tcp.flags.syn == 1 && tcp.flags.fin == 0" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -r evidence04.pcap

...that's a mess.  You could try something more straight forward using the hexadecimal value for the SYN bit:

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x02" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -r evidence04.pcap

Result: 7414 matches - Not bad seems like this could be a SYN scan.


TCP ACK (0x10)- Search for segments containing only ACK flags from scanner

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x10" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -r evidence04.pcap

Result: 11 matches - Compared to the previous result this is not likely the scan we are looking for.


UDP - Search for large number of UDP packets from scanner

$ tshark -R "ip.src == 10.42.42.253 && udp" -Tfields -e frame -e ip.src -e ip.dst -e udp.dstport -r evidence04.pcap

Result: 8 matches - that's less than TCP ACK so the odds are not good that this is a UDP scan


TCP Connect (0x10)- The attributes of a TCP Connect scan are similar to a SYN scan so we cannot simply look for the SYN packets.  Unlike the SYN scan, the TCP Connect scan will complete the 3-way TCP handshake by sending the ACK packet back to the target if it receives a SYN/ACK.  The results of searching for segments with ACK flag sent from the scanner could be misleading if there were an ACK scan in progress.  We need more data!  Inspecting the previous packet in the sequence (note the addition of tcp.stream in the tshark fields list) it is possible to associate it with a SYN/ACK from the target thus confirming the presence of a TCP Connect scan.

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x10" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -e tcp.stream -r evidence04.pcap

Output:

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x10" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -e tcp.stream -r evidence04.pcap

Frame 791     10.42.42.253    10.42.42.50    139    0x10    390
Frame 4389     10.42.42.253    10.42.42.50    135    0x10    2235
Frame 13531     10.42.42.253    10.42.42.50    135    0x10    7413
Frame 13532     10.42.42.253    10.42.42.50    139    0x10    7414
Frame 13543     10.42.42.253    10.42.42.50    135    0x10    7415
Frame 13547     10.42.42.253    10.42.42.50    135    0x10    7415
Frame 13593     10.42.42.253    10.42.42.56    1    0x10    7425
Frame 13594     10.42.42.253    10.42.42.25    1    0x10    7426
Frame 13606     10.42.42.253    10.42.42.50    135    0x10    7431
Frame 13610     10.42.42.253    10.42.42.50    1    0x10    7433
Frame 13622     10.42.42.253    10.42.42.56    1    0x10    7425

(Note: I like to include the frame number for ease of locating the packet in Wireshark.)


Result: 11 matches - not too many - if this were an ACK scan there would be hundreds or thousands of ACK packets coming from the scanner.  In the output above, let's look at the first TCP stream identified as 390:

$ tshark -R "tcp.stream eq 390" -Tfields  -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -e tcp.stream -r evidence04.pcap

Frame 779     10.42.42.253    10.42.42.50    139    0x02    390
Frame 786     10.42.42.50    10.42.42.253    56257    0x12    390
Frame 791     10.42.42.253    10.42.42.50    139    0x10    390
Frame 821     10.42.42.253    10.42.42.50    139    0x14    390

The sequence above confirms that this is *not* a SYN scan since the scanner responded to the clients SYN/ACK (flag 0x12) with an ACK (flag 0x10).  In addition the lack of ACK packets does not indicate an ACK scan.  Given the evidence above, it appears that this first scan is a TCP Connect scan.

To be thorough the XMAS and RST scans are examined next.

TCP XMAS (0x31) - Search for FIN, PSH, and URG flags from scanner

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x31" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -r evidence04.pcap

Result: 0 matches


TCP RST (0x04) - Search for RST segments from SRC

$ tshark -R "ip.src == 10.42.42.253 && tcp.flags == 0x04" -Tfields -e frame -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -r evidence04.pcap

Result: 10 matches - the output of this contains one destination IP so it is not a host enumeration scan.

Side Note: Here is a little exercise that will extract the flag values and create a list counting the frequency of each type.  Step 1: Extract SRC IP, DST IP, DST Port and TCP Flags field and save it to a CSV file: $ tshark -R "ip.src == 10.42.42.253" -Tfields -e ip.src -e ip.dst -e tcp.dstport -e tcp.flags -E separator=, -r evidence04.pcap >> output.txt Now, although you could just extract the header field above, I extracted additional fields so I can reuse it to analyze ports and target IPs. So, now just need to pluck the TCP Flags from output.txt $ cat output.txt | awk -F, '{print $4}' | sort -u > list.txt Should look something like this: $ cat  list.txt  0x00 0x02 0x04 0x10 0x11 0x14 0x18 0x29 0x2b 0xc2 Step 2.  That give you a distinct list of all the TCP flag values in hexadecimal format.  Now let's generate a count of each with this Bash loop: $ for i in `cat list.txt`; do echo -n "TCP Flag: $i, Count: " ; grep -c $i output.txt; done TCP Flag: 0x00, Count: 1 TCP Flag: 0x02, Count: 7414 TCP Flag: 0x04, Count: 10 TCP Flag: 0x10, Count: 11 TCP Flag: 0x11, Count: 3 TCP Flag: 0x14, Count: 2 TCP Flag: 0x18, Count: 3 TCP Flag: 0x29, Count: 4 TCP Flag: 0x2b, Count: 1 TCP Flag: 0xc2, Count: 1 Using this information alone the answer to this challenge would be inaccurate.

3. What were the IP addresses of the targets Mr. X discovered?

With this command you can quickly find a distinct list of targets (DST IP)

tshark -R "ip.dst" -Tfields -e ip.dst -r evidence04.pcap | sort -t "." -k1,1 -k2,2 -k3,3 -k4,4 | sort -u

10.255.255.255

10.42.42.25

10.42.42.253

10.42.42.50

10.42.42.56

So throwing out the broadcast and the known source (scanner) you can identify the targets 10.42.42.25, 10.42.42.50, and 10.42.42.56.

4. What was the MAC address of the Apple system he found?

Borrowing the command line foo from Puzzle #3 the MAC OUI Vendors can be extracted like this:

$ for i in `tshark -R eth.src -Tfields -e eth.src -r evidence04.pcap  | sort -u`; do echo -n "$i OUI Vendor: "; VALUE=`echo $i | awk -F":" '{print $1 ":" $2 ":"  $3}'`; grep -i $VALUE oui.txt | awk '{print $2}';done

00:16:cb:92:6e:dc OUI Vendor: AppleCompu

00:23:8b:82:1f:4a OUI Vendor: QuantaComp

00:26:22:cb:1e:79 OUI Vendor: CompalInfo

70:5a:b6:51:d7:b2 OUI Vendor: CompalInfo

5. What was the IP address of the Windows system he found?

By elimination, known IP addresses are:

10.255.255.255 - Broadcast

10.42.42.25 - Apple Macintosh

10.42.42.253 - Scanning System

10.42.42.50 - ?

10.42.42.56 - ?

Do either of these unidentified hosts respond to the SYN probes?  Wireshark display filter for SYN+ACK from specific SRC IP addresses can reveal what services responded... Well known Microsoft specific services can indicate that a Windows machine is responding to the probe.

Try either the .50 or .56 hosts in the 'ip.src==' filter below

ip.src == 10.42.42.50 && tcp.flags.ack ==1 && tcp.flags.syn == 1

Only .50 replys with both the SYN+ACK TCP flags set which reveals that the port is open and something acknowledged the SYN - presumably a windows service on this well known port (MS-RPC on port 135).

Curiously .50 is also talking to the Apple system on TCP/139 (NetBIOS/SMB - File and Printer Sharing) which the attacker also probed.

Answer: 10.42.42.50

6. What TCP ports were open on the Windows system? (Please list the decimal numbers from lowest to highest.)

TCP/135

TCP/139

X-TRA CREDIT (You don’t have to answer this, but you get super bonus points if you do): What was the name of the tool Mr. X used to port scan? How can you tell? Can you reconstruct the output from the tool, roughly the way Mr. X would have seen it?

It's everyone's favorite scanner nmap of course! To do this answer justice it would be another week before I finish so I will just recommend reading this article (http://www.aldeid.com/index.php/Network-forensics/Puzzle4#Tools) which is extremely informative on the topic..

References:

0. Wikipedia http://en.wikipedia.o/wiki/Transmission_Control_Protocol#TCP_segment_structure
1. http://danielmiessler.com/study/tcpflags/
2. http://www.wireshark.org/docs/dfref/t/tcp.html
3. http://www.parkenet.com/apl/HexDecConverter.html