DNS Tunneling with dnscat2
dnscat2 is a very popular and well-known DNS tunneling utility.
It can tunnel traffic through multiple DNS records,
such as A, TXT, and NS records.
It also includes a built-in command shell and can tunnel custom IP traffic
to multiple locations.
In addition, we can run the dnscat2 client with standard user privileges
as it does not require client-side drivers.
To perform DNS tunneling with dnscat2, we need to perform some configuration
on the Ubuntu machine, which will act as the lab’s primary DNS server.
As noted in the previous section, all subdomain lookup requests
for a specific domain should go to our DNS tunneling server,
which acts as the authoritative name server for that domain.
In the lab, we’ll use a simple dnsmasq DNS server & configure it to forward requests
We’ll use tunnel.com as an example domain for this demonstration.
The following diagram visualizes the roles of each node in the DNS lab setup
We’ll need to edit the /etc/dnsmasq.conf file on the Ubuntu machine
and append our entries.
We must specify the DNS servers for specific domains in a standard format
and use the IP address of our Kali machine.
After making the configuration changes, we must restart the dnsmasq service.
Next we’ll install dnscat2 on our Kali machine.
At this point, we have to start dnscat2-server
for our example tunnel.com domain.
It will ask for our password to elevate to root.
Next, we’ll switch to the Windows machine,
and start dnscat2 from the Desktop,
specifying the domain we are using for the tunnel.
dnscat2 will encrypt connections by default,
but we may also specify our own pre-shared key if we like.
Once a connection is established, dnscat2 will display a
“short authentication string” which can be used to detect MiTM attacks.
We'll verify this authintication string on both sides.
We confirm that the authentication string is the same.
We can start interacting with our client after attaching to the session using the
session -i command:
Next, we’ll run an interactive shell with the shell command.
This will create a new session
so we will need to switch to it in order to execute commands.
Our interactive shell is working flawlessly.
Very nice.
dnscat2 also supports TCP/IP tunnels over DNS.
That means we can create a tunnel back to the victim machine so that we can RDP
into it from our Kali system.
Let’s try this by redirecting our local port 3389 to the Windows machine’s IP.
Once the tunnel is created, we can rdesktop to our Kali host
and interact with the RDP session on the Windows machine.
Since the traffic is tunneled over DNS, the session will be slow, but functional.
Now that everything is working, let’s launch Wireshark,
and filter for DNS to inspect the DNS traffic hitting our Kali machine.
This is definitely “interesting” DNS traffic.
Each of the requests contains very long and seemingly random domain names.
If we look at the packet details,
we can see that both the requests and the replies are quite lengthy,
and they include our hexencoded traffic.
Despite the fact that dnscat2 produces an anomalous DNS traffic pattern,
it is still less anomalous than a standard command shell.