top of page


"blogger, InfoSec specialist, super hero ... and all round good guy" 



Into the Rabbit Hole – Offensive DNS Tunneling Rootkits

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.

What is DNS?

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 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 rather than typing in the IP Address of

How DNS Tunneling Attacks Work

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.

Figure 1: Domain Name System Tunneling

Step 1: Getting a Public Server

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 that 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.

Step 2: Registering a Domain

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.)

Step 3: Running the Software

Attackers will then run their malicious server software on these public servers. For some DNS tunneling applications, client software is needed as well. Attackers distribute the client software through phishing emails, Office-enabled macro documents, or javascript applets loaded onto malicious websites. The client software that runs on the victim machine can be as elaborate as a full EXE program, or as stealthy as a PowerShell or Python script.

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:

  • DNScat2 (

  • Iodine (

  • Heyoka (

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.

Installing dnscat2

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

# 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.

Figure 2: Setting security to open

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 endpoint EDR 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.

Figure 3: Connecting the client to the server

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.

Figure 4: Wireshark showing DNS messages communicating with the C2 server

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.

Figure 5: List of dnscat2 commands

In most cases, attackers will have the same rights, access, and privileges to whatever user or service that the client software was logged on in order to connect to the command and control server.

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.

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. Attackers will always try new and more complicated techniques to try to bypass your security devices.


bottom of page