Capital One 2019: From SSRF to the Metadata Endpoint
also called IMDSv1 Breach
A server-side request forgery reached the cloud instance metadata service, obtained temporary credentials, and used an over-permissioned role to read a very large volume of data.
What happened
In 2019 an attacker exploited a server-side request forgery vulnerability in a misconfigured web application firewall running on an EC2 instance. SSRF lets an attacker cause a server to make requests on their behalf — and the request they induced was to the instance metadata service at a well-known link-local address.
That endpoint returns temporary IAM credentials for the role attached to the instance. With those credentials, the attacker accessed storage buckets and exfiltrated a very large quantity of customer data.
The chain of failures
SSRF vulnerability in an internet-facing component.
A metadata service reachable without authentication from any process on the instance — the design of IMDSv1, which assumed anything running on the host was trusted.
An over-permissioned role. The credentials permitted access to far more data than the WAF's function required. Had the role been scoped to what the component actually needed, the SSRF would have yielded credentials worth very little.
Insufficient detection of anomalous bulk access — a role that normally does very little suddenly reading large volumes should be a strong signal.
The changes
AWS introduced IMDSv2, which requires a session token obtained via a PUT request with a hop limit — defeating the simple SSRF pattern, since an SSRF typically cannot issue the required request or set the required headers. It should be enforced estate-wide, and it is a configuration many organisations still have not applied.
The transferable lesson
Scope roles to function, and assume the workload will be compromised. The determining factor in this breach was not the SSRF — vulnerabilities happen — it was what the credentials on that instance were permitted to do.
The exercise worth running: pick an internet-facing component and ask what an attacker with full control of it could reach. What credentials are in its memory and environment, what does its cloud role permit, what internal services will accept its identity, what data can it read. In most estates the honest answer is far more than anyone expects, and it is directly actionable.