A redirector server is responsible for redirecting all the communication to the C2 server. Let’s explore the basics of redirector using a simple example. Take a scenario in which we have already configured our team server and we’re waiting for an incoming Meterpreter connection on port 8080/tcp. Here, the payload is delivered to the target and has been executed successfully.

This article is an excerpt taken from the book Hands-On Red Team Tactics written by Himanshu Sharma and Harpreet Singh. This book covers advanced methods of post-exploitation using Cobalt Strike and introduces you to Command and Control (C2) servers and redirectors.

In this article, you will understand the basics of redirectors, the process of obfuscating C2 securely, domain fronting and much more.

To follow are the things that will happen next:

On payload execution, the target server will try to connect to our C2 on port 8080/tcp. Upon successful connection, our C2 will send the second stage as follows:

A Meterpreter session will then open and we can access this using Armitage:

However, the target server’s connection table will have our C2s IP in it. This means that the monitoring team can easily get our C2 IP and block it:

Here’s the current situation. This is displayed in an architectural format in order to aid understanding:

To protect our C2 from being burned, we need to add a redirector in front of our C2. Refer to the following image for a clear understanding of this process:

This is currently the IP information of our redirector and C2:

• Redirector IP: 35.153.183.204
• C2 IP: 54.166.109.171

Assuming that socat is installed on the redirector server, we will execute the following command to forward all the communications on the incoming port 8080/tcp to our C2:

Our redirector is now ready. Now let’s generate a one-liner payload with a small change. This time, the lhost will be set to the redirector IP instead of the C2:

Upon execution of the payload, the connection will initiate from the target server and the server will try to connect with the redirector:

We might now notice something different about the following image as the source IP is redirector instead of the target server:

Let’s take a look at the connection table of the target server:

The connection table doesn’t have our C2 IP and neither does the Blue team. Now the redirector is working perfectly, what could be the issue with this C2-redirector setup?

Let’s perform a port scan on the C2 to check the available open ports:

As we can see from the preceding screenshot, port 8080/tcp is open on our C2. This means that anyone can try to connect to our listener in order to confirm its existence. To avoid situations like this, we should configure our C2 in such a way that allows us to protect it from outside reconnaissance (recon) and attacks.

Obfuscating C2 securely

To put it in a diagrammatic format, our current C2 configuration is this:

If someone tries to connect to our C2 server, they will be able to detect that our C2 server is running a Meterpreter handler on port 8080/tcp:

To protect our C2 server from outside scanning and recon, let’s set the following Uncomplicated Firewall (UFW) ruleset so that only our redirector can connect to our C2. To begin, execute the following UFW commands to add firewall rules for C2:

sudo ufw allow 22
sudo ufw allow 55553
sudo ufw allow from 35.153.183.204 to any port 8080 proto tcp
sudo ufw allow out to 35.153.183.204 port 8080 proto tcp
sudo ufw deny out to any

The given commands needs to be executed and the result is shown in the following screenshot:

In addition, execute the following ufw commands to add firewall rules for redirector as well:

sudo ufw allow 22
sudo ufw allow 8080

The given commands needs to be executed and the result is shown in the following screenshot:

Once the ruleset is in place, this can be described as follows:

If we try to perform a port scan on the C2 now, the ports will be shown as filtered: as shown below.

Furthermore, our C2 is only accessible from our redirector now. Let’s also confirm this by doing a port scan on our C2 from redirector server:

Short-term and long-term redirectors

Short-term (ST)—also called short haul—C2 are those C2 servers on which the beaconing process will continue. Whenever a system in the targeted organization executes our payload, the server will connect with the ST-C2 server. The payload will periodically poll for tasks from our C2 server, meaning that the target will call back to the ST-C2 server every few seconds. The redirector placed in front of our ST-C2 server is called the short-term (ST) redirector. This is responsible for handling ST-C2 server connections on which the ST-C2 will be used for executing commands on the target server in real time. ST and LT redirectors would get caught easily during the course of engagement because they’re placed at the front.

Long-term (LT)—also known as long-haul—C2 server is where the callbacks received from the target server will be after every few hours or days. The redirector placed in front of our LT-C2 server is called a long-term (LT) redirector. This redirector is used to maintain access for a longer period of time than ST redirectors. When performing persistence via the ST-C2 server, we need to provide the domain of our LT redirector so that the persistence module running on the target server will connect back to the LT redirector instead of the ST redirector.

A segregated red team infrastructure setup would look something like this:

Source: https://payatu.com/wp-content/uploads/2018/08/redteam_infra.png

Once we have a proper red team infrastructure setup, we can focus on the kind of redirection we want to have in our ST and LT redirectors.

Redirection methods

There are two ways in which we can perform redirection:

• Dumb pipe redirection
• Filtration/smart redirection

