Sharkfest 2013: Part II
In the first part of our article we solved the first three challenges, so in this article we will continue with rest of the challenges.
CHALLENGE #4: OUCH!
What should you learn next?
TRACE FILE: challengeattack.pcapng
BACKGROUND: These capture files were taken from a network that was experiencing a "zero-day" attack and was completely overwhelmed. It is also reported that some of the nodes within the network appear to be unable to update their antivirus/security software. The Network Administrator has given you this file that contains what he considers "suspicious" behavior and has asked you to help. The Administrator can tell you that 141.157.228.12 is a server and that 10.1.1.31 is a client machine.
QUESTIONS:
1. What file transfer application is seen in this trace file?
Analysis - Go to Statistics and then select Protocol Hierarchy which will show all protocols used in this trace file.
As can be seen below, the Trivial File Transfer Protocol is being used for transferring data.
Answer: TFTP
2. What is the IP address of the host that is receiving the file?
Analysis - We already knew the server address is 141.157.228.12 and also knew that the file transfer application is TFTP, so we applied a filter for TFPT, and we can see below that the packet contains an exe file and its transfer type also.
Answer: 10.1.1.31
3. What is the name of the file that is being transferred?
Analysis – First, we applied the filter for TFTP application, and as can be seen, there is an exe file, mblast.exe, which is transmitting to 10.1.1.31.
Answer: mblast.exe
CHALLENGE #5: DNS TROUBLE
TRACE FILE: challengednstrouble.pcapng
BACKGROUND: After a maintenance window on the day before, when several servers had been upgraded to a newer operating system, a lot of trouble tickets have come in. Users complain that connecting to web sites and other services takes a long time now, especially when connecting for the first time.
A quick check on all relevant switches, routers and servers reveals no bottlenecks in CPU, memory or disk I/O, so of course the tickets are handed over to the network guys - it must be the network, right? Finally, one of the network engineers comes to you and asks you to help him with analyzing a trace he took. He suspects that there is something wrong with the DNS name resolution, but even after filtering away most of the other stuff he can't put his finger on it. Can you take a look at his trace to find out what happened and if this is a network problem at all?
QUESTIONS:
1. What FQDN is the client attempting to resolve?
Analysis - Open any packet and expand the Domain Name System tab, and as can be seen below, the DNS query is going for flane.de.
Answer: flane.de
2. To what IP address is the first recursive DNS query sent?
Analysis - Go to Statistics and select Conversations, and as can be seen below, there are 6 connections that have been initiated, and the first connection is between 192.168.129.111 and 192.168.129.127.
Answer: 192.168.129.111
3. To what IP address is the second recursive DNS query sent?
Analysis - Go to Statistics and select Conversations, and as can be seen below, there are 6 connections that have been initiated, and the second connection is between 81.209.147.10 and 192.168.129.111.
Answer: 192.168.129.111
4. The trace file includes authoritative DNS servers responsible for what top level country code domain?
Analysis - As we know, the host is trying to resolve flane.de, so here we used a domain look up service for flane.de and we got the all details.
Answer: Germany
5. What is the IP address of the host that is responsible for the long delay in resolving the host name?
Analysis - So here we have to find that host which is taking a long response time, so we started to look at every packet and their request time interval with other hosts, and noticed that in packet no 4 and 5, the host 192.168.129.111 sent a DNS query to 81.209.147.10 two times, and their time interval is also greater than all other packets.
Answer: 81.209.147.10
CHALLENGE #6: VOIP RECONSTRUCTION
TRACE FILES: challengevoip.pcapng
BACKGROUND: This captured file was collected from a recently installed VoIP network that is experiencing performance issues, and you have been asked to evaluate it and recommend corrective action.
QUESTIONS:
1. What three UDP-based protocols are used for the VoIP call and call setup?
Analysis - Okay... the question is based on UDP protocols, so we applied a filter for UDP, and as can be seen below, now we can see only three types of protocols in use: SIP, SDP and RTP.
Answer: SIP, SDP, RTP
2. With what three IP addresses is 45.210.3.90 communicating?
Analysis - It's pretty simple, we have to just check from the Conversation feature. Go to Statistics > Conversation
Answer: 45.210.3.36, 45.210.3.97, 45.210.3.72
3. What SIP error code is seen in this trace file?
Analysis - The error is related to the SIP protocol, so we first applied a filter for SIP and then added the status-code filter.
Answer: Error code 480
4. What is the stated cause of this SIP error?
Analysis - Expand the 480 error code packet in the message header section. We can see the warning message "Endpoint not registered".
Answer: Endpoint not registered
CHALLENGE #7: BOYSCOUT
TRACE FILES: challengeboyscout.pcapng
BACKGROUND: Information leaks from all sorts of places...
Consider the name of this challenge when you view the trace file.
QUESTIONS:
1. What is the secret message?
Analysis: This one is the last and the toughest question of the whole challenge. For finding the secret answer, first we have to create the TCP sequence graph. Select Statistics > TCP StreamGraph > TCP Sequence Graph (Stevens).
Now as can be seen below, we got some kind of graph. The graph is a Morse code and it can be decoded in readable format.
For decoding the Morse code, we used an online Morse code decoder.
Answer: i0love0wireshark
References : http://www.lexilogos.com/keyboard/morse.htm
What should you learn next?
http://www.wiresharktraining.com/sharkfest2013challenge.html