That’ll never work–we don’t allow port 53 out

June 20, 2013

One of my favorite Cobalt Strike features is its ability to quietly manage a compromised system with DNS. Being rather proud of this feature, I talk about it a lot. During some conversations, I’ve heard the response “that’ll never work, we don’t allow port 53 out, unless it’s our internal DNS server”. To which I reply, “That does not matter, if I get code execution on a system that can resolve an internet host, then I can control that system”.

Here’s how:

Cobalt Strike ships with a DNS server. When I create a listener for the DNS Beacon, this server is started for me.

Sitting at a random place on the internet, this DNS server is useless. To have use, this server must become part of the “hierarchical distributed naming system for computers, services, and resources connected to the Internet” [ref]. The thing we lovingly refer to as the Domain Name System.

How do I make my server part of the DNS system? I register a domain and delegate my Cobalt Strike system as the authoritative DNS server for that domain (or some subdomain).


malwarec2.losenolove.com is authoritative for several losenolove.com subdomains

To communicate with me, a compromised system will make a DNS request for a host in a domain that I am authoritative for. Likely, this compromised system will send the DNS request to your internal DNS server. If a request is not in your internal DNS server’s cache, your server will either forward the request to another server or work to iteratively find out which DNS server may answer for the requested host. Since I’m authoritative for the domain the requested host is in, I get the request, and I get to provide the answer.


A query in action, try dig +trace whatever.somedomain.com

This capability is all well and good, but how do I use it? Cobalt Strike’s Beacon has two DNS communication strategies. Which strategy makes sense depends on your situation.

Hybrid DNS/HTTP Communication

By default, DNS Beacon uses DNS as a beacon and HTTP as a data channel. Every sixty seconds (or some other user controlled time), the compromised system will make an A record request for an attacker controlled domain. Embedded in the requested hostname is a number, unique to that Beacon instance.

Hybrid HTTP/DNS Communication

When Cobalt Strike’s DNS server gets the request, it checks if any tasks are available for that Beacon instance. If no tasks are available, it returns a response that tells Beacon to go to sleep.

If a task is available, the Cobalt Strike DNS server returns an IP address. The compromised system then connects to that IP address and makes an HTTP GET request to download its tasks. The tasks are encrypted.

This is the hybrid communication model. The idea here is that DNS requests on a regular interval are less likely to get noticed than, say, HTTP requests on a regular interval.

Pure DNS Communication

The hybrid beacon offers a quieter way to hold access to a compromised system than other tools in the pen tester’s arsenal. But, what happens when DNS is the only way out?

DNS Beacon may use DNS as a data channel. Every sixty seconds (or, again, some user controlled time), the compromised system makes an A record request for an attacker controlled domain. Again, embedded in this request is a number, unique to that Beacon instance.

If a task is available and the user instructed that Beacon to use DNS as a data channel, the Cobalt Strike DNS server returns an IP address with special meaning to the Beacon agent. The compromised system then makes several requests to an attacker controlled domain to push metadata about the compromised host, download tasks, and upload any output.


How does this happen? Well, let’s take a look at an A record request. An IP address is a 4-byte integer. Right? If a compromised system makes 100 requests for hosts in a domain the attacker is authoritative for, then the attacker can push 400 bytes of data.

A records don’t carry a lot of information, but there are alternatives. For example, a AAAA record for an IPv6 address is 16 bytes of information. A TXT record is up to 255 printable characters.

So far, this communication is one way. The compromised system is making many requests to an attacker controlled domain to download information. How do we go the other way?

The requested host is Beacon’s opportunity to send information.

To post output, the Beacon agent encodes its encrypted output into a DNS-safe form and makes a request for [encoded output].someattackercontrolleddomain.com. Each request can only hold so much data. Beacon makes as many DNS requests as necessary to send data back to me.

Of course, there are things that can go wrong. For example, if Beacon constantly requests the same host, another server will cache the response. To manage this, Beacon encodes a nonce into each request. It’s also possible for a query attempt to timeout, disrupting the transaction. Cobalt Strike’s DNS communication code is written to detect this situation and recover from it.

By making requests to an attacker controlled domain, it’s possible to indirectly control a compromised system–egress restrictions be damned.

