CloudGoat: Building Vulnerable AWS Infrastructure to Train Your Red Team
Hook
Most security training tells you what not to do. CloudGoat does the opposite: it programmatically deploys exploitable AWS infrastructure so you can practice breaking in without going to jail.
Context
Cloud security failures make headlines regularly—misconfigured S3 buckets, over-permissioned IAM roles, exposed Lambda functions. Yet most security professionals learn cloud penetration testing through documentation and hypotheticals rather than hands-on exploitation. Traditional vulnerable VMs like DVWA or Metasploitable don’t translate to cloud environments where the attack surface involves API permissions, service relationships, and identity federation rather than network ports and web forms.
Rhino Security Labs created CloudGoat to fill this gap. It’s a Python-based orchestration tool that deploys pre-designed vulnerable AWS and Azure architectures into your own cloud account. Each scenario represents a capture-the-flag challenge where you start with limited credentials and exploit misconfigurations to escalate privileges, access sensitive data, or compromise the environment. Think of it as a framework for creating temporary, disposable hacking ranges in the cloud.
Technical Insight
CloudGoat’s architecture separates orchestration logic from scenario definitions. The core Python CLI manages scenario lifecycle—configuration, deployment, state tracking, and teardown—while individual scenarios appear to use Terraform modules that define the actual vulnerable infrastructure.
When you deploy a scenario, CloudGoat creates an isolated instance folder in the project base directory with a unique scenario ID. This folder contains a ‘start.txt’ file with the resources needed to begin the scenario, and sometimes an SSH keypair named ‘cloudgoat’/‘cloudgoat.pub’. The tool tracks scenario state to enable independent creation, reset, and destruction of each scenario.
Here’s what CloudGoat deployment looks like:
# Install CloudGoat
pipx install cloudgoat
# Configure CloudGoat with your AWS profile
cloudgoat config aws
# Configure for Azure if needed
cloudgoat config azure
# Configure whitelist
cloudgoat config whitelist --auto
# Deploy a scenario (specific scenario names not shown in documentation)
cloudgoat create <scenario_name>CloudGoat uses Terraform (version 1.5.0 or higher required) as its infrastructure deployment engine, with the AWS CLI and Azure CLI for cloud authentication. The tool requires Python 3.9+ and includes dependencies like jq for JSON processing. Each scenario instance is tracked independently, allowing multiple scenarios to run simultaneously.
The documentation emphasizes that scenarios vary in difficulty and offer multiple paths to victory. Each scenario includes documentation with clear goals, and CloudGoat aims to provide “focused, curated, high-quality learning experiences” rather than generic vulnerable infrastructure.
CloudGoat’s modularity is designed to permit easy expansion by the community. The tool maintains state information to reliably destroy all resources it created, which is critical given the vulnerable nature of the deployed infrastructure. However, CloudGoat can only manage resources it creates—any resources you create manually during exploitation must be removed before running the destroy command.
One architectural aspect: CloudGoat doesn’t provide a web interface or hosted platform. You need your own AWS or Azure account with sufficient privileges to create and destroy resources including IAM roles, EC2 instances, S3 buckets, and other services.
Gotcha
The README’s warnings aren’t hyperbole—CloudGoat creates genuinely exploitable infrastructure. The tool explicitly states: “DO NOT deploy CloudGoat in a production environment or alongside any sensitive resources.” You need a completely isolated cloud account with no production data, no connectivity to corporate networks, and ideally aggressive cost alerts because scenarios create real cloud resources that generate costs.
Windows support is explicitly absent. The README states “Linux or MacOS. Windows is not officially supported,” though it notes that argument tab-completion specifically requires bash 4.2+ (available on Linux or OSX with some difficulty). WSL may work, but native Windows doesn’t.
Resource cleanup has a critical limitation explicitly documented in the README: “CloudGoat can only manage resources it creates. If you create any resources yourself in the course of a scenario, you should remove them manually before running the destroy command.” If you manually create resources during exploitation, you’re responsible for cleaning those up before destroying the scenario, or Terraform may fail with dependency errors and leave orphaned resources.
The permission requirements can conflict with organizational security policies. Scenarios likely need the ability to create IAM roles and policies, which security teams often restrict. Some scenarios may deploy publicly accessible resources that could trigger automated security alerts or violate compliance requirements even in test accounts. The README warns to deploy in accounts with “sufficient privileges to create and destroy resources” but this broad requirement may conflict with least-privilege policies.
The README includes a warning about the scenario instance folder: “Don’t delete or modify the scenario instance folder or the files inside, as this could prevent CloudGoat from being able to manage your scenario’s resources.” Manual interference with CloudGoat’s state tracking can break the cleanup process.
Verdict
Use CloudGoat if you’re training red teams, preparing for cloud security certifications, or need hands-on practice with realistic AWS and Azure exploitation techniques. The scenario-based approach with documented goals makes it valuable for security consultancies building repeatable training programs or organizations wanting to test their detection capabilities against actual attack patterns. The tool’s focus on “vulnerable by design” infrastructure fills a gap in cloud security training.
Skip if you lack access to a dedicated, isolated AWS or Azure test account with broad permissions to create and destroy resources—this isn’t something you can run in a shared sandbox or limited environment. Also skip if you need Windows support or want a hosted/SaaS solution. CloudGoat requires Linux or MacOS, comfort with Terraform, cloud CLIs, and Python tooling, and is explicitly self-hosted infrastructure-as-code rather than a managed platform. The requirements (Terraform 1.5.0+, Python 3.9+, AWS CLI, Azure CLI, jq) and the need for manual resource cleanup make this a tool for experienced practitioners rather than beginners exploring cloud security.
