1. DNS Tunnel Technology Analysis
1 DNS Protocol Parsing Process
The DNS protocol parsing process is divided into two types: iterative query and recursive query.
>
1.1
Iterative Query
The local domain name server sends a request message to the root domain name server, which either provides the IP address or instructs the local domain name server to query another domain name server (let’s call it A) next. The local domain name server sends a request message to the A domain name server, which again either provides the IP address or directs the local domain name server to query a B domain name server. This process continues until the IP address is found.
1.2
Recursive Query
The client queries the local domain name server. If the local server does not have the queried IP address in its cache, it will, on behalf of the client, send a request message to the root domain name server.
The result of the recursive query is either the desired IP address or an error message.
The client sends only one request asking for the final result.
This query to the local domain name server is part of the recursive query.
The local domain name server’s query to the root domain name server is part of the iterative query.
2 DNS Tunnel
DNS tunnel is a type of covert channel that encapsulates other protocols within the DNS protocol for communication. The encapsulation is performed by the client, while the server converts the DNS traffic back into normal traffic.
2.1
DNS Tunnel Attack Implementation Process
Most firewalls and intrusion detection systems allow DNS traffic.
Tunnel attacks exploit this permissive policy and the protocol parsing process.
IP Direct-Connect DNS Tunnel:
This method involves a direct connection between the client and a specified target DNS server (Authoritative NS Server), where data is encoded and encapsulated within the DNS protocol for communication. This method is fast but less covert, making it easier to detect, and has higher restrictions, as many scenarios do not allow specifying the DNS server.
The client uses a UDP socket to establish the connection, effectively utilizing UDP but leveraging port 53.
Domain Name Type DNS Tunnel (Relay):
A relay tunnel implemented through DNS iterative queries, which is more covert. However, because data packets must pass through multiple nodes before reaching the target DNS server, it is significantly slower than a direct connection.
>
(Figure 1-2)
At this time, the PC has been controlled by an attacker and implanted with a Trojan.
The authoritative domain name server of aaa.com is also under the attacker’s control, and the domain aaa.com belongs to the attacker.
Step 1: The controlled PC encapsulates data into a DNS packet, requesting a query for aaa.com from the local domain name server within the LAN.
Step 2: The local domain name server sends a query request through the firewall to the root domain name server.
Step 3: After numerous redirections, the query request ultimately reaches the authoritative domain name server of aaa.com.
Step 4: The authoritative domain name server of aaa.com, under the attacker’s control, parses the incoming DNS packet and sends a response packet.
Step 5: The DNS response packet penetrates the firewall.
Step 6: The DNS response packet enters the intranet.
Step 7: The local domain name server returns the response packet to the controlled PC.
Step 8: The controlled PC parses the data in the DNS response packet to obtain new instructions.
2.2
Typical Malicious Programs
Trojan.Win32.Ismdoor.gen: Utilizes a multi-layer C&C communication protocol structure and DNS tunneling technology, with C&C server commands encoded as IPv6 addresses.
Backdoor.Win32.ClIEcker: Allows the program to receive random types of DNS packets from the server. This Trojan has no logical sub-protocols, only requests for sending and receiving packets.
Backdoor.Win32.Denis: Communicates with DNS servers using only one format of DNS packets, with a summary that limits the response size to 4 bytes. This is merely a regular Trojan downloader that downloads files slowly.
PlugX Remote Control Variant: This backdoor Trojan combines DNS tunneling with PlugX remote control programs to conduct attack control through an established DNS tunnel. By using the DNS request-response mechanism as a command and control channel for attack penetration, it encapsulates C&C server instructions into DNS response packets to control the compromised host. Thanks to the DNS protocol’s characteristics, this Trojan can effectively bypass firewalls and evade standard security detection.
2.3
Classic Attack Events
In May 2016, Palo Alto exposed an APT attack where the Webky team used DNS request-response as a command and control channel for attack penetration. The attackers encapsulated the C&C server’s instructions in DNS response packets.
In March 2017, Cisco’s Talos team discovered an attack named DNSMessenger, where all commands and control communications of the malware were conducted via DNS TXT type queries and responses to evade detection.
As early as the 2012 RSA conference, remote control malware based on DNS protocol was considered one of the six most dangerous future attacks.
2. DNS Tunnel Attack Implementation and Popular Tools Display
DNS covert tunnels mainly encapsulate other protocol traffic to complete transmission.
Since Dan Kaminsky released the DNS covert tunnel tool based on NSTX at the Defcon conference in 2004
Currently, Trojans based on DNS tunnels are divided into two types
IP Over DNS (allowing IP packets transmission through covert tunnels) and TCP Over DNS (providing a hidden tunnel for single TCP communication).
IP Over DNS involves encapsulating IP packets into DNS message constructs. When building DNS covert tunnels, both parties need to address data fragmentation, encapsulation, and reassembly. IP Over DNS commonly uses TUN/TAP devices (virtual network devices in the system kernel) to redirect packets to designated virtual network cards to resolve data fragmentation and reception issues at the sending end.
DNS domain characters are limited to letters a-z, A-Z, 0-9, and ‘-‘ totaling 63 characters. Typically, base32 and base64 encoding are used to encapsulate the information to be transmitted, with a maximum domain name length of 255 characters. Each subdomain can be up to 63 characters long. The sender splits and encodes the covert data, then encapsulates it in the DNS message domain name for transmission. Upon receiving the DNS message, the receiver extracts, decodes, and reassembles the encapsulated information field from the domain name to restore the IP message. The main tools include DNSCat and Iodine.
TCP Over DNS only encapsulates TCP as a transport protocol in the hidden tunnel. Since DNS uses an unreliable UDP protocol, ensuring data isn’t lost or corrupted during transmission requires efficiently balancing transmission efficiency and channel stability. SSH’s port redirection or SOCKS proxy techniques are commonly used to redirect TCP channels into DNS tunnels. Aside from this, TCP Over DNS involves encoding, data segmentation, and reassembly similar to IP Over DNS. Main tools include OzyManDNS and DNS2TCP.
1 Test Platform
Client: Local virtual machine kali x64
Server: VPS (Hong Kong, China)
Local Domain Name Server: Internal company DNS server
Public Domain Name: xxx.xxx.xxx.xx
2 dns2tcp
dns2tcp is developed by Olovier Dembour and Nicolas Collignons using C language. It supports DNS protocol KEY and TXT type requests. Using this tool doesn’t require installing additional TUN/TAP, offering strong usability and practicality.
2.1
dns2tcp Tunnel Establishment Process
Firstly, configure dns2tcp on the VPS.
Open the dns2tcp configuration file, and the modified configuration file is shown in the figure.
Run the command to establish a DNS tunnel; at this point, the dns2tcp server-side is ready.
Now, let’s look at the client side
Here, I’m using Kali, as Kali comes pre-installed with dns2tcp.
(Figure 2-3)
The dns2tcp client command is shown in figure 2-3.
Use the command to create a tunnel and send data, as shown in figure 2-4:
(Figure 2-4)
Then, use the server to send data to the client, as depicted:
We can see the transmission of aaa.txt from the client and test.txt from the server.
Transmission complete, successfully established a data transmission tunnel using dns2tcp
2.2
dns2tcp Packet Analysis
Analyze packets captured with Wireshark
Randomly pick a packet to examine the DNS protocol content in detail
The type I used was TXT for transmission, dns2tcp allows two types, TXT and KEY, with TXT as the default type
If the type changes, the format of base64 + domain name would not change.
The data transmitted through the tunnel before the domain is encrypted using base64
When a DNS tunnel transmits data, it divides the data into several small units and sends them sequentially with minimal time interval. When there’s no data interaction, the two ends of the tunnel still send packets to maintain the communication state, roughly sending one packet every 0.6s, with a maximum interval of 3s, which can be configured.
The packets sent by the dns2tcp tool for establishing tunnels have very obvious features.
The contents of the request and response packets are essentially identical, except the response packet includes a string of base64 encrypted data.
(Figure 2-8)
2.3
Summary
Client transmits data using the domain prefix with TXT record type (this type can be altered using dns2tcp parameters), and both the domain prefix and response content are encrypted using base64.
From the packet-sending behavior, it can be observed that during data transmission—such large data-interaction operations—
3 Iodine
Iodine is currently an active and widely known DNS tunneling tool, with platform coverage that includes Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, and Windows, even with an Android client. However, TUN/TAP installation is required. The official documentation claims upstream speeds of up to 680 kbit/s, with a downstream ceiling reaching 2.3 Mbit/s.
3.1
Iodine Tunnel Establishment Process
First, add an NS record
Here, ns.xxx.xxx is set to point to www.xxx.xxx. To resolve ns.xxx.xxx, this subdomain must visit the domain server of www.xxx.xxx
The server start command is shown as follows:
Iodine provides a nice feature to query online whether the established tunnel is effective.
The server’s tunnel is successfully established
At this time, a virtual network card named dns0 will be generated.
The client inputs a command to establish the tunnel
Now, looking at the C&C server, data transmission is in progress
Tunnel establishment with Iodine is complete
3.2
Iodine Packet Analysis
Analyze the packets captured
By default, Iodine uses TXT and NULL types for sending data, supporting various query request types like NULL, TXT, SRV, MX, CNAME, and A.
Randomly find a request packet
Check its queries field
We find encrypted data before ns.xxx.xxx, with Iodine supporting multiple encoding schemes like base32, base64, and base128. The transmission used the NULL type
Next, use ID to check its response packet
We can observe that in this packet, Iodine used the NULL type for response. Here is the encrypted data we transmitted
Iodine has excellent performance, with very high speeds. Checking the official document’s explanation, the test results are also impressive, measured in kbit/s
3.3
Summary
Iodine is quite similar to dns2tcp. In fact, these DNS tunnel tools are largely similar. Packet capture analysis shows that the DNS tunnel’s content is encrypted, and upload-download frequencies are high.
Iodine’s portability is strong, running on various UNIX-like systems and Win32. It can establish tunnels between two hosts.
With Iodine, operations are straightforward, automatically handling IP numbers on the interface, with up to 16 users able to share a server simultaneously.
4 Dnscat2
Dnscat2 is positioned as an encrypted command and control (C&C) channel embedded within the DNS protocol. Like others, it adopts a C/S architecture, with the client on the infected host and the server on the authoritative domain name server.
4.1
Dnscat2 Tunnel Establishment Process
The server-side of Dnscat2 employs an interactive mode, inspired by Metasploit and Meterpreter. Its operation is indeed similar to these tools.
First, the server creates a tunnel. You can see Dnscat2 printed a lot of information, including instructions for the client to establish the tunnel.
Use the client command to establish a DNS tunnel
Session established is displayed. The tunnel has been successfully set up.
Look back at the server, and the tunnel has been successfully established (Window 1)
We then issue the session command on the VPS to check this tunnel
Use the help command to see the built-in functions of the dnscat2 tool
Try using session –i 1 to create a new command window, then use the ping command for testing.
You can see “Pong!” returned, indicating successful execution.
Back to the client
Data is shown.
4.2
Dnscat2 Packet Analysis
Analyse packets captured
Select a random packet and examine its request package
Then check the queries field
You can see that the encrypted domain name starts with dnscat styling. This packet uses the CNAME type
Next, look at the response packet with the same ID
Where the answers field contains
4.3
Summary
Dnscat2 differs from other DNS tunnel tools by providing commands, executed in window forms, for performing various tasks.
Packet analysis reveals that Dnscat2 uses encrypted means to obscure the C&C server domain name, enhancing its stealth.
3. Detecting DNS Tunnel Trojans
Analyze DNS tunnel Trojan sessions based on three communication behaviors.
1 Total Number of Packets in DNS Session
Normal DNS sessions are brief, ending with the conclusion of a DNS resolution task.
DNS tunnel Trojan sessions conclude alongside the Trojan’s lifecycle. Throughout the lifecycle, it sends heartbeat packets, transfers information, resource files, etc., behavior to the C&C server. The C&C server also sends control instructions. Hence, DNS message counts are high in DNS tunnel Trojan sessions.
2 Tunnel Message Type
In normal DNS traffic, A record type traffic accounts for 20%-30%, CNAME record for 38%-48%, AAAA record for 25%, NS record only 5%, and TXT record only 1%-2%. However, for higher bandwidth, some DNS covert channels like Iodine, in their default configuration, use lesser-used record types like TXT or NULL.
3 Fixed Domain Name Portion Remains Unchanged
In DNS tunnel messages, only the subdomain changes.
However, in Dnscat2, the root domain is also encrypted and continuously changes, albeit with a distinct marker.
