redStack: A Boot-to-Breach Lab Environment for Red Team Operators

[!NOTE] redStack is now feature complete and supports both public internet deployments and closed environments (HTB/VL/PG) that use OpenVPN. This is actively being tested and debugged, so please reach out with any issues or concerns.

[!IMPORTANT] redStack is not a tutorial on how to use C2 frameworks. It is an environment that removes the infrastructure hurdle so you can focus on learning. The lab gives you a fully configured, production-style red team setup out of the box (Boot-to-Breach). This lab is strictly for authorized training and lab environments only (HTB, VL, PG, self-hosted cyber ranges, personal lab VMs, etc.). It is not intended for use in real-world engagements or against targets you do not own and have explicit written permission to test.

[!CAUTION] AWS TOS: Use at your own risk

Hosting C2 infrastructure on AWS may raise concerns under the AWS Acceptable Use Policy. Before deploying, review the AUP and submit the AWS Penetration Testing / Simulated Events request form. This is the appropriate channel for notifying AWS that you are running security tooling on their infrastructure.

As long as you are using redStack exclusively for personal lab work and authorized training platforms (HTB, VL, PG, self-hosted cyber ranges, etc.), you are generally in the clear. A quick conversation with AWS customer support can confirm this and give you peace of mind specific to your account and usage pattern. To be safe, consider running redStack from a dedicated, single-purpose throwaway AWS account. One used solely for this lab so there is no risk to other workloads, billing alerts, or account standing.

---

Table of Contents

• Architecture Overview
• Part 0: Pre-Deployment Checklist
  • Prerequisites
  • Step 0.1: Clone Repository & Install Tools
  • Step 0.2: AWS IAM Permissions
  • Step 0.3: Verification Commands
  • Step 0.4: Create AWS SSH Key Pair (Required)
• Part 1: Initial Deployment
  • Step 1.1: Configure Terraform Variables
  • Step 1.2: Initialize Terraform
  • Step 1.3: Review Deployment Plan
  • Step 1.4: Deploy Infrastructure
  • Step 1.5: Review Deployment Information
  • Step 1.6: Point Domain to Redirector
• Part 2: Verification
  • Step 2.1: Access Guacamole Portal
  • Step 2.2: Access Windows Workstation
  • Step 2.3: Verify Internal Connectivity
• Part 3: Apache Redirector Configuration
  • Step 3.1: Obtain SSL Certificate
  • Step 3.2: Run the Connectivity Test
  • Step 3.3: Review Configuration
  • Step 3.4: Security Layer Details
  • Step 3.5: Review Logs
• Part 4: Mythic C2 Setup
  • Step 4.0: Verify Pre-Installed Profiles and Agents
  • Step 4.1: Verify HTTP C2 Profile is Running
  • Step 4.2: Generate Agent
  • Step 4.3: Deploy Agent
  • Step 4.4: Test C2 Session
• Part 5: Sliver C2 Setup
  • Step 5.1: Access Sliver Server
  • Step 5.2: Connect to Sliver and Create Listener
  • Step 5.3: Generate Implant
  • Step 5.4: Test Sliver Session
• Part 6: Havoc C2 Setup
  • Step 6.1: Build Havoc (run once after deployment)
  • Step 6.2: Verify Havoc Teamserver
  • Step 6.3: Open the Havoc Desktop and Connect the Client
  • Step 6.4: Create Listener and Generate Demon
• Part 7: Troubleshooting
  • Connectivity Checks
  • Component Health Checks
• Post-Deployment Actions
  • Cleanup (When Done)
  • Cost Management
• Success Criteria
• Part 8: External Target Environments (HTB/VL/PG)
  • Step 8.1: Configure terraform.tfvars
  • Step 8.2: Deploy and Obtain Your .ovpn File
  • Step 8.3: Get the .ovpn File to the Redirector
  • Step 8.4: Start the VPN Tunnel
  • Step 8.4b: Get the VPN Interface IP for C2 Callbacks
  • Step 8.5: Verify Connectivity from Internal Machines
  • Step 8.6: Stop the VPN
  • Important Notes

---

Architecture Overview

+----------------------------------------------------------------------+
|                    redStack Network Architecture                     |
+----------------------------------------------------------------------+

                          [ Operator ]
                       Browser / MobaXterm
                               |
                   HTTPS :443  |  SSH :22
                               |
+------------------------------+------------------------------+
|               TeamServer VPC (172.31.0.0/16)                |
|   +-----------------------------------------------------+   |
|   | guacamole               Elastic IP: <Public IP>     |   |
|   | 172.31.x.x                                          |   |
|   +--+----+----+----+-------------------------------+---+   |
|      |    |    |    |   Guacamole-managed sessions  |       |
|     SSH  SSH  SSH  RDP                              |       |
|      |    |    |    |                               |       |
|   +--+  +-+  +-+--+-+---------+                     |       |
|   |     |    |    |           |                     |       |
|   v     v    v    v           v                     |       |
| +------++------++------+  +------------+            |       |
| |mythic||sliver||havoc |  |WIN-OPERATOR|            |       |
| |      ||      ||      |  |            |            |       |
| +------++------++------+  +------------+            |       |
|        ( no public IPs - internal only )            |       |
+------------------------------+----------------------+-------+       
                               |                              
           VPC Peering: 172.31.0.0/16 <-> 10.60.0.0/16        
           - C2 callbacks: Apache proxy -> teamservers
                               |                               
+------------------------------+------------------------------+
|                Redirector VPC (10.60.0.0/16)                |
|   +-----------------------------------------------------+   |
|   | redirector              Elastic IP: <Public IP>     |   |
|   | 10.60.x.x                                           |   |
|   | Apache :80/:443 (X-Request-ID + URI validation)     |   |
|   | Decoy page served to unvalidated requests           |   |
|   +-----------------------------------------------------+   |
+------------------------------+------------------------------+
                               ^
                               |
                    public internet / cloud DNS
                               |
                               v
          [ Public Internet Accessible Target Environments ]

Public Internet Environment (C2 Callback Flow):
  [target / implant] --HTTPS/HTTP--> public internet / cloud DNS
  --> redirector Elastic IP --> Apache (X-Request-ID + URI validation)
  --> VPC peering --> mythic / sliver / havoc (172.31.x.x)

[!NOTE]

• All C2 servers have no public IPs. Reachable only through the redirector via VPC peering
• The redirector runs in its own isolated VPC, simulating an external provider
• Every lab machine has /etc/hosts entries so all hostnames resolve across the environment
• Requests without a valid X-Request-ID header receive a decoy CloudEdge CDN maintenance page
• Only requests with a matching URI prefix and the correct header token are proxied to the correct C2 server
• redirect.rules blocks AV vendors and TOR exits (403)
• Run terraform output network_architecture to see the diagram populated with your actual IPs

---

Part 0: Pre-Deployment Checklist

Prerequisites

• [ ] AWS account with IAM credentials
• [ ] AWS CLI installed and configured
• [ ] Terraform >= 1.0 installed
• [ ] Your public IP obtained
• [ ] Repository cloned (see Step 0.1)
• [ ] SSH key pair created in AWS EC2 (see Step 0.4 below)

Step 0.1: Clone Repository & Install Tools

Clone the repository:

git clone https://github.com/BaddKharma/redStack.git
cd redStack

[!NOTE] All subsequent commands should be run from inside the `redStac