DataArena
The $100M Metadata Heist: How SSRF Breached Capital One's AWS IAM
CYBER THREAT & EXPLOIT CASE STUDIESReal-World Breach Forensics

How Sites Get Hacked

Forensic breakdowns of multi-million dollar data breaches, state-sponsored cyber warfare, AI-generated code vulnerabilities, and how security auditors bulletproof web systems.

Inspect Worst Deals Ever Store
CRITICAL THREATCWE-918 / Server-Side Request Forgery7 min read

The $100M Metadata Heist: How SSRF Breached Capital One's AWS IAM

How a former cloud software engineer exploited a Server-Side Request Forgery (SSRF) flaw in an open-source AWS WAF to query the AWS EC2 Instance Metadata Service (169.254.169.254), stealing temporary IAM admin tokens and exfiltrating 100 million credit card applications.

Documented Real-World Damage: $190M Legal Settlement & 100M Credit Card Applications Stolen
Interactive Exploit Sandbox

Simulate Attack Payload vs. Defense

Injected Payload (Attacker Input):
http://169.254.169.254/latest/meta-data/iam/security-credentials/WAF-Role
Server Execution Result (Unpatched Application):EXPLOIT SUCCEEDED
SSRF Succeeded! Internal Metadata Returned:
AccessKeyId: ASIAIOSFODNN7EXAMPLE
SecretAccessKey: wJalrXUtnFEMI/...
Token: IQoJb3JpZ2luX2VjE...
Attacker acquired full S3 storage read permissions.

Source Code Dissection & Fix

// Vulnerable WAF / Reverse-Proxy Relay Endpoint:
app.get('/proxy-check', async (req, res) => {
  const targetUrl = req.query.url;

  // FATAL FLAW: Server fetches any URL requested by the user without validation!
  // Allowed attacker to target local link-local cloud metadata IP!
  const response = await fetch(targetUrl);
  const data = await response.text();

  res.send(data);
});

The Capital One Cloud Breach

In 2019, Capital One suffered one of the largest financial cloud breaches in history: 100 million credit card applications, 140,000 Social Security numbers, and 80,000 bank account numbers were stolen.

The intrusion was accomplished through **Server-Side Request Forgery (SSRF)** against a misconfigured open-source Web Application Firewall (ModSecurity) running on an Amazon EC2 instance.

The Link-Local Magic IP: 169.254.169.254

In Amazon Web Services, every EC2 virtual machine can communicate with an internal, non-routable IP address: ```text http://169.254.169.254/ ```

This is the **Instance Metadata Service (IMDS)**. When an EC2 instance needs to know its own IP, hostname, or IAM role credentials, it sends a simple HTTP GET request to this address.

Because the WAF had an SSRF flaw that fetched URLs on behalf of users, the attacker commanded the WAF to request: ```text http://169.254.169.254/latest/meta-data/iam/security-credentials/ ```

The internal server answered with temporary AWS security credentials (`AccessKeyId`, `SecretAccessKey`, `Token`).

The S3 Sync Exfiltration

The WAF's IAM role had been over-privileged with full read access to all corporate S3 storage buckets. The attacker copied the temporary credentials onto her home laptop and ran:

aws s3 sync s3://capitalone-credit-cards .

Within hours, 700 S3 buckets containing 100 million credit applications were exfiltrated.

How IMDSv2 Neutralized SSRF

AWS introduced **IMDSv2** specifically to eradicate this entire class of vulnerability. IMDSv2 requires a `PUT` request with a custom header (`X-aws-ec2-metadata-token-ttl-seconds`) to establish a temporary session token before reading metadata. Because SSRF vulnerabilities rarely support custom HTTP headers, IMDSv2 stops metadata extraction in its tracks.

Finished reviewing this exploit case study?

Mark it as analyzed below, or click Next Report to auto-complete.

The $100M Metadata Heist: How SSRF Breached Ca… · DataArena