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 188.8.131.52. 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:
Before changing any of the configuration first change the DNS server that will be used for resolving DNS queries
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.
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.