attack_range from Splunk deploys production-like cloud labs across AWS, Azure, and GCP, simulates adversary techniques, and streams telemetry into Splunk for authorized detection engineering.
| Tool | splunk/attack_range — builds instrumented, attack-simulated cloud environments for detection development and testing |
| Category | Security lab automation and attack simulation platform |
| Primary Use | Standing up reproducible Splunk-instrumented labs in AWS/Azure/GCP, running Atomic Red Team simulations, and validating detections against real telemetry |
| Safe Use | Designed exclusively for authorized detection engineering, purple-team exercises, and security research in self-owned lab environments; it is a defensive testing platform, not an attack tool against third parties |
| Telemetry Note | As a lab builder it is inherently observable: all simulated adversary activity is intentionally forwarded into Splunk for detection tuning, so every action it simulates produces the exact telemetry defenders would monitor in production |
splunk/attack_range is one of the most established open-source projects in the detection engineering space, currently sitting at roughly 2,568 stars on GitHub, written in Python, and released under the permissive Apache-2.0 license. Now at major version 5, it answers a problem every detection team eventually hits: you cannot write reliable detections for adversary behavior you have never observed in real telemetry. The tool solves this by deploying a small, production-like environment in your own cloud tenant — AWS, Azure, or GCP — instrumented with Splunk, Windows and Linux servers, and optional components such as Kali and Zeek, then deliberately simulating attacks inside it so the resulting logs land in Splunk for analysis.
The architecture, as described in the README, is a layered pipeline. Provisioning is handled by Terraform for cloud infrastructure and Ansible for configuration and role application inside the built machines. Templates are organized per provider under templates/{aws,azure,gcp}/, and each deployed range gets its own configuration file in config/<attack_range_id>.yml. This split means the project is effectively a declarative lab factory: you pick a template such as aws/splunk_minimal_aws, and the tool orchestrates the full chain from empty cloud account to instrumented range without you writing any infrastructure code yourself.
Version 5 marks a significant operational shift in how the tool is consumed. The preferred deployment method is now Docker Compose, which bundles the web application, a REST API, and an optional CLI profile into a single compose stack — eliminating the need to install local Python, Ansible, or Terraform dependencies on the operator workstation. This containerized control plane approach makes the tool considerably more approachable for teams that want repeatable lab tooling without polluting engineering laptops with provisioning toolchains.
After starting the stack with docker compose -f docker/docker-compose.yml up, two interfaces become available. The web app listens on port 4321 and exposes the full lifecycle — building and destroying ranges, checking status, running simulations, and sharing access. The REST API serves on port 4000 with interactive documentation at /openapi/swagger, which is the natural integration point for automation from scripts or CI pipelines. Endpoints such as POST /attack-range/build and GET /attack-range/status/<id> let external tooling drive range creation programmatically, which is where the platform becomes genuinely useful for regression-testing detections as part of a pipeline.
A distinctive design decision is the build flow's two-phase VPN handshake. When you initiate a build, the system provisions to a state the README labels *Waiting for VPN* — at that point you download a generated WireGuard configuration, establish the tunnel, and then continue the build. This pattern reflects a deliberate trust boundary: the range is network-isolated from the public internet, and access is brokered through WireGuard rather than exposing lab services directly. It also enables the share action, which generates additional client configurations so colleagues — say, a purple team or a detection engineer on another continent — can reach the same range securely.
The simulation layer is where the tool earns its keep for defenders. attack_range integrates Atomic Red Team and other technique frameworks to execute adversary behaviors mapped to MITRE ATT&CK, generating authentic telemetry from the simulated Windows and Linux hosts. For a detection engineer, this is the core value proposition: instead of theorizing about what a technique looks like in logs, you execute it in a controlled, owned environment and immediately query the resulting events in Splunk to iterate on detection logic. The contributor list reads like a roll call of Splunk's security research organization, including Patrick Bareiß, Jose Hernandez, Michael Haag, Rod Soto, and many others, which signals sustained vendor investment rather than a hobbyist project.
For terminal-centric workflows, the CLI remains available and can be invoked inside the compose stack via the cli profile — docker compose --profile cli -f docker/docker-compose.yml run --rm attack_range — with actions covering build, destroy, simulate, apply-role, and share. The apply-role action is worth noting for lab maintenance: it lets you re-run individual Ansible roles against an existing range, which is useful when you want to add a component or repair configuration without tearing down and rebuilding the entire environment — a meaningful time saver given cloud build times.
Credential handling follows standard cloud conventions. The README directs users to configure ~/.aws, ~/.azure, or ~/.config/gcloud locally and mount those directories into the containers as shown in docker/docker-compose.yml. This keeps the control plane stateless with respect to secrets and lets organizations apply their own credential management — including short-lived or scoped cloud credentials — rather than baking keys into tooling. It is a small detail, but one that indicates the project assumes a professional audience operating within organizational security boundaries.
From a defensive observability standpoint, attack_range is the rare security tool that is intrinsically telemetry-positive. Everything it simulates is intentionally forwarded into Splunk inside the range, so the artifacts of Atomic Red Team executions — process events, registry modifications, network connections captured by Zeek — are preserved precisely for detection development. Teams can export the resulting detections as research artifacts, and the lab itself is destroyed with a single destroy action when the engagement ends, limiting cloud spend and sprawl.
Documentation is a strong point. Full documentation is hosted on Read the Docs at attack-range.readthedocs.io, with chapters covering getting started, configuration, networking, sharing, templates, and Ansible roles — enough depth to customize templates and roles for organization-specific lab topologies. Support flows through the GitHub issue tracker, the #security-research room in the Splunk Slack, and Splunk Answers, with formal support entitlement available for Splunk Enterprise customers. The CONTRIBUTING guide in docs/CONTRIBUTING.md and the large contributor roster suggest an actively maintained community trajectory.
The project's topic tags — attack-simulation, detection, lab, simulation, adversary — accurately describe its position in the ecosystem: it sits at the intersection of red team tooling and blue team analytics without being either. For authorized security teams, its place in the workflow is concrete and repeatable: stand up a range, simulate a technique, observe the telemetry, tune the detection, and destroy the environment. That closed loop, executed entirely inside infrastructure you own, is exactly why attack_range has become a reference platform for detection engineering programs and purple team exercises rather than merely a convenience for lab hobbyists.
splunk/attack_range.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.