redStackPRO is a web canvas that compiles drawn attack-infrastructure and AD-range topologies into runnable Terraform and Ansible exports for authorized lab work.
| Tool | devZero-Security/redStackPRO — a web canvas that compiles red team infrastructure and cyber range topologies into runnable Terraform + Ansible exports |
| Category | Infrastructure-as-code composition layer for offensive security labs and ranges |
| Primary Use | Drawing attack infrastructure (Sliver, Mythic, redirectors, jumpboxes) or defensive AD ranges like GOAD on a canvas, then exporting and deploying the resulting Terraform/Ansible working directory yourself |
| Safe Use | Explicitly restricted by the authors to lab environments you own or are authorized to test in writing; suited for authorized red team training, range building, and defensive detection engineering |
| Telemetry Note | Deploys are fully visible in your own cloud account's audit trails (CloudTrail, GCP audit logs) since terraform apply runs under your credentials; deploy.sh writes a secret-scrubbed log to logs/deploy-<timestamp>.log; the tool itself never holds credentials or deploys anything |
redStackPRO, published by devZero-Security as a prerelease beta at version 0.9.0 under an MIT license, takes an unusual architectural stance in the crowded space of red team tooling: it is purely a composition layer. You draw a topology on a web canvas — attack infrastructure and deliberately vulnerable target ranges share the same drawing surface — and the tool compiles that drawing into roughly 200 files of Terraform and Ansible, a deploy.sh, and a briefing document. The tool then steps out of the way entirely: you run the export from your own machine, under your own cloud credentials. The README is emphatic on this point, calling the export itself the trust boundary — redStackPRO never deploys anything and never holds a secret.
The canvas distinguishes two modes, Offense and Defense, which map to the two halves of an engagement-training workflow. An Offense drawing produces attack infrastructure — the README highlights a split-horizon C2 example with two independent front doors, Apache fronting Sliver and Nginx fronting Mythic, each redirector on its own peered network, with teamservers, an OpenSearch collector, operators, and a jumpbox behind it. A Defense drawing produces vulnerable Active Directory ranges, and the export names its handoff file OFFENSE-BRIEFING.md or DEFENSE-BRIEFING.md accordingly. That single file tells you the generated credentials and what misconfigurations are planted where, which is a thoughtful touch for range documentation.
The defense side ships with recognizable reference blueprints. GOAD — the well-known three-domain, two-forest lab with five machines and their intra- and cross-forest trusts — is drawn on the canvas as a first-class blueprint, and a lighter variant goad-light compiles from the command line without opening the browser at all: redstackpro compile frontend/public/goad/goad-light.json -o export. That headless path matters because it proves the canvas is only a frontend to a deterministic compiler — the same compiler, same output, whether a human draws or a script submits JSON. A smaller Harbor blueprint (a parent-child forest trust with a phished-workstation-to-domain path) rounds out the shipped starting points.
The multi-operator story is one of the more interesting design details in the README. An attack-infrastructure jumpbox can declare a list of operators (handle plus role), each of whom receives a Guacamole portal login plus — if access_mode is set to wireguard or openvpn — a personal VPN credential generated on the jumpbox at apply time. The keys never leave the box or enter the export; only the client config file does. The README is candid about the current weakness: portal logins today share one lab password, so per-operator isolation comes from VPN credentials rather than portal authentication, with individual portal passwords on the roadmap. Adding a teammate to a running jumpbox is a single sudo rsp-operator add <handle>.
Deployment mechanics are deliberately conservative. deploy.sh applies the Terraform and then provisions from the range's own jumpbox, because managed hosts sit on a private subnet nothing else can reach — a sensible default that mirrors how production environments are actually structured. The script copies deploy.tfvars into terraform/terraform.tfvars at apply time and aborts if the root file is missing, preventing the classic drift failure where someone edits the wrong variables file. On Windows, a manage.ps1/deploy.ps1 pair is provided, and the README explicitly warns that invoking bash deploy.sh from PowerShell launches WSL with a different filesystem and credentials. Lifecycle continues after deploy: manage.sh status|start|stop|teardown lets you pause billing without destroying a range, which anyone who has left a forgotten lab burning cloud spend will appreciate.
Provider coverage at this beta stage is GCP and AWS, tested end to end for both target ranges and attack infrastructure, with Azure, Proxmox, and ESXi on the roadmap — the repo topics confirm the intended breadth. The AWS quota planning section is unusually practical for a tool README: it walks through elastic IP limits (5 per region by default, roughly 2 consumed per defense range and 3 per offense range), vCPU ceilings where a full AD range plus SIEM can exceed defaults because hosts are mostly t3.large/t3.medium, and the one-time per-region Kali Marketplace subscription. The point it makes repeatedly is that a compile does not check quotas, so a large apply can fail partway and leave instances running and billing — the exact failure mode that wastes money and leaves stray infrastructure exposed.
Getting started is straightforward. The whole canvas ships in one container with API and web app on a single port: docker run -p 8000:8000 -v redstackpro-data:/data ghcr.io/devzero-security/redstackpro:0.9.0. Running from source requires Python 3.11+, Node 24, and pip install -e ".[dev]" before splitting into redstackpro serve for the API and npm run dev inside frontend/ for the canvas. The image carries no Terraform or Ansible and never sees cloud credentials; it only generates code. Prerequisites are on you: terraform, ssh, tar, Python 3.8+, and cloud identities with the right permissions (AmazonEC2FullAccess on AWS, roles/compute.admin on GCP), with Ansible self-installing on the jumpbox.
The headless API story deserves attention from anyone building automation. Everything the canvas does is exposed over REST: a topology is plain JSON validated against a published schema living in src/redstackpro/schema/topology/ and served at /api/v1/registry/schema, registry endpoints enumerate node kinds, providers, and roles, and the validate/compile steps the UI calls are the same endpoints. Documentation lives at /docs and /openapi.json, which the README notes an LLM agent can consume directly as tools. There is also an optional Postgres backend via REDSTACKPRO_DATABASE_URL with the compose postgres profile for shared team deployments — a signal that the project anticipates multi-user range-management scenarios beyond a single operator's laptop.
From a defensive perspective, redStackPRO is as valuable for blue teams as red: the Defense mode builds the AD ranges (GOAD-style trusts, phishable workstations, planted misconfigurations) that detection engineering and purple-team exercises depend on, with a DEFENSE-BRIEFING.md documenting exactly what weaknesses exist so defenders can write targeted detections. Operationally, because every deployment runs through terraform apply under your own credentials, the entire activity is visible in your cloud provider's audit logs — CloudTrail or GCP audit logs — making the tool trivially auditable in environments where that matters. The generated logs/deploy-<timestamp>.log files are secret-scrubbed deployment records that double as an operational paper trail for the range owner.
The authorization framing is not an afterthought. The README carries an explicit CAUTION callout: the tool builds offensive infrastructure and deliberately vulnerable ranges, and is to be used only in lab environments you own or are explicitly authorized to test, never against systems without written permission. That positioning, combined with the export-as-boundary architecture — no credential custody, no deploy capability — makes redStackPRO a clean fit for authorized engagements, internal training programs, and academic lab construction rather than anything adversarial against third parties. It is functionally a range compiler with an opinionated security model.
Caveats are the usual beta ones, stated honestly by the authors: the topology schema is still moving, Azure/Proxmox/ESXi support is absent, and stability-seekers should pin to a released version. At roughly 69 stars, the project is early in its life, and the maintainers actively solicit scrubbed deploy logs attached to GitHub issues to diagnose failures, printing the log path and issue link automatically when a run goes wrong. For teams currently hand-rolling red team infrastructure in Terraform or rebuilding GOAD from scattered scripts, the value proposition — draw once, compile to reviewable infrastructure-as-code, deploy and tear down under your own control — is a credible workflow improvement worth watching as the provider matrix fills out.
devZero-Security/redStackPRO.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.