Overview

For this challenge, we are presented with a PCAP file reported to be named fc.pcap and with a reported size of 198.37KB.

After downloading the file we find it is named fc_0.pcap and has a size consistent with the reported size of 198.37KB. The file is found to have an MD5 sum of 6d3342b94b6f5e623a8867a4a5dca08e and the unix command file returns:

fc_0.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 65535)

supporting the view that we have a network packet capture dump.

Opening the PCAP file in wireshark reveals (via the summary dialog), that:

• full size packets (i.e. 64KB) have been captured
• capture started on 13/Mar/2012 at 21:30:51 and lasted 8.133s
• there are 238 packets in total.

Using the conversations dialog, we discover that:

• only two NICs are present (one is a VMWare NIC and one a Northrop NIC)
• only two IP addresses are used (one is 10.0.0.2 and one is 10.0.0.1)
• only two ports are used (one is 23 and one is 42818)
• 192617B (151 packets) flow from 10.0.0.2:42818 to 10.0.0.1:23, whilst 6681B (87 packets) flow from 10.0.0.1:23 to 10.0.0.2:42818.

Using the IO graphs (with: an x axis tick interval of 0.01s and 2 pixels per tick; and bytes/tick plotted on the y axis), we obtain the following graph:

As can be seen in this graph, we have a peak of traffic at 1.2s (approx. 125,000B) and then a secondary peak at 1.3s (approx. 50,000B) into the packet capture. Under the belief that this network data is untoward, these peaks suggest behaviour such as: the presence of a data overflow (and so overly large packets to trigger the overflow); the exfiltration of data; or the uploading of attacker data.

Closer inspection of the PCAP file reveals that only one TCP flow is present in the file (this appears to be a telnet session) and the telnet session appears to be encrypted (from packet #4 we see the presence of an DES CFB64 encryption option). In addition, we see that:

• from 1.209s (packet 32) to 1.212s (packet 172) 146,858B flow from 10.0.0.2:42818 to 10.0.0.1:23
• from 1.283 (packet 173) to 1.289s (packet 217) 36,261B flow from 10.0.0.2:42818 to 10.0.0.1:23.

Plotting packet capture number against TCP/IP ID number further demonstrates that only two TCP/IP stacks are involved in this communication (this graph has been generated using scapy and Gnuplot):