Challenge pcap
Challenge Questions

Introduction and Scenario

This write up is going to be going over a small network traffic analysis challenge. We are given a base scenario, a set of questions, and a pcap file to answer those questions. Below is the scenario, which I follow up with a brief summary of how I perceive the scenario to affect the challenge, if at all. You are an independent Security Analyst. Recently, Star Mart, a large supermarket chain, has called you and asked for help(Because you are just that good right?). The Company believes they have had a security breach carried out by a small group of hackers over the Easter weekend. The company doesn't know what information has been stolen and it is up to you to identify what the hackers have taken alongside other critical information. Questions What host is exfiltrating the data? What protocol are they using to exfiltrate the data? At what interval are the hackers exfiltrating the data (in seconds)? What domain is being used to hide the data? How are the hackers disguising the data? What are the second and seventh entries being filtrated? How are the entries obfuscated? List all the entries that were stolen.






Breaking Down the Scenario

It is quite common for people to just skip over or skim the scenarios for ctfs/challenges, which I view as a mistake. There are a few reasons why this is most likely a bad idea. The first one being that event/challenge organizers often times hide little hints or clues in the scenario. In addition to possible hints, the scenario provides the context in which YOU the participant are involved in their world. This means that as your role changes in the scenario, you may want to change your perspective. A good example of this is the way two security professionals may look at the same information. The scenario we have to deal with may seem brief, but there are some details that may be worth taking a look into. The pcap file we have was given to us by the business who believes they have been hacked. It is safe to say that the pcap file is going to be coming from from their network, meaning their internal servers will most likely have some sort of private ip, with a few public facing servers for things such as websites etc.. This tells us any private ip range will more than likely be the host sending out exfiltrated data. What the scenario tells us to be looking for:

  • The infected host is most likely on a private IP range
  • The data being exfiltrated is most likely NOT being sent in plaintext
What the concept of data exfiltration tells us to look for:
  • The attacker most likely wont be exfiltrating the data all at once as to avoid detection
  • The attacker will probably be exfiltrated by the means of some very common or miscellaneous protocol to try and fly under the radar.

First Glance

With these factors in mind, lets begin to take a look at the packet capture itself. There are a few different ways to approach finding first what host(s) are involved in the attack. More or less the first step for most traffic analysis questions like this will remain the same: Identify what traffic we need to be looking at. This first step is often times quite daunting for people, and it can really make it hard to get started with the challenge. Luckily we have a few tricks we can use to make this step a bit easier.

The first thing we notice upon opening the pcap file is a host with the ip 10.2.0.15, which is a private IP. This is immediately a host we are going to look into as we know it is on the private network of the business. In addition to this we are going to view the "endpoints" for our traffic. This will tell us who has all been communicating in this pcap. After looking through some of the listings, we can quickly see they only have one private ip even listed in the pcap file. Meaning the first host we should start looking at is this 1 host on the private ip range. Lets start doing this by setting a filter in wireshark. This filter "ip.addr == 10.0.2.15" will make wireshark ONLY show us traffic that EITHER the destination ip or the source ip was the ip following the "==". After applying this filter, and taking a look back into the endpoints and check the little box at the bottom that says "limit by display filter". You will notice nothing changes, this tells us that the IP 10.0.2.15 is involved with every packet in the packet capture meaning that it was more than likely captured/capturing a single host. This is another bit of evidence that may elude to 10.0.2.15 being our host referenced in the first question. Going back into the endpoints window lets sort the list by number of packets sent. Do this in each tab, including ipv4, tcp, udp etc.. This is the stage where we can look for anything that may be interesting or different to stand out. The challenge itself I would rate is more on the easy side, which is important when identifying what we are looking for. In the UDP tab we notice that one IP is responsible for almost ALL outside UDP connections. Lets start by looking into this.





Filtering The Traffic

Lets take that display filter we used earlier and combine with another to enable us to effectively analyze the UDP traffic. Since we are looking to narrow it down to one specific protocol we can use a wireshark filter with our address filter to narrow it down to be only UDP traffic where our 10.0.2.15 host was one of the endpoints. In this case the ip.addr filter is not completely necessary, but I will keep it as most other times it will be needed. Our filter will end up looking something like this "ip.addr == 10.0.2.15 && udp". Upon applying this filter we notice that every single packet is DNS (which runs under udp hence why it is shown in this filter). This could be viewed as disproportionate and odd to have ONLY DNS packets of UDP on this network, but its far from impossible so we will go ahead and take a brief look at the traffic displayed by the filter.

