Dnsmasq is a lightweight utility that provides network infrastructure for small networks: DNS, DHCP, router advertisement and network boot.
Dnsmasq accepts DNS queries and either answers them from a small, local, cache or forwards them to a real, recursive, DNS server.

When performing red team operations it is important to have a large arsenal in your disposal which can be used according to the scenario, objectives and versatility needed. One of the tools that can be useed is DNSMasq.

Cobalt Strike Beacon

The DNS beacon offered by Cobalt Strike is a great way to smuggle communications in and out strict egress firewall environments. As communication takes place either via DNS A, DNS AAAA or DNS TXT records it might be possible to get around the firewall policies.

Raphael Mudge breaks down this functionality in this video

Cobalt Strike beacon through DNSMasq

Using a DNS beacon requires a backend server which will handle the DNS requests in this case the Cobalt Strike C2 server. When dealing with a capable blue team it can be fairly easy for them to observe the DNS requests or payload communication and block the IP of the server serving the payload therefore killing this communication channel for the red team. This is where redirectors come into play. The DNS redirector will stand in-between the C2 server and the client. It is important to also note that more than one redirectors can be used to obscure the infrastructure even more.

The idea behind this method is to “hide” the server hosting the DNS beacon i.e the Cobalt Strike server. This can be done in multiple ways including SOCAT and IPTABLES which I presented in my BSides Cyprus 2019 talk. The slides and commands from my talk are here.

This post is about DNSMasq which I did not cover during my talk and offers a very intuitive way to do the redirections. Although not recommended for live operations, DNSMasq allows for redirecting multiple domains therefore one redirector can be used for multiple campaigns at the same time. I usually make use of this capability during the testing of the infrastructure and not during real client engagements.

Also note that this is a barebone setup not taking into consideration securing the infrastructure at all so exercise due diligence when spinning up your own infrastructure for live engagements.

The setup is as follows:

• Cloud server acting as the redirector
• On-premise C2 hosting the DNS payload

Of course the above setup type is not mandatory and can be adjusted according to your operational needs and constraints.

We first need to create the A record for the domain which will resolve back to the DNS cloud redirector instead of the Cobalt Strike server. Second we need to create 2 NS records pointing at the A record of the redirector domain. For example:

• dns.testdomain.com – A Record
• malware1.testdomain.com -> dns.testdomain.com
• malware2.testdomain.com -> dns.testdomain.com

Through this method, the backend IP of the C2 server will not appear in any logs and if someone queries the DNS records of the testdomain.com will only see the IPs of the redirector. If the blue team performs such analysis they will only be able to see and block the IP of the redirector and allow us to spin up a new one to continue the operations.

The configuration for the Cobalt Strike beacon should look like the below.

Let’s assume that the Cobalt Strike server has the public IP of 195.45.65.45. If we proceed with the attack it will never work as the DNS hosts configured in Cobalt Strike do not point back to the C2 IP, remember these A and NS records point to the redirector. For this to work we need a redirector which will accept these requests and forward them back to the Cobalt Strike server and this is where DNSMasq comes into play.

Cloud redirector setup

Install DNSMasq if not already installed

 apt update
apt install dnsmasq 

On Ubuntu systemd-resolv runs on port UDP 53 by default which will not allow DNSMasq to bind on this port therefore it needs to be stopped and disabled first.

To disable systemd-resolv

 sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
rm /etc/resolv.conf

The configuration file for DNSMasq is in:

/etc/dnsmasq.conf

Before changing any of the configuration first change the DNS server that will be used for resolving DNS queries

nano /etc/resolv.conf

And add the local DNS server so that that resolving is handled by the local DNS server i.e DNSMasq

echo "nameserver 127.0.0.1" > /etc/resolv.conf

Only a couple lines in the dnsmasq config file are enough for this to work.

no-resolv
no-hosts
listen-address=[External IP],127.0.0.1
server=/testdomain.com/[C2 IP]

The first line tells DNSMasq not to use resolv.
The second line tells dnsmasq not to use the hosts file. The third line tells dnsmasq on which interfaces to listen. Since we want to respond to external queries it is important to also indicate the public IP. The last line is a wildcard to send all DNS requests coming in ending in testdomain.com to the C2 IP where our DNS server is located. This offers great versatility as new NS records can be defined without needing to make any changes to the DNSMasq configuration as the wildcard will pick these up as well.

DNSMasq has many other options so make sure you check them out as well.

I always like to run a packet capture on the redirector to monitor the incoming DNS requests and make sure that all the redirections work fine.

tcpdump -i eth0 udp port 53

To test that the redirection works run the following command and hope that the famous 0.0.0.0 answer comes back meaning that we could successfully reach the C2 DNS server.

nslookup demo.test.testdomain.com

I tried tracing the DNS requests with dig +trace to see if the Cobalt Strike server IP appears anywhere but as DNSMasq on the redirector provides the responses back and none of the responses come directly from the CS server the IP did not appear.

And that is it!

For any questions or comments hit me up on Twitter.