Digital forensics

Sharkfest 2014 Part I

The sharkfest challenge was organized by Wireshark University. There are five challenges related to the trace files analysis. In each challenge, there are some questions we have to answer by analyzing the captured trace files. The sharkfest challenge trace files can be downloaded from the reference links. In this part of the article, we will solve the first three challenges, and the other two challenges we will continue in the second part of the article.

CHALLENGE #1: Trouble ticket

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

TRACE FILE: TroubleTicket.pcapng

QUESTIONS:

1. What is the application protocol used?

Analysis – Let us open the pcap file and it's very simple, we saw an HTTP GET request in the trace file. The application is using HTTP protocol.

2. Are all GET requests asking for the same URI?

Analysis - For finding if all requests are asking for the same URL, we just set a simple filter for all HTTP requests. We used HTTP containing "GET" and as can be seen below there are three HTTP GET requests found, and all are asking for the same URL.

3. Based on where this trace was taken, do the packets get lost closer to the client or closer to the server?

Analysis - First we see our client is 46.115.18.210 which is sending the first SYN request to the server which is 81.209.179.132.

Then we see in the second packet the server is responding to the SYN request with SYN,ACK and again it's sending SYN,ACK.

Since the client is not responding with the ACK packet, the server is sending SYN,ACK request multiple times.

Now come back to the main question which is asking where the connection gets lost, near client or server, so we can see here the client is not responding with the ACK request and the connection gets lost near the client.

4. This trace was taken inside the infrastructure. What is the Initial Round Trip Time of the connection?

Analysis - Wireshark is capturing inside the infrastructure between client and server. For measuring the initial round trip, we have to capture the entire three way handshake between client and server.

So we found the exact complete request where the client is sending the SYN request the server responds with SYN,ACK request and then the client sends ACK request.

Now we will set time reference in the first SYN request. Right click on the packet and select 'Set Time Reference'
.

After setting the set time reference in the SYN packet, it will show the total time of three way handshake in the last ACK request and as can be seen below the total time is 3.562215000 seconds.

5. Who owns the server?

Analysis - We set an HTTP filter for all HTTP requests in the trace file. Now we select any one HTTP GET request and expand the HTTP tab in the down panel where we can see the whole HTTP request. We found the host name in the HOST header which is www.verkehrsmittelvergleich.de.

By simply doing a Whois lookup for the domain we found the details we are looking for. The server is owned by Jasper Bongertz.

CHALLENGE #2: BIG FTP

TRACE FILE: BigFTP.pcapng

QUESTIONS:

1. On which host was Wireshark running when this trace file was taken?

Analysis - The first packet we saw in the trace file is a FTP request in 0.00000 seconds and the second packet comes with the response in 0.036454000 seconds later, again the third packet is going with FTP command in 0.000505000 seconds, the request time is too fast, which means Wireshark is running on client's system.

2. If this network does not support jumbo frames, why do we see 16,450 byte packets in the trace file?

Analysis - We first sorted the length column, now we can see all 16450 byte packets.

This size of packet is supported by something called Large Segment Offload. We are seeing the packets are going from the client consist of a large number of bytes in the packet. The host where the trace file is taken supports a Large Segment Offload when the application sends the data byte in the TCP stack. The TCP stack normally segments those bytes and places the header in the beginning of the information and passes down it to the IPV4 header, thus the large packet comes down and the Wireshark host gets a copy of the packet. Now we get a copy of the packet before it gets to the network interface card (NIC) driver and the driver passes the 16450 bytes down to the NIC card, and it actually creates the TCP segments and sends out on the network. Only for this process we are seeing here the jumbo packets in the trace file.

3. What data packet is being acknowledged in frames 314-321?

Analysis - Select Go and then Go to Packet for jumping into packet number 314.

Give the packet number as can be seen below, we gave 314.

Now we can see all packets between 314-321.

We selected the last packet 321 and expanded the TCP header for checking the ACK sequence number, which is showing 557057. Now we have to find which data packet is sending this ACK number to 321.

We started to check all the first data packet numbers, which are sending the main FTP-DATA. We found that packet number 304's TCP header has the next sequence number for 557057. This means data packet 304 is acknowledged between 314-321.

4. Why can't you view the reassembled .jpg file that is uploaded in this trace file?

Analysis - We selected a data packet and right clicked on it then selected Follow TCP stream.

Inside the TCP stream it is showing the RAW data and it doesn't look like an image file. There is message showing that this program must be run under win32 and also some kind of source code is showing. It means it is a Windows executable program.

5. What is the true purpose of kidsatbeach.jpg?

Analysis - First of all we just solved the mystery of the jpeg image in the previous challenge. It was an exe file. So we saved the file in exe format.

After saving the file, now we can run the file to see what its purpose is.

And we found that it was a simple audio converter software.

CHALLENGE #3: PAID TO PLAY

TRACE FILE: AllPlayNoWork.pcapng

QUESTIONS:

1. For what server did the client try to resolve an IPv6 address?

Analysis - An IPV6 address resolution looks for the value AAAA in DNS query. We found the DNS query with AAAA value and expanded the query tab where we can see the query is trying to resolve ws12.gti.mcafee.com.

3. What operating system do you think the client is running?

Analysis - The easiest way is to detect the OS is from user-agent header, so we have to look at every HTTP request.

We selected any HTTP request and expanded the HTTP tab, and we will set the user-agent header as column view so it will make our task easier to view user-agent for all HTTP requests. Right click on user-agent and select Apply As Column.

Now we can see we have a user-agent column where we noticed the first HTTP GET request contains the Operating System name which is Windows 8.

3. What is the color of the mermaid's hair?

Analysis - The question is about some object, but in Wireshark in raw packets we can't see any kind of object's color. So we will here save all objects from the trace file. Go to File > Export Objects > HTTP

Now we can see all image files are there and we found an image file name little mermaid and our question is also related to mermaid.

We just saved the file in jpeg format and opened the image. As can be seen below the hair color is red.

4. What classic games did the user learn about? (Name all of them.)

Analysis - The answer is inside the same HTTP objects the question is asking about. We saw the classic games image file and saved it.

Here is the list of classic games. Solitaire collection, Pac-man, Mahajong, Bigbuck, etc.

5. Which Angry Birds edition did the user learn about?

Analysis - We found the Angry Birds image file and we saved that file.

It is Angry Birds Space Edition.

The other two challenges we will solve in the next part of the article.

References

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

http://www.wiresharktraining.com/sharkfest2014.html