Getting Started with Stream’s CDRGoat

In our launch post we introduced CDRGoat, our scenario-driven project designed to help security teams validate cloud detections against realistic attack paths. With CDRGoat, defenders can practice investigating signals generated by adversary techniques such as SSRF exploitation, IAM privilege escalation, and lateral movement - all in safe, reproducible AWS environments.

Each scenario provisions an intentionally vulnerable environment in your AWS sandbox and includes a full automated attack script. The script replays the attacker’s steps, so defenders can focus entirely on the defensive side: log visibility, alert fidelity, and triage workflows.

This post will walk through how to set up your environment, run your first scenario and start gaining value from the detections it generates.

Get Started with Stream CDRGoat

⚠️ Warning

CDRGoat provisions intentionally vulnerable resources into AWS. It must never be deployed in production. Always use isolated sandbox accounts, expect cloud usage costs while resources are running and ensure resources are destroyed after finishing.

What You Need to Get Started with CDRGoat

Before running your first scenario, you’ll need a few standard tools:

• An AWS sandbox account (never production)
• AWS CLI configured with valid credentials
• jq utility for JSON parsing

On macOS

brew install terraform awscli jq

On Linux

sudo apt update && sudo apt install -y terraform awscli jq

Deploying a Scenario

Each scenario lives in its own folder, containing both a Terraform plan and an attack script. Terraform provisions the resources, including VPCs, EC2 instances, IAM roles, Lambda functions, and more, depending on the scenario.

To Deploy

1cd scenarios/<scenario-name>
2terraform init
3terraform apply -var='attack_whitelist=["<your-ip>/32"]' -auto-approve

Executing the Attack

Once your environment is ready, it’s time to launch the adversary simulation. Each scenario includes a prebuilt attack script designed to replay the attacker’s path step by step.

1chmod +x attack.sh
2./attack.sh

The script may prompt you for inputs, for example, The external env IP address, but these are always provided in the Terraform outputs. As the script runs, adversary techniques such as credential theft, lateral movement, or database access are executed automatically, generating logs and events in CloudTrail, GuardDuty and other security tools installed.

Cleaning Up

When the exercise is complete, destroy the environment with a single command. This ensures all resources are removed, costs are stopped and the environment is ready for the next simulation.

terraform destroy -var='attack_whitelist=[]' -auto-approve

1️⃣ CDRGoat Scenario 1: RCE on EC2 to RDS Pivot

2️⃣ CDRGoat Scenario 2: SSRF on EC2 to Lambda Privilege Escalation

3️⃣ CDRGoat Scenario 3: Privilege Escalation via Lambda and IAM Role Enumeration

Closing Thoughts

Cloud breaches rarely depend on a single vulnerability. They happen when multiple weaknesses combine into a chain that attackers can (and do) exploit. CDRGoat was built to mirror that reality: scenarios that escalate step by step, forcing defenders to test whether their detections hold up in practice.

By deploying your first scenario and running the automated attack, you’ll go beyond writing detection rules and validate how your SOC responds under real conditions. Clone the repository, spin up a scenario in your AWS sandbox, and see how your defenses measure up.

🌟 Explore the CDRGoat GitHub Repo

‍

Disclaimer

This content is provided for educational and informational purposes only. Stream.Security’s CDRGoat is provided as-is without warranties of any kind. By using this project you accept full responsibility for all outcomes. Scenarios are intentionally vulnerable and must only be deployed in isolated, non-production accounts. Stream.Security does not guarantee the accuracy or completeness of the content and assumes no liability for any damages resulting from its use.

Stream.Security does not endorse or condone any illegal activity and disclaims any liability arising from misuse of the material. Stream.Security and project contributors assume no liability for misconfiguration or unintended consequences, including any illegal activity. Ensuring safe and appropriate use is your responsibility.

‍

‍

‍