Breach Teardown
What Caused the Capital One Breach?
The Capital One breach remains the reference case for cloud identity failure. A server-side request forgery against a misconfigured web application firewall yielded temporary credentials for an IAM role, and that role’s permissions reached hundreds of S3 buckets it had no business touching. Data on roughly 106 million credit applicants followed.
- Scale
- ~106M individuals
- Attack vector
- SSRF to an over-permissioned cloud IAM role
- IAM domains implicated
- Cloud, Security
- Domino controls hit
- 2 of 4
The Incident
What Happened
In July 2019, Capital One disclosed that an attacker had accessed personal information of approximately 100 million people in the United States and 6 million in Canada, largely credit card application data. The exposure included about 140,000 US Social Security numbers, 80,000 linked bank account numbers, and roughly 1 million Canadian Social Insurance Numbers.
The technical chain, reconstructed in detail by academic and industry analyses, began with a server-side request forgery (SSRF) attack against a misconfigured open-source web application firewall running on an EC2 instance. The SSRF reached the cloud metadata service, which returned temporary credentials for the WAF’s IAM role. That role was provisioned with permissions far beyond what a firewall needs. It could list and read a large population of S3 storage buckets, which the attacker proceeded to sync.
Detection came from outside. Months after the exfiltration, an external tipster emailed Capital One’s responsible disclosure address about data posted publicly. In 2020, the OCC assessed an $80 million civil penalty, citing failures in the bank’s cloud risk assessment and control processes.
Attack Chain
How the Attack Compounded
Each step below marks the AXIS control that failed at that point in the chain, where one applies. Steps without a control marker were outside the victim's direct span of control.
An SSRF flaw in a misconfigured WAF lets crafted requests reach the EC2 instance metadata service.
CLOUD-04
The metadata service returns temporary credentials for the WAF’s IAM role.
The role’s permissions extend far beyond the WAF’s function, listing and reading hundreds of S3 buckets.
CLOUD-01
Bulk data sync from cloud storage proceeds without anomalous-credential-use detection.
SEC-01
The breach surfaces via an external tip months later. Nobody had mapped or monitored what that role could reach.
SEC-04
Control Mapping
The IAM Controls That Failed
Every failure point below corresponds to a control in the AXIS question bank, the same 4 controls a maturity assessment would have scored before this incident.
| Control | Domain | Capability | How it failed here |
|---|---|---|---|
| CLOUD-01 Domino | Cloud | Multi-Cloud Permission Management (CIEM) | The WAF’s IAM role held standing permissions to enumerate and read data stores unrelated to its function. Finding and shrinking that kind of effective-permission sprawl is the job of cloud infrastructure entitlement management. |
| CLOUD-04 | Cloud | Infrastructure-as-Code (IaC) IAM Guardrails & Drift Control | The WAF misconfiguration that exposed the metadata service persisted in production. No infrastructure-as-code guardrails or drift detection treated identity-adjacent configuration as a first-class control surface. |
| SEC-01 Domino | Security | Identity Threat Detection & Response (ITDR) | A firewall’s role credentials suddenly listing buckets and syncing terabytes is a high-signal anomaly, yet exfiltration went undetected and the breach was reported by an outside tipster months later. |
| SEC-04 | Security | Data Security Posture & Identity-to-Data Risk Mapping (DSPM) | No identity-to-data mapping had asked what this role could actually reach and whether that was proportionate. The blast radius of a single non-human identity stayed unknown until an attacker measured it. |
The Maturity Lesson
What Would Have Changed the Outcome
The Domino Effect
CLOUD-01 (multi-cloud permission management) and SEC-01 (identity threat detection) are both domino controls, and this breach is why cloud entitlements earned that status. In cloud environments the IAM role is the perimeter. A single over-permissioned non-human identity nullified encryption, network segmentation, and everything else the bank had invested in.
The Maturity Level That Mattered
At level 2 or 3 on CLOUD-01, effective permissions are continuously analyzed and right-sized against actual usage. A WAF role reading hundreds of buckets fails that analysis on day one. At level 2 on SEC-01, anomalous credential behavior such as new API patterns, mass enumeration, and bulk reads alerts while the attacker is still working.
The enduring lesson for maturity assessment: score non-human identities with the same rigor as admins. Most organizations can name their domain admins. Very few can name the five cloud roles whose compromise would be equivalent, and this breach was executed entirely through one of them.
Related Compliance Frameworks
The controls implicated in this breach carry citations in these frameworks within the AXIS bank:
Sources
About This Analysis
This teardown is based exclusively on public disclosures, regulatory findings, and reporting cited above; it makes no claim of insider knowledge about the internal environment at Capital One. Control mappings express how the publicly documented failure points correspond to capabilities in the AXIS methodology, for educational purposes. AXIS is not affiliated with Capital One.
More From the Breach Radar
Would Your Program Have Caught This?
The 4 controls that failed here are questions in the AXIS assessment. Score your organization against them, and the rest of the bank, in about 20 minutes. No signup required to start.