Redirectors
Red Team Infrastructure Setup
Redirectors
What is a redirector and why do we need them?
Creating standalone servers is time consuming. In a Red team engagement, the client's defenders (blue team) will actively be trying to prevent attacks if any of our activities are discovered. If all of the traffic from Command and Control (C2) to the initial payload are downloaded from and connecting to a single server it is trivial for the blue team to simply blacklist the IP, in this situation we would be forced to completely rebuild a new server. As it is expected for servers to get burned during an engagement, we need a way to obfuscate where our payloads, C2 and phishing activities are originating from.
In order to achieve this, we utilize a series of redirectors, or servers which proxy traffic from the victim host to our backend servers.
On the most basic level this is trivial, a simple SOCAT pipe can redirect all traffic received to the backend servers like so: socat TCP4-LISTEN:80,fork TCP4:192.168.1.1:80
https://ired.team/offensive-security/red-team-infrastructure/redirectors-forwarders
However, many other factors come into play when engaged in a red team. A domain will be needed which is categorized (https://www.observeit.com/blog/website-categorization-explained/) by the client’s firewall. The reason for this is two-fold, one, it is extremely suspicious to see prolonged HTTP traffic to and from a random IP address to a host located within the client’s LAN. Any security analyst will flag this behavior as suspicious as will many security programs such as IDS, EDR and SEIM solutions. Secondly most corporate firewalls will not allow traffic to any endpoint on the internet, this is why it is important to not only have a domain but have one that is categorized, reducing the risk rating of the domain and improving the likelihood that the C2 implant will successfully reach our server.
In order to get our domains successfully categorized and to further fool the blue team it is important for our redirectors to have some kind of content on them. There are several different options here, including building simple but believable shell sites, cloning a websites HTML and the easiest, proxying traffic from the redirector to a third-party website.
C2 and Payload Redirector Setup
The majority of these instructions were created using the following resource, https://fatrodzianko.com/2019/08/16/covenant-c2-infrastructure-with-redirectors/.
First go to digitalocean.com and create a new droplet of the smallest size (1GB ram 1 CPU). Pick a region for the server to be located (doesn’t really matter although an American IP may have a higher likelihood of success if the target is in the US). Add your SSH key and use a Ubuntu image.
Once the droplet is created copy the public IPV4 address and go to DreamHost and setup DNS A records for the root domain and www both pointing to your newly created droplet. Wait for the DNS record to propagate before proceeding to the next step.
Once the DNS record has propagated SCP the startup script into the VPS. Run it with the first argument being yourdomain.com and the second arguement will be the public IP address of the backend server. The third arguement will be the third party website to proxy traffic to. Follow any prompts that appear.
You should now be able to visit the covenant admin console on the backend server. SCP the certificate.pfx file that was added to the home directory of your VPS by the startup script back to your machine.
The SSLCertificatePassword field will be whatever the password was that you entered when executing the startup script.
If everything up to this point was successful you should be able to visit yourdomain.com/en-us/test.html and see the mangled HTTP saying “Hello World”.
You are now ready to utilize Covenant as both your C2 as well as your payload server through the “Hosted Files” tab when looking at your listener. You can add a new proxy to your redirector by editing the file /etc/apache2/sites-enabled/000-default-le-ssl.conf and adding a new ProxyPass and ProxyPassReverse entry for the directory where you are serving your executable
Generally speaking, you will want to have a payload redirector, a C2 redirector a phishing redirector and another C2 redirector with an implant configured with a long pause between each check in, such as 24 hours, for persistence.
#!/bin/bash
apt-get update -y && apt-get upgrade -y
apt-get install apache2 -y
a2enmod ssl rewrite proxy proxy_http
a2ensite default-ssl.conf
a2enmod proxy_connect
service apache2 stop
service apache2 start
sudo apt-get update -y
sudo apt-get install software-properties-common -y
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update -y
apt-get install certbot python-certbot-apache -y
certbot -d www.$1.com,$1.com --apache --register-unsafely-without-email
cd /etc/apache2/sites-enabled/000-default-le-ssl.conf
sed -i "/\SSLCertificateKeyFile/a SSLEngine On \nSSLProxyEngine On \nProxyRequests Off \nSSLProxyCheckPeerCN off \nSSLProxyCheckPeerName off\nProxyPass /test/test.txt https://$2/test/test.txt \nProxyPassReverse /test/test.txt https://$2/test/test.txt \nProxyPass /en-us/index.html https://$2/en-us/index.html \nProxyPassReverse /en-us/index.html https://$2/en-us/index.html \nProxyPass /en-us/docs.html https://$2/en-us/docs.html \nProxyPassReverse /en-us/docs.html https://$2/en-us/docs.html \nProxyPass /en-us/test.html https://$2/en-us/test.html \nProxyPassReverse /en-us/test.html https://$2/en-us/test.html\nProxyPass / https://$3/ \nProxyPassReverse / https://$3/" /etc/apache2/sites-enabled/000-default-le-ssl.conf
service apache2 stop
service apache2 start
openssl pkcs12 -export -out certificate.pfx -inkey /etc/letsencrypt/live/www.$1/privkey.pem -in /etc/letsencrypt/live/www.$1/cert.pem -certfile /etc/letsencrypt/live/www.$1/chain.pemLast updated
Was this helpful?