Introduction

For as long as offensive computer network operations have occurred, whether performed by malicious actors or security consultants, attackers have made attempts to keep their infrastructure hidden and protected. At the most fundamental level, this typically involves the redirection of network traffic from the target’s network through a host or service that obscures the traffic’s final destination. In this blog post, we will take a high-level look at the purpose of redirectors and discuss their implementation.

Please note that the examples discussed represent the tip of the iceberg in terms of redirection, and this blog post should be considered a non-exhaustive primer.

Overview

Put simply, redirectors are systems that proxy traffic from a target network to private attack infrastructure. They serve multiple purposes, including to:

Below is more information about these different purposes.

Prevent unauthorized access to the attack infrastructure:

Redirectors act as the demarcation line between the public internet and private attack infrastructure. Private attack infrastructure may include phishing or Command and Control (C2) servers, decoy web servers, staging servers, or any other component that must remain protected from unauthorized parties. Redirectors provide granular control over access to private attack infrastructure, allowing only the desired traffic to pass through.

Control the appearance of the infrastructure:

Given that a redirector establishes a boundary between the public internet and private attack infrastructure, it often is the only publicly visible infrastructure component and the nearest hop to the target environment. The redirector’s characteristics and appearance inform the target, and anyone who investigates the host, of the purpose and use of the host. Redirectors offer an opportunity to shape the perception and to deceive or mislead.

Protect the attack chain:

Redirectors are considered burnable components of attack infrastructure. If a redirector is identified and categorized as malicious, then it can be burned down and replaced with a new redirector. The new redirector can then be connected to the existing private attack infrastructure. The attack chain, although impacted by the burning of a domain, IP, or redirector, remains mostly intact, as the core components are hidden behind the redirector.

By segmenting and controlling traffic to private attack infrastructure via the use of redirectors, the more time-consuming and sensitive components to set up—such as C2 or phishing servers—remain protected and inaccessible to defenders.

Redirector Types

For the purposes of this blog post, let’s think of basic redirector types as existing on a spectrum of less to more filtering. Generally, this also correlates to less or more effort to configure and deploy. However, the level of effort on either end of the spectrum can be diminished through automation.

Image

Figure 1 - Redirector Types

On the “less effort” and “less filtering” end of the spectrum, we have redirectors based on socat, iptables, or blind reverse proxies. These types of redirectors generally tend not to filter or apply rules to traffic. Instead, they blindly forward, or bend, traffic to a destination. Setup involves relatively little effort. However, there are implications related to the level of operational security they offer. With few filters, these redirectors will pass most traffic, including from Internet scanners or mail filtering solutions, right through to backend servers. Depending on the use case, this may be acceptable. However, it may increase the likelihood of identification and categorization of the redirector and/or backend assets as malicious.

On the “more effort” and “more filtering” end of the spectrum, we have redirectors built using reverse proxies that allow for filtering traffic based on specific conditions and rules. These redirectors may only pass traffic with specific User Agent strings to a backend C2 server, or they may redirect traffic from pre-defined IP ranges to a decoy web server. The intricacies of the configuration depend on the engagement requirements, the capabilities of the reverse proxy and beacon being used, and, lastly, the engineer’s imagination. More filters mean more control over how traffic is processed, which, if configured correctly, may improve the protection of infrastructure and decrease the likelihood that it is identified as malicious.

Implementation

There are many reverse proxies available to choose from, each with their own advantages and disadvantages. The following implementation will use Apache, a web server featuring robust reverse proxy configuration options. After describing the basic setup with Apache, we will add a CloudFront distribution in front of the redirector to demonstrate an additional layer of redirection. For the C2 framework, this example will use Cobalt Strike. However, the basic redirector configuration is generally C2 framework agnostic, and you may use the framework of your choosing. Please note that discussions of the C2 deployment and configuration are not in scope for this post.

Before getting started, there are several requirements for this demonstration:

For the purposes of this demonstration, we are setting up a Cobalt Strike team server on an AWS EC2 instance. However, given that during live engagements, team servers can end up hosting data from the target network. It is preferrable that the team server be hosted on a server owned by your organization.

EC2 Provisioning

Using your preferred method, whether via the AWS console, Terraform or otherwise, provision two EC2 instances of the Linux distribution of your choosing: one for the redirector and one for the team server.

Create a security group for each EC2 instance, as we will apply different rules for each resource. Initially, configure the security groups to allow traffic inbound only from the operator’s IP.

Image

Figure 2 - Initial Redirector Security Group Rules

Apache Installation and Initial Configuration

On the redirector EC2 instance, install Apache along with several Apache modules that will be required for the configuration:

Certbot Installation and Execution
Certbot is a tool that obtains TLS certificates from Let’s Encrypt. We will use Certbot’s HTTP-01 Challenge type to obtain a certificate, which requires that:

Before installing and running Certbot, modify the redirector security group rules to allow inbound traffic from anywhere to port 80.

Image

Figure 3 - Security Group Modification Prior to Running Certbot

Next, add the IP address of the redirector as the A Record for the domain being used for the redirector.

Image

Figure 4 - A Record Entry for Redirector Domain

Once those steps are complete, install and run Certbot by executing the following:

