Cloud Security
Hands-On Workbook

Meridian Retail Group moved to AWS three years ago. The provider has held up its half perfectly — there's no datacenter breach in this story. Every single thing you'll find in this workbook lives in the "yours" column.

1. Create an AWS Free Tier account

   Use a personal email, never a work one.

2. Enable MFA on the root account immediately

   Then never use root again for daily work.

3. Set a billing alarm

   AWS Budgets console, alert at $1 and $10 — before you do anything else.

4. Create a dedicated IAM user for yourself

   With AdministratorAccess for lab purposes, and generate access keys for it.

5. Install and configure the AWS CLI

   Using that IAM user's keys, never root's.

6. Install Prowler

   You'll use it from Module 4 onward.

# verify your CLI is talking to the right account
aws sts get-caller-identity

# install Prowler
pip install prowler

1. Open a policy in your own account

   Find one attached to any role in the IAM console.

2. Read it line by line

   What does each Action/Resource pair actually permit?

3. Look for wildcards

   "*" in either the Action or Resource field.

4. Run it through the IAM Policy Simulator

   Simulate a specific action and see whether it's actually allowed.

5. Spot misleading names

   Any policy whose name undersells what it actually permits.

// danger sign #1: wildcard action AND wildcard resource together
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// danger sign #2: LOOKS like read access — iam:PassRole + compute is a privesc primitive
{
  "Effect": "Allow",
  "Action": ["iam:PassRole", "lambda:CreateFunction", "lambda:InvokeFunction"],
  "Resource": "*"
}

1. Read the Level 1 hint carefully

   At flaws.cloud — it's written like a real engagement note, on purpose.

2. Level 1

   Find a publicly listable S3 bucket and read its contents directly.

3. Level 2

   Same misconfiguration class, slightly less obvious entry point.

4. Level 3

   Find credentials accidentally exposed inside the bucket, then use them with the AWS CLI.

5. Document the root cause

   One sentence per level — that sentence is the skeleton of a real finding.

# levels 1/2 pattern: list a bucket's contents directly via its REST endpoint
aws s3 ls s3://[bucket-name] --no-sign-request

# level 3 pattern: once you have leaked keys, check what they can see
aws sts get-caller-identity --profile flaws
aws s3 ls --profile flaws

1. Clone CloudGoat

   And install its Python requirements.

2. Create a dedicated IAM user for CloudGoat

   Never root — and configure an AWS CLI profile for it.

3. Whitelist your IP

   CloudGoat locks every scenario's vulnerable resources to your IP only.

4. Deploy an IAM privilege-escalation scenario

   E.g. iam_privesc_by_rollback or iam_privesc_by_attachment.

5. Enumerate from low privilege

   Starting from the credentials CloudGoat gives you, find the escalation path.

6. Confirm, then destroy

   Verify admin-equivalent access, then immediately tear the scenario down.

git clone https://github.com/RhinoSecurityLabs/cloudgoat.git
cd cloudgoat
pip3 install -r ./core/python/requirements.txt

# deploy a privilege-escalation scenario into YOUR account
./cloudgoat.py create iam_privesc_by_rollback --profile cloudgoat

# when you're done — every time, no exceptions
./cloudgoat.py destroy iam_privesc_by_rollback --profile cloudgoat

Three layers stack to decide bucket access: Bucket Policy (resource-based), ACLs (legacy, mostly deprecated), and Block Public Access (an account- and bucket-level override switch). AWS now defaults Block Public Access ON for new buckets — but Meridian's buckets predate that default.

1. List every bucket in your account

   Or Meridian's shared practice set, if your instructor has provided one.

2. Check Block Public Access settings

   For each bucket.

3. Check the bucket policy directly

   For any Principal: "*" statement.

4. Check object-level ACLs

   For "AllUsers" or "AuthenticatedUsers" grants.

5. Identify which layer allowed it

   For any bucket that's actually public — Policy, ACL, or a disabled Block Public Access switch.

# check Block Public Access at the bucket level
aws s3api get-public-access-block --bucket [bucket-name]

# check the bucket policy itself
aws s3api get-bucket-policy --bucket [bucket-name]

1. Read the two-path structure

   At flaws2.cloud — the second half requires your own AWS account.

2. Complete the first path

   Focused on S3/CloudFront misconfiguration.

3. Move into the container-escape path

   You're given access to a container and need to find a way out.

4. Identify what allows the escape

   Privileges, mounted volumes, or metadata service access.

5. Document the root cause

   Same one-sentence format as Lab 1.2.

1. Check default encryption

   On every S3 bucket in your account.

2. Identify the key type

   SSE-S3 (AWS-managed) or SSE-KMS (a key you control and can audit).

3. Check EBS encryption-by-default

   At the account/region level.