Dumb pipe redirection

The dumb pipe redirectors blindly forward the network traffic from the target server to our C2, or vice-versa. This type of redirector is useful for quick configuration and setup, but they lack a level of control over the incoming traffic. Dumb pipe redirection will obfuscate (hide) the real IP of our C2, but won’t it distract the defenders of the organization from investigating our setup. We can perform dumb pipe redirection using socat or iptables. In both cases, the network traffic will be redirected either to our ST-C2 server or LT-C2 server.

Source: https://payatu.com/wp-content/uploads/2018/08/dumb_pipe_redirection123.png

Let’s execute the command given in the following image in order to configure a dumb pipe redirector which would redirect to our C2 on port 8080/tcp:

Following are the commands that we can execute to perform dumb pipe redirection using iptables:

iptables -I INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 54.166.109.171:8080
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1

The given commands needs to be executed and the result is shown in the following screenshot:

(Ignore the sudo error here. This has occurred because of the hostname that we changed)

Using socat or iptables, the result would be same i.e. the network traffic on the redirector’s interface will be forwarded to our C2.

Filtration/smart redirection

Filtration redirection, also known as smart redirection, doesn’t just blindly forward the network traffic to the C2. Smart redirection will always process the network traffic based on the rules defined by the red team before forwarding it to the C2. In a smart redirection, if the C2 traffic is invalid, the network traffic will either be forwarded to a legitimate website or it would just drop the packets. Only if the network traffic is for our C2 will the redirection work accordingly:

To configure a smart redirection, we need to install a web service and configure it. Let’s install Apache server on the redirector using the sudo apt install apache2 command:

We need to execute the following commands as well in order to enable Apache modules to be rewritten, and also to enable SSL:

sudo apt-get install apache2
sudo a2enmod ssl rewrite proxy proxy_http
sudo a2ensite default-ssl.conf
sudo service apache2 restart

These are all commands that needs to be executed. The result of the executed commands are shown in the following screenshot:

We also need to configure the Apache from its configuration:

We need to look for the Directory directive in order to change the AllowOverride from None to All so that we can use our custom .htaccess file for web request filtration.

We can now set up the virtual host setting and add this to wwwpacktpub.tk (/etc/apache2/sites-enabled/default-ssl.conf):

After this, we can generate the payload with a domain such as wwwpacktpub.tk in order to get a connection.

Domain fronting

According to https://resources.infosecinstitute.com/domain-fronting/:

Domain fronting is a technique that is designed to circumvent the censorship employed for certain domains (censorship may occur for domains that are not in line with a company’s policies, or they may be a result of the bad reputation of a domain). Domain fronting works at the HTTPS layer and uses different domain names at different layers of the request (more on this later). To the censors, it looks like the communication is happening between the client and a permitted domain. However, in reality, communication might be happening between the client and a blocked domain.

To make a start with domain fronting, we need to get a domain that is similar to our target organization. To check for domains, we can use the domainhunter tool. Let’s clone the repository to continue:

We need to install some required Python packages before continuing further. This can be achieved by executing the pip install -r requirements.txt command as follows:

After installation, we can run the tool by executing the python domainhunter.py command as follows:

By default, this will fetch for the expired and deleted domains that have a blank name because we didn’t provide one:

Let’s check for the help option to see how we can use domainhunter:

Let’s search for a keyword to look for the domains related to the specified keyword. In this case, we will use packtpub as the desired keyword:

We just found out that wwwpacktpub.com is available. Let’s confirm its availability at domain searching websites as follows:

This confirms that the domain is available on name.com and even on dot.tk for almost $8.50:

Let’s see if we can find a free domain with a different TLD:

We have found that the preceding-mentioned domains are free to register. Let’s select wwwpacktpub.tk as follows:

We can again check the availability of www.packtpub.tk and obtain this domain for free:

In the preceding setting, we need to set our redirector’s IP address in the Use DNS field:

Let’s review the purchase and then check out:

Our order has now been confirmed. We just obtained wwwpacktpub.tk:

Let’s execute the dig command to confirm our ownership of this:

The dig command resolves wwwpacktpub.tk to our redirector’s IP. Now that we have obtained this, we can set the domain in the stager creation and get the back connection from wwwpacktpub.tk:

In this article, we have learned the basics of redirectors and we have also covered how we can obfuscate C2s in a secure manner so that we can protect our C2s from getting detected by the Blue team.  This article also covered short-term and long-term C2s and much more. To know more about advanced penetration testing tools and more check out the book Hands-On Red Team Tactics written by Himanshu Sharma and Harpreet Singh.

Read Next

Introducing numpywren, a system for linear algebra built on a serverless architecture

Fortnite server suffered a minor outage, Epic Games was quick to address the issue

Windows Server 2019 comes with security, storage and other changes