Cobalt Strike Redirectors
A redirector a day keeps IR away
Last updated
A redirector a day keeps IR away
Last updated
During offensive operations, offensive infrastructure such as teamservers, phishing and staging servers ae often discovered by defensive teams, who then take action against them such as blocking them at the network perimeter or attempting to get the infrastructure taken down by hosting providers.
In order to minimize impact caused by these defensive responses, offensive teams often deploy proxy servers in front of their offensive backend, which are commonly referred to as redirectors. In this case, when a defense team blocks the beacon callback ip, rather than blocking the C2 server they are blocking the ip of the redirector, which can be easily swapped out for another one without having to rebuild the teamserver.
This can be combined with SSH tunneling and a private subnet to prevent unauthorized connection/scanning of the malicious components of our offensive infrastructure.
SSH tunneling:
Using SSH Tunneling to secure C2 infraA common redirector setup is shown below, taken from this other website.
While there are many ways of running these proxy systems, with different pros and cons for each type, they all have the same purpose, of redirecting traffic from the target to the backend offensive infrastructure, and vice versa.
Simple TCP redirector using socat. All it does is redirect traffic to the backend and nothing else.
This type of redirector is documented on the Cobalt Strike website here.
Here’s the socat command to forward connections to port 80 to 54.197.3.16:
A very standard redirector setup. Standard webserver security can be used to provide some level of protection for the backend infrastructure without too many extra tricks. Uses an existing HTTP webserver service such as apache/nginx to redirect HTTP traffic (for http/s beacons of course) to the teamserver. For phishing redirectors, smtp servers such as postfix can be setup to redirect emails.
The apache redirector using mod_rewrite is documented here.
There are open source (or otherwise) projects that aim to add defensive or evasive capabilities to C2 redirectors. One example of this is RedWarden, by mgeeky. This redirector project has additional capabilities such as blocking and logging traffic that could potentially be from defensive teams investigating the infrastructure. This type of redirector can be useful in slowing down defensive response, in addition to proxying traffic for the C2 server.
Services like azure app services and AWS beanstalk can be used to redirect traffic to your offensive infrastructure. The main benefit of these redirectors is that they often come with domain names or SSL certificates from their respective cloud hosting provider, which may make them look less suspicious and get past some network filers.
Serverless code can also be used as redirectors in a similar way. Here are some examples of cloud services as redirectors:
Serverless redirectors can have features similar to "smart" redirectors, depending on the code used.
The CIA also has been known to use C2 redirectors, based on the (now old) vault7 leaks. This is explained more in detail in the following post by byt3bl33d3r. Their infrastructure closely resembles modern red team infrastructure and tools, where beacons call back to a set of redirectors which forward traffic to a C2 server. They seem to favor mTLS to authenticate their implants at the redirector level, making it harder to investigate their backend infrastructure externally.
Starting shell companies to host redirectors is probably not practical for any non state backed operators. lol.
https://byt3bl33d3r.substack.com/p/taking-the-pain-out-of-c2-infrastructure-3c4
