“That’s Not My Name”(Forensic Challenge Writeup) — DownUnderCTF 2021.
DownUnderCTF (description from CTFtime.org)
DownUnderCTF is the largest online Australian run Capture The Flag (CTF) competition with over 3000+ registered users and over 1400+ registered teams (2020). Its main goal is to try to up-skill the next generation of potential Cyber Security Professionals and increase the CTF community’s size here in Australia. Prizes are only for Australian Secondary or Tertiary school students. However, our CTF is online and open for anyone to play worldwide.
That’s Not My Name
Points: 100, Difficulty: Easy
I chose this challenge for the write-up because of the need to have more information about this type of attack that has been increasing and with more sophisticated techniques every year. It’s a bit long to read but I think it’s worth it…. And yes, for those who are just looking for the solution to the challenge in the fastest way, there is also the section of the unintentional solution :)
Challenge Information
— This challenge had a file for download (notmyname.pcapng.7z)
We start opening the file using Wireshark. After a quick analysis, we can notate a strange behavior in DNS exchange info.
After some time searching for references about this behavior, we believe that its a DNS exfiltration, but what kind? how that works? and what tools use the “Bad Actor” to do that?? and where is the flag?. These answers will be answered below
First, some background knowledge.
Spyware is a malicious software (malware) used to gather information about a person or organization without consent. In a typical setting, a remote server, that acts as a command and control server (C&C), waits for an incoming connection from the spyware that contains the gathered information. Statistics reported by Avast estimate that nowadays over 100 million types of spyware are active worldwide.
In the presence of network security products (e.g., firewalls, WAF, and antiviruses), spyware must communicate with its C&C server over a covert channel, to prolong its operation. Among commonly used covert channels, the Domain Name System (DNS) protocol stands out.
Some Theory about DNS Exfiltration.
Data exfiltration is the unauthorized transfer of data from a system. The transfer of data can be manual by someone with physical access to the system or automated or carried out through malware over a network.
Here is a video for “Kaspersky Security Analyst Summit” back in 2015 named: Real-world examples of malware using DNS for exfiltration and C&C channels.
The SANS institute has an excellent white paper called “Detecting DNS Tunneling” where it explains the fundamental concepts. This white paper is necessary to be understood by all cybersecurity professionals, specifically those dedicated to the “Blue Team/DFIR” in order to know the techniques, tools, and procedures used in the exfiltration of information using DNS Tunneling.
DNS Exfiltration Detection
Akamai has in its blog an excellent article called “Introduction to DNS Data Exfiltration”, from this article we take the most significant to understand how DNS exfiltration detection works.
In order to detect a “High throughput DNS tunneling” correctly, its important to know its main characteristics.
As the DNS protocol mainly uses UDP as a transport medium and knowing that this protocol does not guarantee that messages arrive in the order in which they were sent, DNS tunneling tools (such as: Iodine, Dns2tcp, and DNSCat) have been created to guarantee the reliability of the connection in two ways:
1) Forcing a TCP communication over the DNS, or
2) Sending constant ping messages between requests to ensure the correct order.
But by applying one of these DNS tunneling methods, the message rate of the DNS protocol increases. In addition, when using for file transfer or web browsing, the length and volume of messages will also increase significantly compared to normal DNS traffic behavior.
In summary, the presence of DNS tunneling causes a significant change of DNS traffic in three fundamental aspects for its detection:
1) the volume,
2) the length of messages, and
3) a shorter mean time between messages
Back to the challenge…
Knowing this theory, we can be sure that it’s a DNS exfiltration, through a tunnel.
The mean time between queries is less than 1 second due to keep-alive messages, responses to the same primary domain vary enough to implicate the existence of a bi-directional channel, and the average query length exceeds 100 characters. All the aforementioned are unusual compared to normal DNS traffic.
Now it's time to work…
We can see a lot of DNS traffic from a local address (10.0.2.15) to this IP address “3.24.188.205” try to reach this strange domain “qawesrdtfgyhuj.xyz”, most likely the “Bad Actor” it’s using DNSCat protocol to exfiltrate the information. Let’s filter that using tshark:
To analyze the exfiltrated information, we only need the output queries (queries_out.txt), since according to the DNSCat documentation we have to:
The record type of the response records should be the same as the record type of the request.
We can check that its a DNSCat tunnel for sure using an old tool we find in github called DNSCatDecoder, it’s able to decode the .pcap file without filters (DNSCatDecoder does not recognize the .pcapng format, so we must convert it first to .pcap before running it, for this we use editcap).
We start by analyzing the queries_out.txt file and we see that it has the expected format:
<encoded data>.<encoded data>.<domain>.
We also know that the first 9 bytes are not real data, they are related to the C&C communication. (Sequences and control bytes)
More info about the command protocol here
Now we know that only need the <encoded data> for our analysis, then, we do a bit of linux budu magic (sed and awk) and re-arrange the file, first removing from each line the first 9 bytes, and then removing the domain and the dots in the whole file.
Looking closely at the content of the re-arranged file we can identify 6 groups of exfiltration of information. We separated the groups for individual analysis.
The next step is decoding each group, which we know from the DNSCat protocol is a Hex-encoding. For this, we are helped by our good friend CyberChef. But we also decode and analyzed the whole re-arranged file with binwalk and were able to identify 3 image files in PNG format.
Research Analysis
Transmission group 1
Type: text, txt
Description: short extract from the famous “Lorem Ipsum”.
Exfiltered file name: Lorem_Short.txt
Transmission group 2
Type: image, png
Description: Image of the DUCTF logo
Exfiltered file name: ductflogo.png
Note: After decoding transmission group 2, we notice the presence of the 8 bytes that we assume to be “start of transmission” (they are highlighted in red in the following image).
in yellow is highlighted the PNG header with its magic numbers completed. After removing the first 8 bytes, we have the image
Transmission group 3
Type: text, txt
Description: Challenge flag DUCTF{c4t_g07_y0ur_n4m3}
Filter file name: flag.txt
Transmission group 4
Type: text, txt
Description: “Lorem Ipsum”.
Exfiltered file name: Lorem_Long.txt
Transmission group 5 and 6
type: image, png
Exfiltered file name: unknown (not investigated, maybe another time)
Yes, the Unintended Solution
In Wireshark, we look up DNS and notice that the strings are Hexadecimal, then we do the following:
1) DUCTF{ → to HEX = 44554354467b
2) in Wireshark we look for that HEX string and copy its value
3) then paste the value in CyberChef and decode from HEX
Conclusions:
Based on this distinguishable behavior, current solutions focus on the detection of DNS tunneling by relying on the volume and variety of requests that these tools generate. The obvious solution is rate control, which is offered by security vendors, additionally, the importance of having monitoring tools in the NOC’s/SOC’s and of training personnel adequately so that they can respond effectively to this type (and any type) of threat.
This challenge was particularly interesting from the DFIR perspective, as it involves network analysis techniques that are necessary for the identification of information exfiltration of almost any type.
Beyond getting the flag, which is the main purpose of CTFs, challenges like this one, in which you learn: How to understand the problem, detect the input vector that has been exploited, get the name of tools used, and get to know exactly the type of data stolen, are what make it fun to participate and solve the different challenges.
thanks, @DownUnderCTF for the excellent CTF.
For fun and knowledge, always think out of the box! :)
If you have other solutions and/or any questions, comments are welcome.
You can find me on:
Blog: https://leonuz.github.io/
LinkedIn: https://ve.linkedin.com/in/leonuz
