CASE-05 · Case Study — Capital One: The Confused Server

What happened

In 2019 Capital One disclosed that an attacker had reached into its cloud environment and walked out with the personal data of tens of millions of credit-card applicants. There was no dramatic password crack and no zero-day. The attacker found a Capital One web application that sat behind a misconfigured web application firewall (WAF) and abused it with server-side request forgery (SSRF) — a class of flaw where an attacker tricks a server into making a request the attacker chooses, using the server's own network position and identity.

The target of that forged request was not another website. It was a special address every EC2 instance can reach — the AWS instance metadata service (IMDS), the endpoint a machine queries to learn about itself. On the first-generation metadata service (IMDSv1) any process on the box — or, through SSRF, anyone who could make the box issue a request — could ask that endpoint for the temporary IAM credentials attached to the server's role. Those credentials came back. With them, the attacker could act as the server: they listed the storage buckets the role could see and copied data out of them. The permissions on that role were far broader than the job required, so "what the server could see" turned out to be a great deal.

See it — one forged request, three failed guardrails

flowchart LR
  A["SSRF via<br/>misconfigured WAF"] --> B["Server calls<br/>metadata endpoint"]
  B --> C["IMDSv1 returns<br/>temp IAM creds"]
  C --> D["Over-broad role<br/>lists S3 buckets"]
  D --> E["Data copied<br/>out of S3"]

The root cause

No single bug explains this breach; it was three weaknesses lined up so that one led to the next. First, SSRF — the application could be induced to make an outbound request to an attacker-chosen destination, and nothing stopped it from reaching an internal-only address. Second, the instance metadata service (IMDSv1) answered a plain, unauthenticated HTTP request and handed back live credentials; it had no way to tell a legitimate query on the box apart from one smuggled in through a confused front-end. Third — and this is what turned access into a catastrophe — the server's IAM role carried far more permission than it needed. SSRF gave the attacker the machine's identity; IMDSv1 handed over that identity's keys; least privilege was supposed to make those keys nearly worthless, and it wasn't there. This is the confused deputy problem: a trusted component (the server) was tricked into wielding its authority on an attacker's behalf.

The control that would have stopped it

Each link had a control that breaks the chain, and defense in depth means you deploy all three so no single miss is fatal. SSRF egress controls — validate and allowlist where a server may send outbound requests, and block application traffic to the metadata IP — stop the forged request from ever reaching the credential endpoint. IMDSv2, which AWS shipped after this incident, requires a session token obtained with a PUT request before the metadata endpoint will answer, and it restricts the response hop limit; a naive SSRF that can only replay a GET no longer gets credentials back. And least-privilege IAM roles — grant a server only the exact buckets and actions its job requires — mean that even if credentials leak, they unlock almost nothing. Any one of these, in place, likely turns this from a headline into a non-event.

The blast radius

The exposed data covered roughly 100 million individuals in the United States and about 6 million in Canada — people who had applied for Capital One credit-card products. Beyond the raw count, the incident became one of the most-cited cloud breaches of its era precisely because the cause was mundane: ordinary misconfiguration and over-permissioning, not exotic attacker skill. It reset how the industry talks about metadata-service security and directly motivated the rollout of a hardened metadata service as a default expectation.

The lesson

A server that will fetch any URL you name, holding keys it never needed, is one forged request away from being the attacker.

Where it rhymes

This is the canonical real-world case of OWASP A10:2021 — Server-Side Request Forgery (SSRF), chained with the confused deputy pattern and a failure of least privilege. In ATT&CK terms it maps to Unsecured Credentials: Cloud Instance Metadata API — abusing the metadata service to harvest role credentials, then using them for discovery and collection against cloud storage. The defensive spine — validate egress, authenticate the metadata service (IMDSv2), and scope every role to the minimum — is the same reflex that shows up wherever a trusted service can be pointed at a target it was never meant to reach.

Named concepts: server-side request forgery, instance metadata service, least privilege, IMDSv2