Many networks are like sieves. A reverse TCP payload or an HTTP/S connection is all it takes to get out. Once in a while, you have to whip out the kung-fu to escape a network. For these situations, DNS is a tempting option. If a system can resolve a hostname, then that host can communicate with you.

Unfortunately for penetration testers, our options to exfiltrate data and control a payload with DNS are…  limited. Well, until today. Cobalt Strike users now have the ability to control Beacon, entirely over DNS.

Beacon is Cobalt Strike’s payload for red team operations. It executes commands, logs keystrokes, uploads files, downloads files, and spawns other payloads when needed. Its communication is asynchronous, meaning it simulates a low and slow actor, by calling home at set intervals.

Beacon has always had the ability to check for tasks over DNS, but it’s always relied on HTTP as a data channel. At Western Regional CCDC, I ran into a situation where I saw the need for additional flexibility. Towards the end of the event, the second place team was still beaconing back to a node in Amazon’s EC2. Unfortunately, their network setup did not allow Beacon to connect to us and download its tasks. I call this a child in the well scenario. The target’s system is beaconing home, letting you know it’s owned, but it can’t get to you, and you can’t get to it–making it impossible to work with the system.

Steps 2-4 may now happen over DNS

As tempting as DNS is, it’s not without its drawbacks. Communication over DNS is slower than other options. It’s also difficult to graft a communication protocol on top of DNS in a non-obvious way. Seemingly small data transfers require many DNS requests to complete. In short–if someone looks closely enough, they’ll see you. I’ve always wanted the ability to control a system with DNS, but only when I need it. If another protocol makes sense, I’d prefer to use that instead.

Inspired by my child in the well situation at WRCCDC, I arrived at a DNS C2 option I’m happy with. Beacon’s DNS data channel exists as a fallback option. By default, Beacon will continue to use HTTP as a data channel. If you find yourself with a child in the well scenario, type mode dns in the Beacon’s console, and Beacon will use DNS as a data channel to download tasks, post output, and communicate metadata about the host. This change in communication scheme is signaled over DNS.

DNS as a fallback is interesting, but it doesn’t solve a bigger problem–delivering the payload. Cobalt Strike delivers Beacon using an HTTP stager. How do you establish a foothold when DNS is the only way out? Fortunately, I have you covered here too. This release of Cobalt Strike includes the ability to stage Beacon over DNS. The DNS stager appears as an option when crafting one of Cobalt Strike’s social engineering packages or web drive-by attacks.

Select listener (DNS) to stage over DNS

With this new stager and Beacon’s DNS communication mode, it’s possible to establish a foothold and control a system, without a direct connection of any sort.

If you need to simulate an advanced actor, one capable of escaping the toughest networks, this latest Cobalt Strike release has you covered. As usual, a 21-day trial is available for download. Licensed users may use the update program to grab the latest. For a full list of changes, consult the release notes file.