Given a successful Certbot run, a response similar to the following screenshot should be displayed.

Image

Figure 5 - Certbot Run

Once the certificate files have been obtained, remove the AWS security group rule that permitted traffic inbound on port 80.

Apache Site Configuration

The heart of the redirector configuration is found in the Apache site configuration file. The site file defines the desired behavior for network traffic that reaches the redirector as well as the TLS configuration, specifying which certificate files to use and whether to perform TLS verification.

Within the /etc/apache/sites-available/ directory, create a configuration file called domain.com.conf where domain is the name of the domain being used for your redirector.

The first step is to redirect unencrypted inbound traffic on port 80 to port 443. Using Apache’s VirtualHost directive, define the following block (replace exampledomain.com with the domain being used for the redirector):

The above block will redirect traffic to port 443, which will be handled by the block below. In the following VirtualHost directive, Apache is instructed to proxy all traffic to “exampledomain.com,” or the domain you selected for your redirector. In order for this to pass traffic to the team server domain, we will need to modify the /etc/hosts file on the redirector to resolve “exampledomain.com” to the IP address of the team server. We are using this method because it allows us to reuse the TLS certificates obtained via Certbot instead of needing a second domain and second set of certificates.

Next, add an entry to /etc/hosts pointing DNS lookups for your domain to the IP of the team server. When Apache uses the ProxyPass directives to proxy the traffic to the specified domain, it will then reference the redirector’s /etc/hosts file.

Image

Figure 6 - Example Hosts File

Then, enable the site and restart the Apache service:

Command and Control Server Configuration

At the beginning of the walkthrough, we created two EC2s, including one for the redirector and one for the team server. This blog post assumes that the reader can successfully install and configure the C2 framework of their choosing. For the purposes of this demonstration, we have deployed a team server running Cobalt Strike.

Prior to opening the firewall rules to allow traffic in from the redirector, the certificate material from the redirector must be copied to the team server. Depending on your C2 framework, the certificate fullchain and private key files may be added to your C2 configuration in different ways. Once the certificate material has been added, modify the team server security group rules to allow HTTPS traffic inbound from the redirector IP.

Image

Figure 7 – Team Server Security Group Rules

Using your C2 framework, create a listener and payload that are configured to use the previously configured redirector domain name as the HTTPS host.

Image

Figure 8 - Cobalt Strike Listener

Assuming that you are executing the test payload on a Windows VM running on your host, there is no need to add additional firewall rules. However, if you are executing the payload from another workstation with a different IP, adjust the security group rules accordingly.

Once the payload has been executed on the redirector, there should now be an entry in the Apache access.log file indicating that an HTTP request has been made.

Image

Figure 9 - Apache Access Log on Redirector

On your C2 team server, you should see an established session. If the C2 framework being used supports the X-Forwarded-For header, then the client’s origin IP should be available.

Image

Figure 10 - Cobalt Strike Beacon Callback

To summarize, a payload has been executed, a request has been made to the domain hosted on the redirector, and, finally, the request has been passed through the reverse proxy on the redirector to the backend team server. The team server only allows traffic in from the redirector and from operator IPs, thus making it inaccessible to prying eyes. This setup provides the team server with some degree of protection, although it does not filter out unwanted traffic from reaching the team server.

CloudFront Redirection

As an added layer of redirection, and to help with issues related to domain categorization, content delivery networks (CDNs) can be used to redirect traffic. Building on the example just discussed, CloudFront can be easily integrated without any adjustments to the redirector configuration itself. In general, there are two steps to take:

Image

Figure 11 - CloudFront Distribution Details

Image

Figure 12 - CloudFront Distribution Origins

Before generating and executing a new payload, the firewall rules on the redirector need to be modified to allow traffic in from CloudFront. Within AWS security groups, there is a feature that enables users to add firewall rules for dynamically managed lists of resources that AWS maintains. Specifically useful in this scenario is a managed prefix list for all CloudFront IPs. This list enables operators to allow HTTPS traffic in from a dynamic list of CloudFront IPs, while preventing other traffic from reaching the redirector.

Image

Figure 13 - AWS Managed Prefix

Once the appropriate managed prefix has been added to the firewall rules, generate and execute the new payload using the CloudFront URL as the C2 URI. If configured correctly, the Apache access.log on the redirector should show traffic from CloudFront and the team server should show a new beacon.

Image

Figure 14 - Apache Access Log on Redirector

Image

Figure 15 - Cobalt Strike Beacon Callback via CloudFront Domain

Take note that due to the addition of the X-Forwarded-For header on the redirector, the external IP of the beacon displays the real client origin IP.

To summarize, a payload has been executed, a request has been made to a CloudFront distribution, the CloudFront distribution has forwarded the request to the specified domain, and the request has been passed through the reverse proxy on the redirector to the backend team server.

Next Steps

The redirector setup discussed in this post is about as simple as it can get outside of using socat or iptables. From here, an operator could add a myriad of rules defining the paths, User-Agent strings, or other characteristics that are required for traffic to be passed to the backend team server. An operator could also build in deceptive rewrites that seek to control the narrative around the purpose of the exposed infrastructure. For further information on associated TTPs, please reference the following resources: