Skip to main content
redStack is a Boot-to-Breach red team lab environment that provisions a fully configured, production-style C2 infrastructure on AWS with a single terraform apply. It removes the infrastructure burden so you can focus on learning tradecraft, not fighting configuration.
redStack is strictly for authorized training and lab environments — HTB, VulnLab, Proving Grounds, self-hosted cyber ranges, and personal lab VMs. It is not intended for use in real-world engagements or against systems you do not own and have explicit written permission to test.

​
What you get

Three C2 frameworks

Mythic, Sliver, and Havoc — pre-installed, pre-configured, and running on boot.

Apache redirector

Header validation, URI-prefix routing, and automated scanner/AV blocking via redirect.rules.

Guacamole portal

Browser-based access to every lab machine — SSH to C2 servers, RDP to Windows, VNC to the Havoc desktop.

Windows workstation

Windows Server 2022 with Chromium, VS Code, MobaXterm, and 7-Zip pre-installed.

Dual-VPC isolation

C2 servers have no public IPs. All implant traffic flows through the redirector via VPC peering.

OpenVPN support

Connect to HTB, VulnLab, and Proving Grounds Pro Lab networks directly from the lab.

​
Who redStack is for

redStack is built for three audiences:
Operators who want a realistic, isolated C2 staging environment for tool development, payload testing, and tradecraft practice without spinning up infrastructure from scratch. The dual-VPC design and redirector configuration mirror production red team setups used in real engagements.
Students working through red team fundamentals who need a safe, self-contained lab to learn Mythic, Sliver, or Havoc without worrying about infrastructure. Boot-to-Breach means you go from zero to a working C2 callback in under 30 minutes.
CTF and pro-lab players on HTB, VulnLab, and Proving Grounds who want a persistent, dedicated C2 environment with OpenVPN routing built in. Deploy once, use across multiple lab sessions, tear down when done.

​
Key features

​
Three pre-installed C2 frameworks

All three frameworks are installed automatically by Terraform user data scripts — no manual setup required.
FrameworkInstance typeAccess methodNotes
Mythict3.mediumSSH or web UI :7443Apollo agent + HTTP C2 profile pre-installed
Slivert3.smallSSH → sliver-clientDaemon runs as a systemd service on boot
Havoct3.mediumSSH + VNC (XFCE4 desktop)Built from source; Havoc client runs on the desktop

​
Apache redirector

The redirector is the only component with a public Elastic IP. It sits in an isolated Redirector VPC (10.60.0.0/16) that peers to the TeamServer VPC (10.50.0.0/16) over AWS VPC peering. Three security layers protect the C2 backends:
  1. redirect.rules — blocks requests from AV vendors, scanners, and TOR exits with 403 Forbidden
  2. Header validation — requests without a valid X-Request-ID token receive a decoy CloudEdge CDN maintenance page
  3. URI prefix routing — only matching URI prefixes (/cdn/media/stream, /cloud/storage/objects, /edge/cache/assets) are proxied to the correct C2 server

​
Guacamole access portal

Apache Guacamole serves as the operator access layer. It runs on a Debian 12 instance with its own public Elastic IP and provides seven pre-configured connections out of the box:
  • Windows Operator Workstation (RDP)
  • Mythic Team Server (SSH)
  • Sliver C2 Server (SSH)
  • Havoc C2 Server (SSH)
  • Havoc C2 Desktop (VNC)
  • Apache Redirector (SSH)
  • Guacamole Server (SSH)
All SSH connections use password authentication — no key management inside the portal.

​
Hostname resolution

Every lab machine has /etc/hosts entries pre-populated at deploy time. From anywhere inside the lab, you can reach any machine by hostname: 
mythic
sliver
havoc
guac
redirector
win-operator
Windows uses C:\Windows\System32\drivers\etc\hosts with the same entries.

​
OpenVPN support (HTB / VulnLab / PG)

When enable_external_vpn = true, the redirector runs an OpenVPN client and WireGuard bridges traffic from all internal lab machines to the target VPN network. This lets you fire implants at HTB or Pro Lab targets from Mythic, Sliver, or Havoc without routing through your local machine.
This lab is for authorized environments only. Acceptable use includes:
  • HackTheBox (HTB) machines and Pro Labs
  • VulnLab environments
  • Proving Grounds (PG) boxes
  • Self-hosted cyber ranges
  • Personal lab VMs you own
Do not use redStack against systems you do not own or do not have explicit written permission to test. Unauthorized use of C2 infrastructure against third-party systems is illegal in most jurisdictions and violates the terms of service of every major cloud provider.

​
AWS terms of service

Use a dedicated AWS account. 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.Running redStack from a dedicated, single-purpose throwaway AWS account is the safest approach. An account used solely for this lab isolates any risk from other workloads, billing resources, or account standing. If the credentials are ever compromised, an attacker can only reach lab infrastructure you already plan to tear down.
As long as you are using redStack exclusively for personal lab work and authorized training platforms (HTB, VulnLab, PG, self-hosted cyber ranges), you are generally within AWS acceptable use. A quick conversation with AWS customer support can confirm this for your specific account and usage pattern.

​
Cost awareness

EC2 instances accrue charges 24/7 whether or not you are actively using them.
  • Stop instances from the EC2 Dashboard to pause compute charges without destroying the environment (EBS storage still accrues)
  • terraform destroy is the only way to eliminate all charges — it terminates instances, releases Elastic IPs, and removes all billable resources
  • Set a billing alarm in the AWS Billing Console to alert you if monthly charges exceed a threshold you set

​
Get started

Architecture

Understand the dual-VPC network design, EC2 instances, and traffic flow before deploying.

Prerequisites

Install AWS CLI and Terraform, configure IAM credentials, and create your SSH key pair.

Deploy

Run terraform init, terraform plan, and terraform apply to bring up the full lab.

Terraform reference

Full variable reference for customizing instance types, VPC CIDRs, URI prefixes, and more.

Build docs developers (and LLMs) love

Get started for freeTalk to us