Red Team Infrastructure - Deploying a redirector via Terraform

Learn how to deploy and configure a redirector machine in AWS via Terraform.

May 19, 2025

In previous posts, we laid out the foundational red team infrastructure in AWS using Terraform. The configuration included the creation of a Virtual Private Cloud (VPC), public and private subnets, route tables, an internet gateway, a Kali Linux EC2 instance with SSH access, a Windows Server EC2 instance with RDP access and an Ubuntu 24.04 EC2 instance with Havoc C2.

In this post, we take this infrastructure a step forward by adding a redirector machine. The goal is to deploy the redirector on an Ubuntu 24.04 EC2 instance and configure it to run a web server and forward request received on port 443 to the Havoc C2 team server.

Follow my journey of 100 Days of Red Team on WhatsApp, Telegram or Discord.

Why we need a redirector machine?

In a red team engagement, exposing the C2 server directly to the internet significantly increases risk. Threat detection tools and defenders monitor network traffic, and a known or newly-identified C2 server IP can quickly become a point of failure. A redirector helps mitigate this by acting as a buffer between the public internet and the actual C2 server.

The redirector’s primary job is to forward traffic—typically over ports 80 (HTTP) and 443 (HTTPS)—to the backend Havoc C2 server, making it appear as though the connection terminates at the redirector. This technique helps mask the true location and identity of the C2 infrastructure. It also adds a layer of operational security by allowing dynamic redirection, traffic filtering, and the use of deception techniques such as domain fronting or HTTP filtering.

EC2 instance and other configuration

To deploy the redirector machine, a new t3.micro Ubuntu 24.04 EC2 instance is added to our red team infrastructure. This instance will be attached to a new public subnet (192.168.3.0/24). This subnet will allow access to ports 80 and 443. The operator will be allowed to connect to the instance via SSH (key-based authentication). SSH access will be allowed only from the Havoc C2 server.

Once the redirector EC2 instance is created, it is configured automatically using a custom user_data script. This script is passed to the instance during launch using Terraform’s templatefile() function.

This script performs the following steps:

Updates package lists and installs apache2.
Enables ssl, rewrite, proxy, proxy_http Apache modules.
Enables the SSL configuration in /var/apache2/sites-enabled.
Adds a directory block to the SSL configuration.
Updates the SSL configuration to allow SSL proxy and relax SSL verification requirements (since we are working with self-signed certificates).
Setup web traffic redirection via a .htaccess file. The .htaccess configuration will:
- disable directory browsing
- redirect all requests to / to index.html
- serve all request matching a file on the redirector machine
- forward all remaining requests to the Havoc C2 server
Creates an index.html file in /var/www/html directory.

Next, the user_data script for the Havoc C2 server is updated to automate certain steps. This includes:

Creating a systemd service that ensures the Havoc team server starts automatically whenever the instance reboots.
Installing autossh, a tool used to maintain a persistent SSH tunnel.
Configuring autossh to establish a reverse SSH tunnel to the redirector EC2 instance. This tunnel forwards traffic from the redirector to the Havoc C2 server.
Creating another systemd service to automatically launch the autossh and setup a reverse SSH tunnel on boot.

The user_data script for the Kali Linux EC2 instance is updated to:

Place the previously generated SSH private key to the machine. This is done to allow copying of generated payloads to the redirector machine.

Deploying the redirector machine

Refer to the Kickstarting red team infrastructure automation via Terraform to understand the architecture we are working with.

Here is the Terraform Red Team Infrastructure project in 100 Days of Red Team GitHub repository that deploys a redirector machine.

Clone this project to your machine and execute the following commands to deploy the infrastructure:

⚠️Reminder: Switch to the dev Terraform workspace (terraform workspace select dev) before executing following commands. To create dev workspace use, terraform workspace new dev.

terraform init
terraform plan -var-file "secrets.tfvars"
terraform apply -var-file "secrets.tfvars"

Reminder: You must create a secrets.tfvars file manually to hold credentials. Never commit secrets to version control. It contains AWS credentials temporarily stored in plain text, which is not recommended for production environments. Also, we are still using local state files for simplicity. In a real red team deployment, you must use an encrypted remote backend.

Deploying red team infrastructure via Terraform

Redirector EC2 machine provisioned via Terraform

Requests to / getting redirected to index.html

Havoc C2 team server service successfully launched on startup

autossh service successfully launched on startup

HTTPS request not getting proxied to Havoc C2 server as it is not listening on port 443

HTTPS requests to redirector getting forwarded to Havoc C2 server after setting up a listener on port 443

Copying the generated payload to the redirector machine via scp

Downloading the payload hosted on redirector machine

Once done, remember to destroy the infrastructure via following command (or you may incur significant costs):

terraform destroy -var-file "secrets.tfvars"

Destroying red team infrastructure via Terraform

TL;DR
In this post we covered how to:
- Deploy and configure a redirector machine via Terraform.
- Deploy systemd services to auto-start Havoc C2 team server and automatically establish a reverse tunnel via autossh.
- Validate the functioning of redirector machine by deploying a payload on a Windows box.