In the first demo, I will only use two virtual machines in my lab.
You can easily replicate this on your own.
I will use a Windows VM as the victim and the Kali VM to host the server.
Once the server is running,
I will attempt to establish a direct connection from the victim to the Kali VM.
To get a better understanding of the tool,
we'll quickly go through a hands on demo.
We'll deploy dnscat2.
We will install the client on the victim machine,
and please consider that this might get detected by the antivirus,
which I have disabled in advance. And the server component on the Kali VM.
And then we'll establish a dns tunnel between the two.
I'm currently logged into the Windows victim virtual machine.
And what you're seeing is the Github repository for dnscat2.
All the important information about installing,
configuring and troubleshooting, you can find it here.
After we scroll down a bit through the README file,
there is a specific section called Where to get it.
And here you're presented with multiple options,
including to download the source code from Github and build it
yourself or to download the pre‑built versions.
For this demo, I will use the pre‑compiled versions.
I have already downloaded v0.07 for the client and the server.
One important aspect to keep in mind is that these
versions will be detected by antivirus.
A quick check on virus total shows us that the client version is
detected by 49 out of the 72 antivirus engines.
Now we'll move forward by opening a terminal to launch the dnscat2 client,
which I have already downloaded a copy on the victim virtual machine.
To get acquainted with the command line parameters, you can use ‑h for help.
This will display some of the key parameters
required for establishing a dns tunnel.
But before this, I need to set up dnscat2 server.
Now I will switch to the Kali VM.
I will go through the dnscat2 server directory.
Let's also check the instructions.
On the Github page,
please note that there are specific instructions on how to set up the server.
The author recommends using bundler to manage dependencies,
so I will install it as well.
Now I can install all the required dependencies using sudo bundle install.
And now we should be good to go.
We'll launch the dnscat2 server with the following
command: sudo ruby and then dnscat2.rb.
And as you can see,
there are a couple of warning messages which hinder our usage.
To get rid of this, you can add the ‑W0 to suppress warnings.
By using this, the warnings are no longer displayed.
With the dnscat2 server running, we can also start the client to
connect to our server. For this, we need to explicitly state what
dns server the client will connect to.
And this will be the IP address of the Kali VM. Adding the ‑ping
option will test if there is a dnscat2 server at the specified IP.
And we see we get a positive answer.
Now we can establish the actual direct dns tunnel.
The command is similar to the previous one,
and you only have to remove the ‑ping option.
And we have managed to successfully establish a dns tunnel.
One thing to keep in mind is that we get this information because it's running
in the terminal. In a real attack exercise, this would be invisible to the
victim. To get a better sense of what is happening on the network, we'll open up
Wireshark on the victim machine with the filter for dns, and you can see what
the dns tunnel actually looks like.
Now we'll take a look at the server side. To see the existing
sessions, we'll use the Windows function,
and we can see the session from the Windows 10 victim
machine. To interact with the session, we'll use the window
‑i and then the id of the tunnel,
which is 1 in this case. One of the interesting commands is exec, where
we can execute commands on the victim machine. For testing purposes,
we'll open up the calculator by typing exec and calc.exe. We'll quickly
switch to the victim machine,
where we can see the calculator displayed. In an actual exercise, this
can be used to execute other programs or utilities. Back to the dnscat2
server. To go back and exit the session, you can press ctrl+z. Don't
press ctrl+c or ctrl+x or it will terminate the server. To terminate
processes or session, we can use the kill command followed by the id
number of the session.
Now, there are a couple of aspects where this might not work as
expected, during an actual red team exercise. Due to firewall
restrictions, outbound dns traffic from individual hosts on the
network may be blocked.
An address resolution is done through an internal dns server.
In the direct connection scenario, dns tunneling can be detected by
monitoring clients for increased dns traffic.
In the direct connection scenario, dns tunneling can be detected by
monitoring clients for increased dns traffic.
Next,
we look at the second mode of operation, to connect to the
dnscat2 server by traversing the dns hierarchy.