AWS CloudGoat EC2 SSRF Exploitation

by

Author: Raj Chandel (published on Hacking Articles)
Published: April 22, 2026
Source: https://www.hackingarticles.in/aws-cloudgoat-ec2-ssrf-exploitation/

Summary

This Hacking Articles tutorial walks through the ec2_ssrf scenario in CloudGoat, Rhino Security Labs’ open-source “vulnerable by design” AWS training framework. It is a CTF-style, hands-on lab rather than a vulnerability disclosure — there is no CVE. The scenario chains a Server-Side Request Forgery (SSRF) flaw in a web application into full cloud compromise by using the EC2 Instance Metadata Service (IMDS) to steal IAM role credentials, then pivoting through Lambda and S3 to reach administrator access. Its purpose is to teach a classic cloud attack path and, more importantly, the controls that break it (chiefly IMDSv2).

Technical Details

The lab is deployed with the CloudGoat CLI (cloudgoat create ec2_ssrf), which uses Terraform to stand up the vulnerable environment. The attack chain proceeds through several stages, each pivoting to a more privileged identity:

  • SSRF → IMDS. The web application can be coerced into making a request to the EC2 metadata endpoint at the link-local address 169.254.169.254. Querying /latest/meta-data/iam/security-credentials/ returns the attached IAM role name, and querying that role path returns temporary credentials (access key ID, secret key, and session token). This works because the instance uses IMDSv1, where the metadata service answers unauthenticated HTTP requests.
  • Credential pivoting. The stolen role credentials are loaded into an AWS CLI profile and used to enumerate the account — for example listing Lambda functions and describing EC2 instances.
  • Lambda secrets. A Lambda function exposes credentials stored in plaintext environment variables, yielding a second, more capable identity.
  • S3 to admin. That identity can read an S3 bucket holding administrator credentials, and the escalation ends by invoking a sensitive Lambda function with the elevated permissions. Each step is performed with standard AWS CLI commands, not custom exploit code.

The vulnerabilities demonstrated are architectural misconfigurations rather than software bugs: an unrestricted SSRF sink, IMDSv1 exposing role credentials to any request that reaches it, secrets stored in Lambda environment variables and in S3 objects, and over-privileged IAM roles without least-privilege scoping. The article also stresses tearing the lab down afterward (cloudgoat destroy ec2_ssrf) to avoid AWS charges.

Impact

Chained together, these weaknesses take an attacker from a single web-app SSRF to administrative control of the AWS account: read access across services via successively compromised identities, the ability to invoke privileged Lambda functions, and retrieval of stored credentials. This models a very common real-world cloud breach pattern — SSRF is one of the most frequent initial vectors for cloud credential theft precisely because IMDSv1 hands out role credentials to whatever can reach the metadata address.

Mitigation

The scenario is built to illustrate defenses, and the primary one is enforcing IMDSv2:

  • Require IMDSv2 (set instance metadata options to http-tokens = required) so metadata requests need a session token obtained via a PUT — an SSRF that can only issue simple GETs can no longer read credentials. Also set a low metadata hop limit and disable IMDS entirely on instances that do not need it.
  • Prevent/limit SSRF at the application layer (validate and allow-list outbound request targets) and add network-layer egress controls that block traffic to 169.254.169.254 from application workloads.
  • Do not store secrets in Lambda environment variables or S3 objects; use AWS Secrets Manager (or SSM Parameter Store) with encryption and tight access policies.
  • Apply least-privilege IAM so a stolen instance/role credential grants minimal access, and avoid over-broad roles that enable cross-service pivoting.
  • Monitor and rotate. Audit Lambda environment access, watch CloudTrail for anomalous use of instance-role credentials from unexpected sources, and rotate credentials regularly.

References

Leave a Comment