DNS Tunneling with dnscat2
We can use dnscat2 to exfiltrate data with DNS subdomain queries
and infiltrate data with TXT, and other records.
A dnscat2 server runs on an authoritative name server for a particular domain,
and clients, which are configured to make queries to that domain,
are run on compromised machines.
Let’s try out dnscat2.
We’ll inspect traffic from FELINEAUTHORITY with tcpdump,
filtering specifically on UDP port 53.
We’ll kill our existing Dnsmasq process with a Ctrl + c,
and run dnscat2-server instead,
passing the feline.corp domain as the only argument.
This indicates that the dnscat2 server is listening on all interfaces on UDP/53.
Now that our server is set up,
we’ll move to PGDATABASE01 to run the dnscat2 client binary.
The binary is already on the server for this exercise.
However, we could have transferred the binary from our Kali machine
to PGDATABASE01 via our SSH connection using SCP.
We’ll run the dnscat2 client binary from the database_admin home folder,
with the feline.corp domain passed as the only argument.
The dnscat2 client reports that a session has been established.
We can check for connections back on our dnscat2 server.
Our session is connected!
DNS is working exactly as expected.
Requests from PGDATABASE01 are being resolved by MULTISERVER03,
and end up on FELINEAUTHORITY.
We can use our tcpdump process to monitor the DNS requests to feline.corp:
The dnscat2 process is using CNAME, TXT, and MX queries and responses.
As indicated by this network data, DNS tunneling is certainly not stealthy!
This output reveals a huge data transfer from the dnscat2 client to the server.
All the request and response payloads are encrypted,
so it’s not particularly beneficial to keep logging the traffic.
We’ll go ahead and kill tcpdump with Ctrl + c.
Now we’ll start interacting with our session from the dnscat2 server.
Let’s list all the active windows with the windows command,
then run window -i from our new “command” shell to list the available commands.
This returns a prompt with a “command” prefix.
This is the dnscat2 command session, and it supports quite a few options.
We can learn more about each command by running it with the --help flag.
Since we’re trying to tunnel in this Module,
let’s investigate the port forwarding options.
We can use listen to set up a listening port on our dnscat2 server,
and push TCP traffic through our DNS tunnel,
where it will be decapsulated and pushed to a socket we specify.
Let’s run listen --help.
According to the help message output, listen operates much like ssh -L…
And we should be very familiar with that by now.
Let’s try to connect to the SMB port on HRSHARES,
this time through our DNS tunnel.
We’ll set up a local port forward,
listening on 4455 on the loopback interface of FELINEAUTHORITY,
and forwarding to 445 on HRSHARES.
From another shell on FELINEAUTHORITY
we can list the SMB shares through this port forward.
The connection is slower than a direct connection,
but this is expected given that our SMB packets are being transported
through the dnscat2 DNS tunnel.
TCP-based SMB packets, encapsulated in DNS requests & responses transported over UDP,
are pinging back and forth to the SMB server on HRSHARES,
deep in the internal network.
Excellent!
In this Learning Unit we used dnscat2
to tunnel SMB traffic through DNS requests and responses.
We used that to list the available shares on a host deep inside the internal network
despite the fact that neither HRSHARES nor PGDATABASE01
had direct connectivity to our FELINEAUTHORITY server.