4. Know which choice fits where

   SSE-S3 is fine for low-sensitivity data; SSE-KMS is what lets you audit exactly who can decrypt.

# check a bucket's default encryption configuration
aws s3api get-bucket-encryption --bucket [bucket-name]

# check account-level EBS encryption-by-default
aws ec2 get-ebs-encryption-by-default

1. Check for an existing trail

   Many accounts have only the default 90-day event history, not a full trail.

2. Enable a multi-region CloudTrail trail

   Logging to an S3 bucket, if one doesn't already exist.

3. Enable GuardDuty

   AWS's managed threat detection — mindful of its free trial period and cost after.

4. Confirm both are receiving data

   Not just configured — actually logging.

# check for an existing multi-region trail
aws cloudtrail describe-trails

# enable GuardDuty (mindful of cost after the free trial period)
aws guardduty create-detector --enable

1. Open CloudTrail Event History

   Or query the S3-stored logs if you disabled the default history.

2. Filter for the right time window

   Around when you ran Lab 1.3's CloudGoat scenario.

3. Find the escalation API calls

   Look for iam:AttachRolePolicy, iam:CreatePolicyVersion, or sts:AssumeRole.

4. Trace the sequence

   Which identity made which call, in what order, leading to elevated access.

5. Write a CISO-ready summary

   3–4 sentences describing exactly what you found.

# search Event History for a specific event type around your CloudGoat exercise
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AttachRolePolicy

1. Re-read your evidence

   Lab 1.2's flAWS findings, Lab 1.3's CloudGoat escalation, Lab 3.2's CloudTrail evidence.

2. Write one incident narrative

   How would an attacker chain these three weaknesses together, start to finish, in a real account?

3. Name the control for each step

   What would have stopped it — Block Public Access, least-privilege IAM, MFA, alerting on AttachRolePolicy?

4. Conclude with an executive summary

   One paragraph, written for someone who has never seen a terminal.

1. Install Prowler

   If you haven't already from Lab 0.2.

2. Grant read-only audit access

   Attach the AWS-managed SecurityAudit and ViewOnlyAccess policies to your lab IAM user — enough to see everything, not enough to change anything.

3. Run a full scan

   Against your account.

4. Generate an HTML report

   And open it.

5. Read the top 10 by severity

   Note how many map directly to what you found manually in Modules 1–2.

# run a full AWS scan with HTML output
prowler aws --output-formats html json --output-directory ./prowler-results

1. List supported frameworks

   Prowler supports several compliance frameworks for AWS.

2. Re-run scoped to one framework

   E.g. CIS or NIST 800-53.

3. Map five findings to NIST CSF functions

   Identify, Protect, Detect, Respond, Recover — using what you already know.

4. Recognize the real-world parallel

   This mapping is exactly what auditors expect walking into Meridian's SOC 2 review.

# list available compliance frameworks for AWS
prowler aws --list-compliance

# run scoped to a specific framework
prowler aws --compliance cis_2.0_aws

1. Take your top 5 Critical/High findings

   From Lab 4.1.

2. Write five fields per finding

   The finding, the business risk in plain language, the specific fix, an owner role, a target date relative to the 90-day deadline.

3. Flag quick wins vs. projects

   Fixable in under an hour, versus needing a structural project (e.g. account-wide key rotation).

4. Sequence the plan

   Quick wins first, so visible progress happens before the audit even if everything isn't finished.

1. Create an Azure free account

   And set a budget alert immediately — same discipline as Lab 0.2.

2. Install the Azure CLI

   And log in.

3. Clone AzureGoat and deploy with Terraform

   Into a dedicated resource group.

4. Work through identity-related escalation paths

   App registrations and managed identities — the closest analog to Module 1's AWS IAM work.

5. Destroy the resource group

   Completely, when finished.

git clone https://github.com/ine-labs/AzureGoat.git
cd AzureGoat

# log in and create a dedicated resource group first
az login
az group create --name azuregoat_app --location eastus

terraform init
terraform apply

1. Create a GCP free trial account

   And set a budget alert.

2. Install the gcloud CLI

   And authenticate.

3. Clone GCPGoat and deploy with Terraform

   Into a dedicated project.

4. Work through IAM roles, storage, and Cloud Functions

   The three areas its modules focus on.

5. Destroy every resource

   And consider deleting the dedicated project entirely.

git clone https://github.com/ine-labs/GCPGoat.git
cd GCPGoat

gcloud auth login
gcloud config set project [your-dedicated-project-id]

terraform init
terraform apply

1. Re-run Prowler multi-cloud

   Against any of the three accounts you still have available.

2. Note one default-secure and one default-open setting per provider

   Based on what you actually saw, not general reputation.

3. Write a comparison brief

   Which provider's defaults would you trust most out of the box, and why?

4. Tear down everything, everywhere

   Confirm via each provider's console, not just CLI output.