Walk every CloudGoat scenario

CloudGoat is the AWS-attack lab almost every cloud security engineer has worked through at some point. The scenarios are intentionally vulnerable, you deploy them with Terraform into your own AWS account, you exploit them by hand, and then you tear them down. Walking every scenario and publishing your write-ups is the most common single answer to "what should I build for my portfolio?" — interviewers recognize the work instantly.

This page walks you through doing one scenario the way it deserves to be done — slowly, in your own voice, with screenshots — so it's interview-grade rather than a copy-paste of someone else's solution.

What you'll have at the end

• A public write-up per scenario covering the kill chain, the exploit commands you ran, and the IAM / control changes that close the gap.
• Screenshots of the AWS console showing the misconfiguration before and after.
• A short reflection on what surprised you and what you'd do differently next time.
• An archived terraform destroy log proving you cleaned up after each scenario.

Prerequisites

• An AWS account with a credit card and the budget guardrails set up.
• AWS CLI installed and configured with an admin user (not root).
• Terraform 1.x installed.
• Python 3.x and pip.
• A GitHub account for publishing the write-up.

Step-by-step

1. Install CloudGoat

Clone the repo and install Python dependencies:

git clone https://github.com/RhinoSecurityLabs/cloudgoat.git
cd cloudgoat
pip3 install -r ./core/python/requirements.txt
chmod u+x cloudgoat.py

Configure CloudGoat with your default AWS profile and a whitelist of IPs allowed to reach the lab resources (your home IP):

./cloudgoat.py config profile
./cloudgoat.py config whitelist --auto

2. Pick your first scenario

Start with iam_privesc_by_rollback or vulnerable_lambda — both are short, well-documented, and teach the core mental model. List all available scenarios with:

./cloudgoat.py list scenarios

3. Deploy the scenario

./cloudgoat.py create iam_privesc_by_rollback

This Terraforms the vulnerable resources into your account and prints the starting credentials.

4. Exploit it without reading the solution

Resist the urge to read the official walkthrough first. Try to find the misconfiguration yourself with aws sts get-caller-identity, aws iam list-attached-user-policies, and the AWS CLI. Note every command in a scratchpad. Take screenshots when something interesting happens.

5. Confirm the goal

Each scenario has a defined goal ("escalate from this user to AdministratorAccess," "exfiltrate this S3 object," etc.). Confirm you actually achieved it. If you cheated and looked at the solution mid-way, do the next scenario without cheating to recalibrate.

6. Write up the kill chain

In a README.md in your write-up repo, document:

• The scenario name + a one-line summary of the misconfiguration.
• Initial access — the credentials you started with and what they could do.
• Discovery — every CLI command you ran, with output excerpts (redact account IDs).
• Exploitation — the specific command(s) that achieved the goal.
• The MITRE ATT&CK Cloud techniques the path maps to (attack.mitre.org/matrices/enterprise/cloud/).

7. Write the remediation

Equally important: how you'd fix the gap in production. Be specific. "Apply least privilege" doesn't count — write the IAM policy or the SCP. Bonus points: provide it as Terraform.

8. Tear down

./cloudgoat.py destroy iam_privesc_by_rollback

Save the destroy log to your write-up repo as destroy.log — it shows you cleaned up.

9. Publish

Push the repo to GitHub. Add a top-level README that links to each scenario's write-up. Pin the repo on your GitHub profile. Post one LinkedIn update per scenario or one summary post when you're done with all of them.

10. Repeat for every scenario

There are ~10 scenarios. Doing all of them is a 6-week side project that produces an unmistakable portfolio. Doing 3 of them well is enough to make recruiter screens go differently.

What hiring managers look for

• Your write-up is in your own voice with your own screenshots — not paraphrased from the official solution.
• You explain the why behind each step, not just the commands.
• The remediation section is technically specific (an IAM policy snippet, an SCP, a Terraform diff) — not generic advice.
• You map techniques to MITRE ATT&CK Cloud — shows you understand the shared vocabulary.
• There's a "what surprised me" reflection section. Most write-ups skip this; it's the strongest signal of authentic learning.

Common mistakes

• Copy-pasting the official walkthrough. Recognizable instantly; flagged immediately.
• Doing one scenario and stopping. The portfolio value compounds with each additional write-up.
• Forgetting to destroy. NAT gateways and EC2 instances run up bills overnight. Tear down at end of session, every session.
• Skipping the remediation section because "the exploit was the fun part." Hiring managers care more about defenders than attackers.
• Putting it in a private repo. Half the value is being able to send the link.
• Letting your account leak into the screenshots — redact account IDs, IPs, ARNs.

Where to publish

The full publishing playbook is on the portfolio hub page. The short version: a public GitHub repo with a thorough README is the strongest single signal; pair it with a LinkedIn post and (optionally) a 5-minute lightning talk at a CSOH Friday Zoom.