Cloud-based Redirectors for Distributed Hacking

January 14, 2014

A common trait among persistent attackers is their distributed infrastructure. A serious attacker doesn’t use one system to launch attacks and catch shells from. Rather, they register many domains and setup several systems to act as redirectors (pivot points) back to their command and control server.


As of last week, Cobalt Strike now has full support for redirectors. A redirector is a system that proxies all traffic to your command and control server. A redirector doesn’t need any special software. A little iptables or socat magic can proxy traffic for you. Redirectors don’t need a lot of power either. You can use a cheap Amazon EC2 instance to serve as a redirector.

Here’s the socat command to forward connections to port 80 to

socat TCP4-LISTEN:80,fork TCP4:

The TCP4-LISTEN argument tells socat to listen for a connection on the port I provide. The fork directives tells socat that it should fork itself to manage each connection that comes in and continue to wait for new connections in the current process. The second argument tells socat which host and port to forward to.

Redirectors are great but you need payloads that can take advantage of them. You want the ability to stage through a redirector and have command and control traffic go through your other redirectors. If one redirector gets blocked—the ideal payload would use other redirectors to continue to communicate.

Cobalt Strike’s Beacon can do this. Here’s the new Beacon listener configuration dialog:


You may now specify which host Beacon and other payloads should stage through. Press Save and Beacon will let you specify which redirectors Beacon should call home to as well:


The Metasploit Framework and its payloads are designed to stage from and communicate with the same host. Despite this limitation these payloads can still benefit from redirectors. Simply spin up a redirector dedicated to a Meterpreter listener. Provide the address of the redirector when you create the listener.


Now, one Cobalt Strike instance, has multiple points of presence on the internet. Your Beacons call home to several hosts. Your Meterpreter sessions go through their own redirector. You get the convienence of managing all of this on one team server though.

If you want Meterpreter to communicate through multiple redirectors then tunnel it through Beacon. Use Beacon’s meterpreter command to stage Meterpreter and tunnel it through the current Beacon. This will take advantage of the redirectors you configured the Beacon listener to go through.


  1. Haven’t tested it yet, but this should also be possible for port 53. So you could set this up for DNS based beacon communication?

    • I don’t know the answer to this yet. I give it 50/50 odds that it’ll work as-is or not. Until I try to set something like this up for DNS Beacon–I won’t know.

  2. Could you please tell me is it possible to have both redirector (e.g. socat or some reverse http proxy) and teamserver running on the *same* EC2 instance i.e. the one with only one external IP address ? If yes, please do provide few hints (blog post?) on the matter.


    • I don’t think this would work very well and I don’t exactly understand the benefit of this. What is the benefit of having one server in front of your team server on the same system? I’d just let Cobalt Strike present itself.

      Even if there is a good benefit (e.g., you want to use nginx to host static assets and proxy some things back to CS)–Cobalt Strike’s configuration options do not play well with port bending and this configuration might not be possible on the same host. I do not intend to support this. My recommendation is to spin up beefier nodes to host the team servers and use cheap nodes as redirectors.

      • Thanks for clarification. My goal was exactly you stated in second paragraph.

  3. For new Cobalt Strike users/operators, maybe it would be better to have string “Staging host:” rather than “Host:” in new Beacon listener configuration dialog.

  4. It’s also possible to set up redirectors using xinetd. That way you can configure them to restart themselves if they die and you don’t have to mess with a pile of socat instances running in tmux.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s