redStack is a Terraform blueprint that deploys Mythic, Sliver, and Adaptix C2 servers behind an Apache redirector across two peered AWS VPCs, built for authorized training and self-hosted cyber ranges.
| Tool | devZero-Security/redStack — Terraform-deployed red team operator lab on AWS with three C2 frameworks, redirector, and Guacamole access portal |
| Category | Red team infrastructure automation / cloud training range (Shell + Terraform) |
| Primary Use | Spinning up a disposable, cost-controlled training environment with Mythic, Sliver, and Adaptix for practicing operator tradecraft against authorized ranges and self-hosted lab VMs |
| Safe Use | Strictly for authorized training and lab environments — cyber ranges, self-hosted environments, and personal lab VMs; the README explicitly prohibits real-world engagements or use against systems you do not own and have written permission to test |
| Telemetry Note | Defenders benefit indirectly: the Apache redirector pattern (header + URI gating, scanner blocking) is documented training material that helps blue teams understand what production C2 fronting looks like in VPC flow logs, CloudTrail, and Apache access logs |
redStack from devZero-Security answers one of the most tedious questions in red team education: how do you get a realistic, production-style operator infrastructure stood up without spending a weekend hand-configuring VPCs, certificates, and redirectors. The project is a Terraform codebase that, on a single terraform apply, provisions seven EC2 instances across two peered VPCs: three C2 frameworks (Mythic, Sliver, Adaptix), an Apache-based redirector, Kali and Windows workstations, and a Guacamole portal for browser-based SSH and RDP access. The README positions it clearly as an environment, not a tutorial — it removes the infrastructure hurdle so an operator can focus on learning the C2 tooling itself, and it draws a hard boundary: authorized training and lab environments only.
The architecture is where the value concentrates. Only two instances get public exposure: the guac Guacamole portal and the redirector, which exposes ports 80/443 via an Elastic IP. Everything else — mythic, sliver, adaptix, windows, and kali — is reachable only through Guacamole, which is a sensible blast-radius decision for a training stack. The redirector itself is an Apache reverse proxy acting as the C2 frontend, with header + URI gating and scanner blocking, mirroring the domain-fronting-adjacent patterns operators encounter in real adversary infrastructure. The repo's GitHub topics (redteam-infrastructure, redteam-operations) align with this production-mimetic design intent.
The repository layout is unusually disciplined for a lab project. Each role owns its own Terraform file: sliver.tf, adaptix.tf, redirector.tf, and kali.tf, while main.tf carries the shared VPC scaffolding plus Mythic, Guacamole, and Windows. Per-host security groups live in security_groups.tf, and the setup scripts under terraform/setup_scripts/ are rendered into cloud-init user-data at apply time via templatefile(). This one-file-per-role decomposition makes the stack legible for someone learning how to structure their own infrastructure-as-code, which is arguably a second curriculum hidden inside the project.
Deployment is deliberately simple: cd terraform, terraform init, terraform apply. First deploys take roughly 30-60 minutes, subsequent ones 20-30, and the README frames the whole lifecycle as a five-step path — prerequisites, choosing an open or closed deployment mode, configuring terraform.tfvars, verifying Guacamole plus Windows plus internal DNS, then landing your first beacon against one of the three C2 backends. The sample config in terraform.tfvars.example references the SSH key at the repo root as ../rs-rsa-key.pem, a small detail that tells you the provisioning assumes a single key pair across the fleet.
Two access modes extend the lab beyond a self-contained bubble. Direct Access runs against your own self-hosted cyber range; Tunneled Access places the stack behind an OpenVPN tunnel into a hosted training platform — the README names Hack Smarter Labs, Hack The Box, OffSec Proving Grounds/Labs, and VulnLab as compatible targets, or any provider handing you an .ovpn file. That flexibility means an operator can point the same infrastructure at progressively harder external, but explicitly authorized, training targets without redeploying.
Cost engineering is treated as a first-class feature, which is rare and welcome. The stack runs at roughly $0.27/hour of compute, and the README estimates $15-20/month for a typical 5-10 hour-per-week study cadence if you run terraform destroy between sessions. The caution about forgotten labs being the top cause of surprise AWS bills is practical advice, and the recommendation to set a CloudWatch billing alarm before the first apply should be standard practice for anyone spinning up ephemeral training infrastructure. The dedicated Cost-Management wiki page covers the stop-vers-destroy tradeoff in more depth.
The documentation strategy is notable: the README is intentionally a thin landing page, with the real operator handbook living in the project wiki — 17+ pages covering prerequisites, deployment modes, per-C2 walkthroughs for Mythic, Sliver, and Adaptix, workstation guides, redirector internals, OpenVPN tunnel environments, cost, and troubleshooting. The troubleshooting page in particular enumerates the failure modes that actually surface in practice: Mythic SSL certificate issues, missing Sliver binaries, Adaptix build failures, agents not calling back, Marketplace OptInRequired errors, VPC limits, redirect.rules download problems, and ssh -R binding behavior. That list doubles as an honest map of where the fragility in this kind of stack lives.
The README carries two governance warnings worth quoting by substance. First, the AWS Terms of Service note: hosting C2 infrastructure may raise concerns under the AWS Acceptable Use Policy, and operators should review the AUP and submit the AWS penetration testing / simulated events request form, ideally running from a dedicated, single-purpose throwaway AWS account. Second, the explicit authorization boundary — no real-world engagements, no targets you do not own and have explicit written permission to test. Both caveats frame redStack as a training instrument, and the project's presence at DEF CON 34 via Adversary Village, Red Team Village, and Noob Village workshops reinforces that educational positioning.
Licensing is MIT with a Commons Clause: free to use, deploy, modify, and share, but commercial use — selling the stack or building a paid product on it — requires written permission. The README also flags a provider-agnostic successor, redStackPRO, a web canvas that composes red team infrastructure and cyber ranges as provider-neutral topologies and compiles them to runnable Terraform and Ansible, with GCP and AWS tested end-to-end and Azure, Proxmox, and ESXi on the roadmap. For teams evaluating redStack today, that roadmap context matters: the AWS version remains functional and documented, but the maintainers' forward investment appears to be shifting toward the successor.
For defenders, redStack has secondary value as a reference implementation. The redirector pattern — Apache fronting C2 traffic with header and URI gating plus scanner blocking — is precisely the infrastructure signature that network defenders should understand when triaging suspicious 80/443 endpoints, and studying how it is provisioned (Elastic IPs, peered VPCs, cloud-init rendered rules) informs both purple-team exercise design and cloud detection engineering against similar unauthorized deployments in real estates.
devZero-Security/redStack.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.