Found this packet capture. Pretty sure there's a flag in here. Can you find it!?
(1) ANALYSIS OF THE PCAP FILE USING Wireshark
On this challenge, a pcap file named 'dnscap.pcap' is presented for analysis. We open it with Wireshark and see that there are lots of DNS queries and responses of the following types: CNAME, TXT and MX. On each of them, the contents of both the queries and the responses contain large hex strings.
We can use the following Wireshark filters to isolate each query/response of interest:
(dns.qry.type == 16) and not (dns.txt)
(dns.qry.type == 15) and not (dns.mx.mail_exchange)
(dns.qry.type == 5) and not (dns.cname)
Using tshark, we can extract all those packets in separated files:
Note that for each capture we include the frame number, just in case it is necessary for any purpose.
Then we merge all the files in a single one:
And generate a new merged file with all the packets ordered by frame number (first column in the file):
Here is how this new file looks like:
(2) ANALYSIS OF THE CAPTURED DATA
In order to analyze the data we have just extracted, we use the following Perl script named 'bsidessf17_dnscap_script1.pl' (yeah, there is life beyond Python!):
This script reads each line (packet) of the file, parses the frame number and the payload and parses the payload as well in order to extract the strings separated by '.'. Then it deletes all the strings 'org' and 'skullseclabs' (we are interested just in the hex strings) and converts the hex strings to ASCII.
We execute our script and get the following results:
Observing the packet #49, there is a reference to a file named '/tmp/dnscap.png'.
On the other hand, in the packet #50 we see the magic number of a PNG file (89 50 4E 47 0D 0A 1A 0A):
Contents of packet 50:
We know that a PNG file is made of chunks and that in one image of this type we must find at least chunks of the following types: one IHDR (49 48 44 52), one or more IDAT (49 44 41 54) and one IEND (49 45 4E 44).
We look for the IEND chunk and find it on packet #339:
So we can conclude that most probably there is a PNG image hidden between packets 50 and 339.
(3) REBUILDING A BINARY FILE
We will try to rebuild a binary file from the extrated hex strings from the payloads of the packets. We modify our script (now 'bsidessf17_dnscap_script2.pl') to dump the extrated hex strings to a file:
We execute the script and dump the results to the 'hex.txt' file:
Due to the fact that this file contains a string on each line, we process the file to delete all carriage returns:
And finally we use the 'xxd' utility to convert the hex file to binary:
(4) FILE CARVING IN THE REBUILT BINARY
We use 'binwalk' to try to extract the PNG file inside our rebuilt binary:
But unfortunately we are not able to display the file because we get some errors, so we decide to use the 'pngcheck' utility to get more information about the extracted PNG:
We see that there is a chunk in the PNG file with an invalid name (8C 89 01 in hex). Further investigation reveals that this string is at the beginning of packet #51 (the second packet containing data of the PNG file).
Then we use 'strings' on the binary and see some interesting data:
It looks like someone tried to send a PNG fie using an application called 'dnscat2':
Using this application, an attacker can establish a hidden tunnel inside normal DNS traffic. In a real environment, this tool can be used to establish stealth comms with a C&C server or for data exfiltration.
If this is the case, the data of the transmitted PNG file must be in one way only, more precisely within the DNS QUERIES. Considering this hypothesis, we will discard all the DNS RESPONSES.
Just to add more reliability to our hypothesis, we repeat the previous process with the following scenarios, to no avail (we get new corrupted images:
CNAME queries only.
CNAME queries and responses.
(6) DETAILED ANALYSIS OF THE BINARY FILE
As we saw previously, the chunk with invalid name is in the first portion of packet #51. We look for information about valid chunk numbers and find the following:
Now we hexedit our binary file to get further details about what's happening:
In the ASCII pane, after the valid chunk 'pHYs' we see another valid chunk named 'tIME', but the 'pngcheck' tool reports that between them there is what seems to be an invalid chunk '8C 89 01'. From the beginning of this invalid string to the beginning of the 'tIME' string, there are exactly 9 bytes of data. We see that those are the first 9 bytes of packet 51.
Our second hypothesis is that those first 9 bytes of the packet are garbage, dnscat2 overhead or other kind of data which may not be of interest. So we decide to delete the first 9 bytes of each packet.
On the other hand, if we delete those first 9 bytes on each packet, we rapidly see that there are duplicate packets, which seems consistent with the clue we found using 'strings':
'Good luck! That was dnscat2 traffic on a flaky connection with lots of re-transmits.'
(7) REBUILDING THE BINARY FILE TAKING INTO ACCOUNT THE EVIDENCES FOUND
We will rebuild again the binary file but this time taking into account our new hypothesis from the evidences we just found:
Consider DNS queries only.
Delete the first 9 bytes on each packet.
Delete the duplicated packets.
First, we merge all the DNS queries in a single file:
Second, we generate a new file with all the payloads ordered by frame number:
We edit this file and delete all packets but [50..339], which are those we know that contain the PNG file.
Then we modify our script (now 'bsidessf17_dnscap_script3.pl') to delete the first 9 bytes on each packet:
We execute the script and dump the results to the file 'hex.txt':
Now we delete the duplicate payloads using 'awk':
Then, we delete the carriage returns at the end of each line:
We rebuild the binary using 'xxd':
And finally we use 'binwalk' to carve the PNG file:
We check the resulting PNG with 'pngcheck' and it reports an error regarding some garbage after the IEND chunk (which may be deleted using hexedit):
However, this time we are able to display the PNG file and get the flag: