[redStackPRO]
redStackPRO: red team infrastructure and cyber ranges
Validation range for red team operations

Red team infrastructure, composed on a canvas.

redStackPRO is a visual canvas for red team infrastructure and cyber ranges. Compose a topology, then export a complete, runnable working directory of Terraform and Ansible. You run it from your own machine. redStackPRO never holds your cloud credentials.

View on GitHub Read the quickstart
$ docker run -p 8000:8000 -v redstackpro-data:/data ghcr.io/devzero-security/redstackpro:latest
Attack and defense, one surface

Compose your topology on the canvas.

Offense and defense are the same tool, the same export, the same deploy. Draw the range yourself, or start from a shipped lab and edit it.

Offense · attack infrastructure
An offense topology on the redStackPRO canvas: a split-horizon C2 with Apache fronting Sliver and Nginx fronting Mythic and Adaptix, plus a jumpbox, operators, and an OpenSearch collector.
A split-horizon C2: Apache fronting Sliver and Nginx fronting Mythic and Adaptix, plus a jumpbox, operators, and an OpenSearch collector. The two errors are the canvas validating as you build: the redirectors need a domain you control, set before deploy and caught here, not at apply time.
Defense · target range
A defense topology on the redStackPRO canvas: the GOAD lab with the sevenkingdoms, north, and essos domains across two forests, five machines, and a jumpbox.
The GOAD lab: the sevenkingdoms, north, and essos domains across two forests, with five machines and a jumpbox.
One canvas, three roles

Attack, target, and telemetry on the same canvas.

Every node is colored by what it does, so a range reads at a glance. Each color means one thing, and it holds that meaning everywhere.

Offense

Attack infrastructure

Redirectors, request gating, and C2 blueprints for Mythic, Sliver, and Adaptix. Tested on GCP, AWS, and Azure.

Defense

The target side

Active Directory ranges, ACLs, and vulnerabilities. GOAD and other labs compile through the same pipeline. Tested on GCP, AWS, and Azure, with Windows 11 workstations on Azure.

Sensor

Telemetry and detection

Collectors and log pipelines on the offense or defense side, so an operation leaves evidence you can inspect.

From topology to range

Design, download, deploy.

The canvas is a composition layer. It generates the working directory and hands it to you. Nothing in that chain reaches your cloud on your behalf. It also has an API and a command line, so an agent can read the schema and drive the compose, validate, and compile steps.

01 / Design

Compose the topology

Draw the range on the canvas, or start from a shipped lab like GOAD and edit it as a baseline.

02 / Download

Compile the topology

One topology becomes Terraform for the cloud and Ansible for the hosts, with a briefing on what is planted where.

03 / Deploy

Run it yourself

Fill in deploy.tfvars and deploy with one command: deploy.sh on macOS or Linux, deploy.ps1 on Windows. Your credentials stay on your machine, and teardown asks before it deletes anything. Every shipped target range has a written walkthrough, listed in the wiki.

Deploy · your terminal
A PowerShell terminal in C:\ranges\goad-light running .\deploy.ps1 for GOAD-Light, a four-host Active Directory range on Azure eastus2. Under the redStackPRO wordmark and the DEPLOY GOAD-Light header, step 1 of 8, preflight, reports 4 VMs on Standard_D2as_v7 with a quota of 8 of 10 vCPU, and step 2 of 8, Terraform apply, shows a plan of 41 to add followed by the first resources created, each with its time.
deploy.ps1 for GOAD-Light, a four-host AD range in Azure: a preflight check of VM sizes and vCPU quota, then the Terraform plan and each resource as it is created.
Done · what to run next
The end of the same deploy. Steps 3 to 8 each finish ok, from filling the inventory to launching provisioning on the jumpbox in a screen session that keeps going if you disconnect. A green DONE box reads: Infrastructure is up. Provisioning is running. It lists the Guacamole portal URL, the terraform output command for logins, a one-line ssh command that runs rsp-watch to follow provisioning and return when the run ends, and that the run is finished when run.log shows RUN EXITED ok=1, in 45 to 75 minutes.
The end of the same run: provisioning keeps going on the jumpbox in a screen session, and the DONE box gives the portal URL, the commands for logins and for watching the run, and how long it takes.

A range to validate TTPs and tooling before an operation. Built for rehearsing them, not teaching them from scratch.