When I added DNS as a data channel, my intent was to provide a fallback option for situations where the compromised system can’t download tasks over HTTP. The DNS data channel allows you to recover your Beacon in these situations. You may switch between the hybrid DNS/HTTP communication and pure DNS communication as needed.

While not the subject of this post, Cobalt Strike also includes a stager that will download Beacon via DNS TXT record requests and inject it into memory.

But, I bought Vendor X’s solution?

Are there mitigations and technologies to detect or stop this form of communication? Absolutely. If you have these mitigations in place, have you tested them? If you have a process to detect anomalous DNS traffic and act on it, have you exercised it? This is the point of a penetration test. To test your assumptions against a thinking attacker. The purpose of a threat emulation tool, like Cobalt Strike, is to arm penetration testers with tools to execute these attacks.



  1. A really stupid marketing strategy for something they want $2500/yr for – really stupid they want $2500/yr – I’d offer $25 for lifetime license because only a scammer would really need this crap a) for the “successful” attack report to buffalo businesses with bullshit – otherwise fuck port 53 – this is not a pentesting tool it is malware installed after the exploit and. b) only dumbass corporations would use or pay for this shit to control compromised systems of places that have IT depts that typically ignore port 53 and requested DNS traffic, which even the vendor themselves say it is quieter when you don’t use DNS as a data channel but use both DNS and HTTP requests because (because they need HTTP GET/POST) but those 100 DNS requests for 400 bytes of data channel would be pretty goofy to an attacker and make pretty fucking loud network traffic transfering 4 bytes a request – by the A-record!!! It is not even good malware!!

    • Thanks for taking the time to share your insight. I have to disagree with your comment that Beacon is malware installed after an exploit. It’s not installed at all (unless the user installs it). It’s a payload, like meterpreter. It’s injected into memory via whatever attack vector was used to deliver it.

      I agree that DNS as a channel has its drawbacks. This is why I designed Beacon’s DNS C2 as a fallback. When HTTP is allowed out, the hybrid DNS/HTTP Beacon is good enough and Cobalt Strike has had that for awhile. When I’m participating in an exercise or an engagement, I like to have options. In March, I ran into a situation where I had a compromised system beaconing home, but due to some defensive measure taken, the agent couldn’t connect to me to download its tasks. This was the inspiration for the DNS C2 in Beacon. If I had the implementation that I have now, I could have asked Beacon to use DNS as a data channel, and set to work finding another egress channel out of that network.

      During another exercise I participated in, I had a prototype of this DNS Beacon. In this other exercise, egress is always very difficult, maybe artificially so, but that’s the game I’m asked to play. Where other tools failed, the DNS communication capability was sufficient to defeat the layers of defenses myself and my colleagues had to contend with. Again, is it going to become standard operating procedure to communicate via DNS? Definitely not. But, when DNS is the only way out, I want to know I can still work.

      What’s the value of a toolset like this? Again, it’s to give penetration testers an option to prove it’s possible. The organizations we serve expect that we have sorcerer’s powers and the same tools the most well funded attackers have. If we can’t do something, to our customers, it’s not possible. By giving pen testers tools closer to what’s used to attack their customers, I’m equipping them to better demonstrate risk and test assumptions, even against a mature security program.

  2. I’m not sure if you’re already doing this, but it might be cool to have the DNS server return enciphered IP addresses when resolving, which clients can then deterministically decrypt. Adds a bit more confusion to anyone who happens to inspect the DNS traffic.

    • Thanks for the suggestion. Speaking to the hybrid Beacon, I wanted to create something that looked like a natural traffic pattern. An A record request followed by an HTTP GET to the returned address is natural. If I return a false address and then connect to the real one, there’s still an opportunity to see the real address.

  3. @ Brett Woodward I would have to disagree as well. When you are pentesting in a secure environment DNS can be the only way out. So yea you have to exploit first and if you are running a typical payload you will you will not get anywhere because the firewall blocks attempts to get a shell. With this you do and yea if you are staring at the DNS packets it will look funny but who does that in a real environment, firewalls typically are not smart enough to block valid DNS with hidden data.

  4. The question I have is this – what tools are out there to mitigate this? DNS back channel communications are what keep me awake at night. You’ve put a finger on the one area that is, in all companies, wide open. My company passes 5gigs of DNS to the Internet per day.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 11,412 other followers