Obfuscating C2s - Introducing Redirectors

In the previous chapter, we learned about the basics of C2 server and how we can use file-sharing services like Dropbox and OneDrive as a C2 server. However, from the blue team's perspective, the unfamiliar IPs will be blacklisted after knowing what those IPs are for. If our C2 server is blacklisted, our engagement will fail. Consequently, to protect our C2 servers from being detected by the defenders of the organization, we will hide our team servers behind another server. This server is called a Redirector and it'll be responsible for redirecting all the communication to our C2 server.

In this chapter, we will cover the following topics:

• Introduction to redirectors
• Obfuscating C2 securely
• Short-term (ST) and long-term (LT) redirectors
• Payload stager redirection
• Domain fronting

...

Technical requirements

• Linux
• Armitage
• Socat

Introduction to redirectors

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. 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...

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...

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 are where the callbacks received from the target...

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...

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...

Summary

In this chapter, we have introduced redirectors and why obfuscating C2s is required. 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. In addition, we have learned about short-term and long-term C2s and redirectors. Next, the payload redirection type was covered. Here, we learned about dumb pipe redirection and smart redirection. At the end of the chapter, we saw how we obtained a domain which resembles http://packtpub.com and how this can be used to achieve further anonymity.

Questions

1. Can we use Microsoft Windows based redirector instead of Linux based?
2. Why should we configure and install our own redirector when we can use a compromised server for the same job?
3. Is it mandatory to use Apache Web server for smart redirection?
4. Is it legal if we buy a domain similar to organization's domain for the engagement ?
5. Can we setup the redirectors on AWS?

Further reading

For more information on the topics discussed in this chapter, please visit the following links:

• https://thevivi.net/2017/11/03/securing-your-empire-c2-with-apache-mod_rewrite/
• https://resources.infosecinstitute.com/domain-fronting/
• https://bluescreenofjeff.com/2018-04-12-https-payload-and-c2-redirectors/
• https://www.xorrior.com/Empire-Domain-Fronting/
• https://www.optiv.com/blog/escape-and-evasion-egressing-restricted-networks
• https://www.mdsec.co.uk/2017/02/tor-fronting-utilising-hidden-services-for-privacy/
• https://www.securityartwork.es/2017/01/31/simple-domain-fronting-poc-with-gae-c2-server/
• https://www.mdsec.co.uk/2017/02/domain-fronting-via-cloudfront-alternate-domains/
• https://theobsidiantower.com/2017/07/24/d0a7cfceedc42bdf3a36f2926bd52863ef28befc.html