Cloud vulnerability analysis 8

High-level lessons from two public CloudGoat scenarios. Walkthrough commands, credential recovery steps, and lab solve procedures are omitted.

Scenario 7 — codebuild_secrets

Theme. A large AWS lab that chains CI/CD config, parameter store, compute metadata, and database access around poorly protected secrets.

Resources (lab design). CodeBuild projects, Lambda, VPC with RDS and EC2, and multiple IAM users.

Vulnerability classes (concepts).

• Secrets and IAM keys stored in CodeBuild environment variables
• SSH material left in SSM Parameter Store without encryption / least privilege
• Over-broad IAM so a low-privilege starting user can enumerate build and data services
• RDS snapshot / restore paths that can expose data when snapshot permissions are too wide
• Instance metadata (IMDS) and Lambda environment variables used as a secondary secret store

Impact (abstract). In a misconfigured account, an operator who starts with limited IAM access could discover additional credentials and eventually read sensitive strings from a database or related services.

What to check / mitigations.

• Keep build and Lambda env vars free of long-lived keys; prefer roles, secrets managers, and short-lived credentials
• Encrypt SSM parameters and restrict Describe/Get to need-to-know roles
• Limit who can create RDS snapshots, restore instances, and reset master passwords
• Prefer IMDSv2, minimize instance-profile permissions, and avoid putting DB admin passwords in Lambda env
• Separate duties so CI roles cannot also administer data stores

Scenario 8 — ecs_efs_attack

Theme. A large lab about ECS task trust, container credential endpoints, EC2 tag-based authorization, and shared EFS reachability.

Resources (lab design). VPC with multiple EC2 instances, an ECS cluster/service, and EFS.

Vulnerability classes (concepts).

• Starting SSH access to a “ruse” host with an instance profile that can influence ECS
• Weak trust in container/task credentials obtained from the ECS metadata path
• Authorization that hinges on mutable EC2 tags
• Shared filesystem (EFS) exposed to hosts that should not mount it

Impact (abstract). Privilege on one workload could expand to session access on higher-privilege hosts and to data on a shared filesystem.

What to check / mitigations.

• Treat ECS task roles as high value; scope them tightly and monitor task-definition changes
• Do not authorize admin actions solely by attacker-controllable tags
• Restrict SSM session start and EFS mount targets with network and IAM controls
• Segment admin hosts from general compute; audit who can update ECS services

Solve steps and PoC omitted.