David Fletcher Boston 2016 PCAP Lab Notebook

NOTE: I was only going to post the analysis of the first two analysts to solve the PCAP puzzle, but this is such a great example of a lab notebook I felt I should.

The pcap file titled “Boston2016.pcap” was downloaded from the SANS website at URL https://www.sans.org/event-downloads/43267/Boston2016.pcap.

This pcap file was opened with Wireshark version 2.0.2. Upon opening the pcap file, the analyst navigated to Statistics > Protocol Hierarchy to investigate the composition of the traffic recorded in the pcap file. The Protocol Hierarchy window identified that the whole of the traffic was Domain Name System (DNS) traffic.

Investigating further, the analyst navigated to the Statistics > Conversations window which revealed that the packet capture contained 147 DNS queries and responses originating from host 192.168.11.23 destined for 192.168.1.1. These queries were for various addresses.

Investigating further, the analyst navigated to the Statistics > Conversations window which revealed that the packet capture contained 147 DNS queries and responses originating from host 192.168.11.23 destined for 192.168.1.1. These queries were for various addresses.

The analyst began inspecting the queries for anomalies. Several comparisons were made.  First, the largest and smallest packet sizes were inspected.  Then the request and response messages in each query.  Each appeared to be a valid query and response.

Next the analyst began inspecting just the DNS queries without the responses. Moving through the results, the analyst noticed that the checksum for the UDP packets seemed to contain a message.

The analyst then split the packet capture into two files. One file containing just the queries and one file containing just the responses.

The following display filter was used to display only the queries in the pcap file.

A new pcap file containing just the DNS queries was saved by using the File > Export Specified Packets menu item only the displayed packets selected.

To capture only the responses, the following display filter was used:

Using the same technique used with the queries, the analyst saved just the responses into a separate pcap file using the File > Export Specified Packets menu item.

In order to extract the bytes of interest, the analyst moved the resulting pcap files over to a Kali Linux computer to use the scapy tool to extract the values.

On the Kali Linux computer, the Boston2016_queries.pcap file was read into Scapy using the rdpcap function.  Then a for loop was used in conjunction with the format method to extract the hexadecimal bytes from the UDP checksum field of each packet.

root@Barrett:~# scapy

INFO: Can't import python gnuplot wrapper . Won't be able to plot.

WARNING: No route found for IPv6 destination :: (no default route?)

Welcome to Scapy (2.2.0)

>>> packets=rdpcap("/home/bugger/Desktop/Boston2016_queries.pcap")

>>> packets

<Boston2016_queries.pcap: TCP:0 UDP:147 ICMP:0 Other:0>

>>> packets[0]

<Ether  dst=4c:e6:76:40:db:2d src=b4:b5:2f:d8:dc:89 type=0x800 |<IP  version=4L ihl=5L tos=0x0 len=60 id=1 flags= frag=0L ttl=64 proto=udp chksum=0xed47 src=192.168.11.23 dst=192.168.1.1 options=[] |<UDP  sport=22830 dport=domain len=40 chksum=0x5361 |<DNS  id=9623 qr=0L opcode=QUERY aa=0L tc=0L rd=1L ra=0L z=0L rcode=ok qdcount=1 ancount=0 nscount=0 arcount=0 qd=<DNSQR  qname='tools.ietf.org.' qtype=A qclass=IN |> an=None ns=None ar=None |>>>>

>>> for packet in packets:

...    format(packet.payload[UDP].chksum,'04x')

...

'5361'

'7665'

'2074'

'6865'

'2064'

'6174'

'652c'

'2053'

'414e'

'5320'

'426f'

'7374'

'6f6e'

'2073'

'7461'

'7274'

<snipped output>

The resulting hexadecimal values were then copied into the vim editor.  The single quotes were removed and the values were collapsed into a single line by replacing newlines with a null value. The result was the hexadecimal string seen below:

536176652074686520646174652c2053414e5320426f73746f6e207374617274732041756775737420312c20323031362e20416e6f74686572206e6f7461626c65206576656e74206f636375727265642041756775737420312c2062757420696e20313938312e202054686520726f636b206d7573696320766964656f206368616e6e656c204d5456206d616465206974732064656275742e2054686520666972737420706572736f6e20746f206465636f6465207468697320616e642073686f7720757020616e642073656e6420746865206d65737361676520746f207374657068656e4073616e732e6564752077696c6c20726563656976652061207072697a652e2042657374206f66206c75636b20746f20796f752c204a756479204e6f76616b002e

This value was then supplied to an online hex to ASCII conversion site (http://www.rapidtables.com/convert/number/hex-to-ascii.htm)  to produce the following message:

The same process was applied to the checksums of the query responses, however, no discernible text was produced.  The result can be seen below.