Upon scrolling down I see a few dns queries that stand out to me at packet numbers 4078,4086, 5734. The most noticeable packet out of these is packet 4078 which contains an odd dns query for "616272616e343a6347467a63336476636d513d.uis.edu". If we look at the DNS response to the query we will find it returned flag/error 0x8183 or "no such name". This alone is a little bit suspicious, but the domain being queried itself is also quite odd, so we will pursue this packet by seeing if we can find any more traffic like it.We can accomplish this by using the dns.flags filter in wireshark. We can see that the flag in responses that result in "no such name" errors is 0x8183. So we would add "dns.flags == 0x8183" to our filter.





Suspicious Traffic

We can accomplish this by using the dns.flags filter in wireshark. We can see that the flag in responses that result in "no such name" errors is 0x8183. So we would add "dns.flags == 0x8183" to our filter.After adding that to our filter it will look like this "ip.addr == 10.0.2.15 && udp && dns.flags == 0x8183". This shows us 10 dns responses with that error code, and upon investigating what domains were queried, we find they are all similar to the first packet we mentioned earlier. This leads me to believe that these packets will contain the data being exfiltrated as querying for a domain of that length alone is weird, but what confirms my thought process is that the domains are both not found, and changing as if it really wasnt trying to resolve something specific anyways. In addition the packets appear to be sent every 30 seconds, which is a set interval, one that could be an answer to a question we were given. So lets take a look at what domains are being requested

  • 616272616e343a6347467a63336476636d513d.uis.edu
  • 62726f6765323a5a484a7664334e7a5958413d.uis.edu
  • 6a736d6974363a6332687064475a315932733d.uis.edu
  • 6270617261323a596e5675626e4e766333526c5a57773d.uis.edu
  • 65726f6765333a61576868646d566859584a77.uis.edu
  • 707363686d323a5a32687663335270626d633d.uis.edu
  • 646d616c69323a64473979.uis.edu
  • 6a73707269343a6147466a6132566b.uis.edu
  • 61646d696e3a626d6c745a47453d.uis.edu
  • 726f6f743a64484a6c5a513d3d.uis.edu





Decoding The Data

The part I find most interesting is the strings that are added to uis.edu, they do not seem to follow a set length, and change each time, they do however all follow the same character set. They only can the letters A-F and numbers 0-9, which makes me suspect this could be hexadecimal. So with that in mind, I took the first dns query for "616272616e343a6347467a63336476636d513d.uis.edu and chopped off the uis.edu as we know that is not hex and converted it from hex to text.

The result was the following "abran4:cGFzc3dvcmQ=". This definetly looks like a user and a (most likely) base64 encoded password being sent out of the network. After we decode all of the entries, we should have all the information we need to answer the questions.





Quick Answers/Explanations

What host is exfiltrating the data? 10.2.0.15

We got this answer because this host is an endpoint in every single conversation, and is the only local host we have on top of the traffic we found later on that confirms our theory.

What protocol are they using to exfiltrate the data? DNS

At what interval are the hackers exfiltrating the data (in seconds)? 30 seconds We can determine this by looking at the time between each dns request/response

What domain is being used to "hide" the data? uis.edu The requests that exfiltrate data are ALWAYS going to uis.edu

How are the hackers disguising the data? hex They are converting the data to hex, which we began to suspect because its characters only consisted of A-F and 0-9.

What are the second and seventh usernames being filtrated? broge2 and dmali2

How are the password entries obfuscated? Base64 We suspected this encoding due to the "=" at the end of the string, and it was confirmed upon decoding it with base64

What is all the data taken from server? (Un obfuscated) abran4:password broge2:drowssap jsmit6:shitfuck bpara2:bunnsosteel eroge3:ihaveaarp schm2:ghosting dmali2:tor jspri4:hacked admin:nimda root:tree We hex decode the strings in front of the uis.edu, then we take the base64 encoded passwords we found and decode them and repeat this process for all entries.

Thanks for reading the guide, and please feel more than welcome to email me any feedback or questions you may have!