Recently, the office put up a private webserver to store important information about the newest research project for the company. This information was to be kept confidential, as it’s release could mean a large loss for everyone in the office. Just as the research was about to be published, a competing firm published information eerily similar. Too similar… Time to take a look through the office network logs to figure out what happened.
- What is the IP address of the private webserver?
- How many hosts made contact with the private webserver that day?
Filename | MD5 Hash | Download link |
---|---|---|
capture.pcap | e36ff23c6995e3595035982cced6c6a9 | https://mega.nz/#!aihUgK6I!a9Lvt6R1bBKit_bE8oOSQAUCdnl9LX_5egidhK5veRM |
In this task, the challenge deal with a PCAP file, I let you check my article about PCAP analysis.
The first flag is to find the internal IP address of a web server. Since PCAP is quite large, I just have to load it into Capanalysis
and filter on the SSL and HTTP protocols, then filter on the IP that receives the most data:
It was the web server we were looking for:
Flag 1: 192.168.11.4
Now the second challenge is to find the number of IP addresses that have connected to this webserver. Since we know his IP address, with tshark
it’s pretty easy:
|
|
Fortunately, all connections are done on the same day::
Flag 2: 13
1_Discovery
- What is the IP address of the host exfiltrating data?
- For how long did the exfiltration happen? (Round to the nearest second. Format: MM:SS)
- What protocol/s was used to exfiltrate data? (Alphabetical order, all caps, comma separated, with spaces - ex: ABCD, BBCD)
It’s time to open this big PCAP file in Wireshark. Thanks to the first question, we know that the attack exfiltrates some data. The best filter for that is still: data.data
:
We can see that our web server (192.168.11.4) is chatting with another host (192.168.11.7) via weird ICMP requests. Let’s see what these requests contain:
If we get the first request with a tshark
:
|
|
The data formatted like this looks a lot like the DET (Data Exfiltration Toolkit) framework. I had already talked about it in a writeup at the SantHackLause 2018.
Flag 1: 192.168.11.7
Now we have to determine the duration of the exfiltration. With a small filter on IPs, we see some interesting things in the DNS
:
If we extract the last DNS request and this is indeed the last DET request, we should find a “DONE”:
|
|
Perfect, we know the first request with the “REGISTER” and the last one with the “DONE”.
|
|
The exfiltration lasted 11 minutes and 9 seconds:
Flag 2: 11.09
The last step will be the simplest, we already have all the information, to find the protocols, we will do a little tshark trick:
|
|
The “TCP” protocol is not counted since it is a transport protocol (see OSI Model).
Flag 3: DNS, HTTP, ICMP
2_Exfiltration
- What is the name of the stolen file?
- What is the md5sum of the stolen file?
These questions are a little bit easy since we know that the attacker used DET. First request contains both flags:
|
|
- SEx4IRV
- 746f74616c6c795f6e6f7468696e672e706466
- REGISTER
- 6156eab6691f32b8350c45b3fc4aadc1
The first hexadecimal sequence is the name of the encoded extracted file:
|
|
Flag 1: totally_nothing.pdf
The second hexadecimal sequence is the MD5 hash of the encoded extracted file:
Flag 2: 6156eab6691f32b8350c45b3fc4aadc1
3_Data
- What compression encoding was used for the data?
- What is the name and type of the decompressed file? (Format: NAME.TYPE e.g. tamuctf.txt)
Before answering the questions, it will be necessary to find a way to recover the original file. We know that the attacker used HTTP, DNS and ICMP protocols between IP 192.168.11.7 (attacker) and 192.168.11.4 (webserver) to extract his file. We will, therefore, use the following filter and save only the displayed packets to make a lightened PCAP file:
|
|
We go from 15k packets to 117, it’s still more pleasant to analyze.
Get data from ICMP
ICMP data is sent in hexadecimal when decoding on the fly with xxd
piped to tshark
there is no more line break and the data becomes difficult to analyze. For that, there is sed
which will add more returns to the line:
|
|
These are the ICMP data extracted from a file.
Get data from HTTP
HTTP data are sent as POST data:
Same process as for ICMP:
|
|
Get data from DNS
The functioning of the DNS is a bit more different, because each request will be encoded in another.
|
|
Ordering each request
All requests must be put back in the right order. This is how DET works:
- File ID
- Packet number
- Data
This query construction is not valid for the first (REGISTER) and last (DONE) requests. To put all this in order, python will do it for us. I will put all the lines in a dictionary with the packet number as the key:
|
|
Here is what we obtain:
|
|
Remember the first question of the challenge is the type of compression used:
Flag 1: gzip
Now, let’s uncompress the archive and got the original file:
|
|
And now, let’s validate the last flag:
Flag 2: stuff.elf