Malware of the Day – dnscat2 DNS Tunneling
What is Malware of the Day?
Traffic Type: DNS
MITRE Tactics: T1071.004 DNS, TA0011 Command and Control, T1048 Exfiltration Over Alternative Protocol
Connection Type: DNS
C2 Platform: dnscat2
Origin of Sample: https://github.com/iagox86/dnscat2
Host Payload Delivery Method: Executable
Target Host/Victim: 10.20.57.3 – Ubuntu 20.04
C2 Server: 188.8.131.52
Beacon Timing: N/A
The Domain Name System (DNS) is sometimes referred to as the backbone of the internet, and rightfully so. It performs the simple but integral task of taking human-readable names and determining the machine-readable IP Address that your computer uses to route you to your destination. Like any protocol however, DNS can be abused. DNS Tunneling is one of many attacks that use DNS. Given its large role in the workings of the internet, as well as the fact that it is not indented to be used for data transfer, DNS is often poorly monitored. It is almost always allowed through firewalls even in highly restricted networks.
In this post, we are exploring DNS Tunneling specifically as a command and control channel (MITRE ATT&CK ID T1071.004). Using DNS for C2 communications is a well-established attack vector. There are many free tools available that make it easy to launch an attack, even for the less experienced hackers out there. Recent malware such as the Anchor malware, which targets high profile targets in manufacturing, retail, and finance was discovered to be using DNS for its C2 communications. Another recent malware, FrameworkPOS, steals payment data and exfiltrates it over a DNS channel.
How Does DNS Tunneling Work?
DNS is meant for internet resource lookups, but it can also be used for transferring small amounts of data. The data is usually prepended to the domain name. Example: “maliciousEncryptedCommand.sketchydomain.com”. The attacker must first register an authoritative domain, such as “sketchydomain.com” which points to the server with the server-side malware installed. Then the client side is installed on the target’s computer, which will begin making DNS requests that will be parsed by the program running on the server.
C2 over DNS can be difficult to detect because it blends in well with existing legitimate DNS traffic. The compromised system is not making a direct connection to the C2 server. Instead, the request will be sent out to the DNS resolver and then probably bounce around the internet until it gets to the authoritative name server for the domain queried. This means it will not show up as a beacon or long connection.
To demonstrate DNS Tunneling, we are running dnscat2. We have control over the domain and name server of “cisco-update.com”.
Inspecting the packet capture above, we can see that the client is sending different forms of requests about once every second. Luckily for us, DNS queries are made in plain text so we can see the subdomains being queried, which in this case look suspiciously like Hex encoded commands. Let’s see what our Network Threat Detection software thinks about this…
The screenshot above is taken from the DNS module in AC-Hunter. It shows a host on the internal network (10.20.57.3) made 165,517 lookups and 165,378 FQDNs for the domain “cisco-update.com”. This is being flagged by AC-Hunter because of the volume of DNS queries being made and the high number of FQDNs to a single root domain. It is highly unlikely there is a valid reason for a single system to make 160,000+ DNS queries for the same domain in a 24 hour period. If you were to capture traffic from your PC, you will likely find the most DNS queries will be going to Google, Akamai, Amazon, etc. and even those typically should not be above triple digits in the number of unique subdomains queried.
Using RITA (above), we can see the actual FQDNs (Fully Qualified Domain Names) being queried. The long string of seemingly random alphanumeric characters prepended to the domain is one possible indication that this is not legitimate traffic. One could also do an entropy analysis on the domains to try to determine their maliciousness. Computer generated domains have a high degree of entropy (randomness) whereas in the English language some letters show up considerably more frequently than others. Therefore, domains with higher entropy are more likely to be an encrypted command, or at least something machine generated.
Another thing we could look for is what comes after the DNS request. In almost all circumstances, if a client makes a query for a domain it is because they want content or some resource from that domain. Therefore, after the DNS request has been made we should see another connection such as an HTTPS connection from the client to complete the exchange of information. Witnessing a large amount of DNS requests to a single root domain without a significant number of clients connecting to or visiting that domain is very suspicious.
Using RITA and running the command “rita show-beacons-fqdn -H” shows the connections between a local host’s IP address and a destination’s fully qualified domain name. Below are the results for running this on our test dataset:
We can see that there are no local hosts making connections to the domain “cisco-update.com” aside from the DNS queries discovered earlier. This is anomalous behavior and a strong indicator of compromise using DNS.
DNS attacks are quite easy to launch and without the right detection tools, are likely to go undetected.
As always, we encourage you to download the associated PCAP files below and analyze them in a program/tool of your choosing to test your detection abilities.
Because… PCAPs, or it didn’t happen. 😊
The following PCAP files are packet captures taken from the same lab environment over a one-hour time frame and a 24-hour time frame. The files were generated using Wireshark from the target host. The PCAPs are safe, standard PCAP files and do not include any actual malware.
dnscat2 1 Hour Capture
Size: 2.35 MB
SHA256 Checksum: B1056BAAA15C441AA9FADD23885818DB069F3CC5B560DC4F8A184D3494F3D3BD
dnscat2 24 Hour Capture
Size: 82.56 MB
SHA256 Checksum: DC8C0134830076E010479C3F59A6AE0A6BCF3DDD6BD7F5D8C91879E0E0B9C2D5
Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?
You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.
Interested in threat hunting tools? Check out AC-Hunter
Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!
Hannah joined Active Countermeasures as an intern in 2020. She is currently a graduate student at the University of Utah.