I added DNS Communication to Cobalt Strike in June 2013 and refined it further in July 2013. On sales calls and at conferences I get a lot of questions and compliments on this feature. That’s great.

I’ve also heard the opposite. I’ve heard folks say that DNS Command and Control is noisy. It’s “easy to detect”. I’ve had someone go so far as to say that it’s a gimmick.

I have a philosophy: I like options. I have a preferred way to work. I stay aware of how this preferred way may break down. When this happens, I like to know I can still work and get things done. Cobalt Strike’s DNS C2 is a great example of how this philosophy influences my development choices.

I released Beacon in the 27 Sept 2012 release of Cobalt Strike. This first Beacon could beacon over DNS or HTTP. The DNS beacon would periodically make an A record request to a domain that I, the attacker, am authoritative for. My server would provide a response that told the Beacon whether or not it should make an HTTP request to download its tasks. I built this Beacon for stealth. By checking for requests with DNS, I limit how often my compromised systems need to connect directly to me.

The above is not easy to detect. I’ve had folks tell me that they see this behavior in production. One A record request every 24-hours or week is not trivial to find. This is scary.

In the first half of 2013 I had several opportunities to use Cobalt Strike. I took advantage of the DNS Beacon as a persistent agent. During this time I ran into a scenario I call “the child in the well”. I would see a compromised host beacon, but it would never connect to me to download its tasks. This is a terrible situation. My compromised system can call out to me. I know it’s there. But, I can’t reach it. This happened to me twice and I knew I needed to do something about it.

I added a mode command to the DNS Beacon. This command allows the end-user to state which data channel Beacon should use to download its tasks. When a tasking is available, I communicate this channel preference to the DNS Beacon in my 4-byte A record response.

I added modes to communicate over HTTP, DNS A records, and DNS TXT records. Each of these channels has their purpose and I allow the user to switch back and forth between them for each deployed DNS Beacon.

The HTTP data channel is the default. The compromised system connects to me with a GET request to download its tasks. It uses a POST request to send output when it’s available.

If I run into a child in the well scenario I have a choice between the two DNS data channels.

I used to use Beacon primarily as a lifeline to send sessions to other team servers. The A record channel is in the spirit of this original use case. I can task the Beacon and it will download its tasking 4-bytes at a time. If the system can Beacon to me, then I have some option to control it. The A record data channel isn’t efficient, but it works in a pinch.

I added the TXT record channel at the same time I built a SOCKS proxy server into Beacon. This was July 2012. I built these capabilities into Beacon to keep with an offense in depth philosophy. If I can’t get out of a network on any channel, except DNS, I need a way to continue to work. I saw pivoting as essential to this and so I built the SOCKS proxy server. The TXT record channel is suitable for tunneling some traffic through a Beacon.

I hope this post helps shine light on how I use DNS for covert communication. As a beacon with a high sleep time–it’s stealthy. As a data channel, it’s useful when there are no other options. Which option makes sense will depend on your context. The ability to rationalize context to tool comes from mature tradecraft.

[youtube https://www.youtube.com/watch?v=Ex_bvwMDDbQ]