FortiGuard Labs Threat Research Report
Affected platforms: Windows 7, Windows 10, Windows Server 2016
Impacted parties: Windows 10 version 1809 + and Windows Server version 1903 +
Impact: Command and Control & User-Privacy Settings Violation
Severity level: Informational
Other: Other systems that use DNS may be affected if client-side exploit is available
At FortiGuard Labs, we see numerous evasion techniques that attackers use to bypass egress filtering solutions and establish command and control (C&C) within organizations. These targeted organizations typically have firewalls, IPS systems, end-point detection, and remediation protection all within their organization.
In this blog, we will discuss one of them which is DNS tunneling and how it works. We will look at well-known DNS tunneling attack rootkits and how to configure them to test the security and detection capabilities in your environment. Lastly, we will review some industry best practices and show how the FortiGuard Labs Threat Intelligence Services embedded in our products mitigate this attack.
DNS Tunneling occurs when attackers encode and embed data and protocols in DNS traffic, primarily to achieve command and control inside an organization’s protected network. In addition to command and control, attackers also use DNS tunneling to deliver and distribute malicious payloads, such as remote access trojans and ransomware, to victim computers inside an organization.
Domain Name System, or DNS, is essential to how the Internet works, it is the “phone book” of the Internet. Most people cannot remember to type in the IP address 126.96.36.199 in their web browser to get to Google. DNS maps these IP addresses to (in often cases) human-readable domain names. In this case, a user can easily remember Google.com rather than typing in the IP Address of 188.8.131.52.
DNS Tunneling attacks take advantage of almost every device on the internal network behind a firewall that allows outbound access to resolve DNS requests. One of the reasons DNS Tunneling attacks work is that organizations often do not filter those outbound DNS requests.
The attack itself adds malicious payloads and commands to a trusted DNS. Additionally, compromised hosts don’t actually need external Internet access to be attacked. If they simply have access to internal DNS servers, and if those internal DNS servers have access to the Internet, in some cases this is enough to enable the machine to receive DNS responses with malicious data. This means attacks to machines that are normally considered to be “air gapped,” but still allow DNS queries to a DNS server with external access, may be vulnerable to this type of attack.
Attackers understand this weakness and take advantage of this. They start by running an offensive DNS tunneling app on a public server, such as one obtained from a virtual private server (VPS) service provider. The reason attackers do this is because they need to configure their attack on a server that is publicly accessible on the Internet. Advanced attackers may use compromised machines, servers, and web sites to achieve this instead of using a VPS. The only requirement they need is for the server to be accessible, and for it to be able to run their DNS Tunneling attack software.
They then register a public domain with a domain registrar and set the authoritative DNS to the publicly accessible server they obtained in step 1. (Read more details on this below.)
When attackers compromise a client and run the software on the victim’s machine, they will typically specify a domain name. All requests will be sent to the local DNS server, which will then be redirected to the authoritative DNS server for that domain. The attacker controls the authoritative DNS (which commonly is their command and control server). This is the reason why attackers will register their own domain, as we described in step 1.
Cybersecurity defenders use DNS toolkits to test their ability to detect and stop DNS tunneling attacks. The tools and methods we described are optimized for defenders to not only understand how DNS tunneling attacks work, but to also determine if an organization can detect an attack when it occurs, and if they can stop that attack. The most common DNS Tunneling toolkits in use today by defenders include:
Each one of these DNS tunneling rootkits has its advantages and disadvantages. For example, DNScat2 provides built-in encryption and is very simple to use. In exchange, it sacrifices performance and session management and is limited to only tunneling TCP traffic.
Iodine is extraordinarily efficient, and generally has a faster response. However, it only supports IPv4 and does not provide encryption. Attackers can also incorporate other tools, such as VPN or TOR services, into their attack toolkit. In addition, all of these tools are being changed and improved upon continually since they are open-source resources.
DNScat2 is a toolkit many organizations use for red team/blue team exercises when they are trying to determine if they can detect and stop DNS tunneling attacks within their organization. DNScat2, according to their own GitHub repository, is described as an attack tool designed to create an encrypted command-and-control (C&C) channel over the DNS protocol. The software has two components: a client and a server.
Let’s take a closer look at how organizations might use this tool in a configuration that is similar to how it is used by security operation centers (SOCs) and other security teams to test their detection capabilities. Here are the basic commands to install dnscat2 on a Ubuntu/Debian system:
# apt-get update
# apt-get -y install ruby-dev git make g++
# apt install ruby-full
# apt-get install snap
# gem install bundler
# git clone https://github.com/iagox86/dnscat2.git
# cd dnscat2/server
# bundle install
Next, run the command lsof -i -P -n | grep LISTEN and ensure you have no conflicts or no other services running on port 53:
# cd dnscat2/server
# ruby ./dnscat2.rb
# set security=open
Note: we are running the program in this example without encryption. I recommend testing this in your environment with security open at first to ensure you have the program running correctly. Then, once you are sure it is operating the way you want, turn on encryption.
Next, we need to have the client connect back to the server. There are multiple ways an attacker may decide how to accomplish this to be stealthy and evade standard detection protocols. In this case, we will manually connect the client to our server using the details in Figure 2, below.
Keep in mind that threat-actors will be more challenging to detect. They may use a combination of PowerShell, Python, or Macro-based attacks. Tools such as FortiEDR can do a great job at catching some of these attacks as they attempt to connect to external command and control systems and process and execute commands.
Once the client is connected, running Wireshark shows DNS messages communicating to our command and control server. In this case, since we are not running encryption, we can examine specific messages and commands in our DNS traffic. You can see that by being connected to the command and control server we are generating lots of DNS traffic across our network. When you enable encryption, it is much more difficult to examine the attack.
Attackers will use different types of DNS record types in which to embed their attack. TXT records are often used because they have the largest and most diverse payload structure.
The program dnscat2 allows attackers to execute numerous commands, run a windows shell, upload or download data (or additional malware), and control vital functions of the victim’s Windows machine.
In most cases, attackers will have the same rights, access, and privileges to whatever user or service that the client software was logged on to in order to connect to the command and control server.
FortiGuard Labs is the global threat intelligence and research organization at Fortinet. Our researchers are trying to keep one step ahead of attackers by understanding how their attacks work from a network and host perspective. This enables us to design effective detection and mitigation techniques. We spend thousands of hours looking at packet captures, investigating real-world attacks, and understanding how various toolkits and methods work.
However, as attacks get more complex, so must the research we use to detect them. Over a decade ago, FortiGuard Labs started thinking about detecting malware in archived files. Today, we have active research into identifying malware using multiple artificial neural networks, detecting and classifying malware from memory semantic analysis, and many other techniques.
What does this mean for our customers and how does this relate to protecting you against DNS tunneling threats? It means that when you enable a signature or turn on a protection engine, that “enable” button has a lot of research behind it. I am not saying the patents linked above directly impact our DNS tunneling signatures, but what it does showcase is how we are always thinking about advanced attacks—even those that may be using encryption and other evasion techniques—and planning how we can detect and stop them.
As malware evolves and tries to evade standard inspection protocols, we have in place, and are continuing to develop new techniques to inspect files. As attackers migrate to fileless malware and in-memory attacks, we have multiple technologies to examine the attack and, in some cases, even make it available for forensic analysis. And as attackers modify their techniques, we have machine learning and artificial intelligence-based systems working to understand the attacks and help us formulate a response.
Below is a screenshot of our IPS signature for dnscat2. It disrupts the attacker’s ability to maintain command and control. In many cases, this IPS signature will stop the attack from working correctly or at all.
If attacks do occur, attackers will use command and control to execute commands on the victim’s machine. Attacks vary based on the endgame of the attacker. In many cases, attackers are trying to exfiltrate data or execute ransomware.
Next-gen endpoint protection agents, such as FortiEDR, can stop malicious commands being executed.
Attackers, if they are successful in establishing command and control, will often try and run more malicious commands or malware, such as ransomware on the endpoint. FortiResponder can block the file encryption process and provide forensic evidence for examining the nature of the attack. In the example above, as a malicious process attempts to encrypt files on disk, it is blocked in real-time.
Attackers will always try new and more complicated techniques to try to bypass your security devices. Thousands of hours of research around these attacks are conducted by FortiGuard Labs each year with one goal in mind: to keep you covered.