In March 2019, an attacker took data on about 106 million people from Capital One's cloud storage without ever stealing a human password. According to the criminal complaint and reporting on it, the attacker abused a misconfigured web application firewall to obtain temporary credentials for the cloud role that firewall ran as, then used that role to list and copy data from Amazon S3. Capital One's breach is the textbook case of a workload identity with far more access than its job needed, and of instance credentials that were reachable by an outsider.
Key takeaways
- Data was accessed on 22 and 23 March 2019 and reported to Capital One by an outside researcher on 17 July 2019. About 100 million people in the US and 6 million in Canada were affected.
- The attacker obtained credentials for a firewall's cloud role, reported as "ISRM-WAF-Role", and used them to list and sync S3 buckets. Security researchers widely attribute this to server-side request forgery against the cloud instance metadata service.
- The firewall role could read far more data than a firewall needs. That excess privilege, not the firewall flaw alone, is what made the breach so large.
- The regulator, the OCC, fined Capital One $80 million in 2020, and customer class actions settled for $190 million. The attacker, Paige Thompson, was convicted in June 2022.
- Lessons: scope workload roles tightly, require IMDSv2 and block metadata access from untrusted paths, and alert on unusual data access by machine identities.
At a glance
| Organisation | Capital One |
|---|---|
| When | Data accessed 22 to 23 March 2019; reported 17 July; discovered 19 July; announced 29 July 2019 |
| Attacker | Paige Thompson, convicted of wire fraud and computer intrusion offences in June 2022 |
| Entry point | A misconfigured web application firewall running in Amazon Web Services |
| Identities abused | Temporary cloud credentials for the firewall's IAM role |
| Impact | About 100 million US and 6 million Canadian individuals; about 140,000 Social Security numbers, 80,000 bank account numbers and 1 million Canadian Social Insurance Numbers |
| Category | NHI (cloud workload identity) |
What happened
On 17 July 2019, an outside security researcher used Capital One's Responsible Disclosure Program to report what the bank calls a "configuration vulnerability". The report pointed to data posted on GitHub. Capital One confirmed the intrusion on 19 July and announced it on 29 July 2019.
The data had been taken on 22 and 23 March 2019. Most of it came from credit card applications made between 2005 and early 2019: names, addresses, phone numbers, email addresses, dates of birth and self-reported income. Capital One says about 140,000 US Social Security numbers, about 80,000 linked bank account numbers of secured card customers and about 1 million Canadian Social Insurance Numbers were also exposed. It says no credit card account numbers or log-in credentials were compromised.
According to the criminal case, the attacker had built a tool to scan Amazon Web Services accounts for misconfigurations. At Capital One, a misconfigured web application firewall was used to obtain credentials for the role it ran under. KrebsOnSecurity, reporting on the complaint and the attacker's own online posts, described the role as "ISRM-WAF-Role" and the attacker using standard command-line tools to list the bank's storage buckets and sync their contents, about 30 GB of data. The Justice Department says the same person's intrusions affected more than 30 organisations, and that she also planted cryptocurrency-mining software on victims' cloud servers.
Paige Thompson was convicted in June 2022 of wire fraud, five counts of unauthorised access to a protected computer and damaging a protected computer. The Office of the Comptroller of the Currency fined Capital One $80 million in August 2020 over weaknesses in its cloud risk management, and customer lawsuits were settled for $190 million.
Timeline
| Date | Event |
|---|---|
| 22 to 23 March 2019 | Data copied from Capital One's cloud storage. |
| June 2019 | The attacker discusses the access in online posts, according to KrebsOnSecurity. |
| 17 July 2019 | Outside researcher reports the issue through the Responsible Disclosure Program. |
| 19 July 2019 | Capital One confirms the intrusion. |
| 29 July 2019 | Capital One announces the incident. |
| August 2020 | OCC imposes an $80 million civil money penalty. |
| 17 June 2022 | Paige Thompson convicted on seven federal counts. |
How it happened: the identity attack path
- A workload with a cloud identity. The web application firewall ran on cloud compute with an IAM role attached. The role's temporary credentials were available to the instance through the metadata service.
- A path to those credentials. The firewall was misconfigured in a way that let an outsider obtain the role's credentials. Security researchers widely describe this as server-side request forgery: making the firewall request its own metadata endpoint and hand back the credentials.
- A role that could read too much. The firewall role had permission to list and read many S3 buckets holding customer data. A firewall needs none of that.
- Legitimate tools, legitimate credentials. With valid role credentials, the attacker used standard cloud command-line tools to list buckets and copy their contents. To the cloud platform, it looked like the firewall's own identity reading data.
- No alert on unusual access. The bulk read in March went unnoticed until the external report in July.
Impact
- People: about 100 million in the United States and 6 million in Canada.
- Sensitive data: about 140,000 Social Security numbers, 80,000 bank account numbers and 1 million Canadian Social Insurance Numbers, plus application data going back to 2005.
- Regulatory: an $80 million OCC penalty in August 2020.
- Legal: $190 million settlement of customer class actions; criminal conviction of the attacker in 2022.
What this means for NHI governance
Capital One is the classic cloud non-human identity breach. No employee was phished and no password was cracked. The attacker became a machine identity, the firewall's role, and did whatever that role was allowed to do. Because the role was far more powerful than its function required, a flaw in one component became a breach of a large share of the bank's customer data.
Two structural lessons still apply across cloud estates. First, instance and workload credentials are only as safe as every path that can reach them. Any request forgery, file-read or command-injection flaw in a workload can turn into credential theft if the metadata service answers freely. AWS's IMDSv2 requires a session token for metadata requests, which blocks many forged requests of this kind. Second, least privilege for workload roles is a data protection control, not an administrative nicety. Most organisations still have roles that were granted broad storage or database access "for now" and never trimmed.
The same pattern appears in more recent incidents, including the 2026 OpenAI and Hugging Face breach, where AI agents pulled cloud instance credentials from the metadata endpoint, and cloud campaigns on our timeline such as 230 million AWS cloud environments compromised.
Recommendations
- Scope every workload role to its job. Review roles attached to compute, especially network appliances and front-end services, and remove any data access they do not need. Our Cloud Workload Identity Guide covers role design.
- Require IMDSv2 and limit metadata access. Enforce session-token metadata requests and a hop limit, and block metadata access from containers and processes that do not need it.
- Test internet-facing workloads for request forgery. Include SSRF and file-read checks in application and firewall configuration reviews.
- Alert on unusual data access by machine identities. A firewall role listing buckets or reading gigabytes of customer data should raise an immediate alert.
- Protect sensitive data independently of the role. Encrypt sensitive fields with keys that ordinary workload roles cannot use.
- Inventory roles and their owners. Every workload identity needs an owner and a regular review, as described in our NHI Lifecycle Management Guide.
Frequently asked questions
How was Capital One hacked in 2019?
An attacker abused a misconfigured web application firewall in Capital One's cloud environment to obtain the credentials of the cloud role it ran as, then used that role to list and copy data from storage buckets.
How many people were affected by the Capital One breach?
About 100 million people in the United States and about 6 million in Canada, according to Capital One.
Why is Capital One considered a non-human identity breach?
The attacker never used a person's account. Everything was done with temporary credentials belonging to a machine identity, the firewall's cloud role, which had far more access than it needed.
Related NHI Mgmt Group resources
AWS S3 buckets under attack · 230 million AWS cloud environments compromised · Kubernetes NHI Security Guide · Top 10 NHI Issues
How NHI Mgmt Group can help
Securing Non-Human Identities (NHIs), including AI agents, is becoming increasingly crucial as attackers target cloud roles, service accounts, API keys, tokens and secrets. Our NHI Foundation Level Training Course gives teams the practical grounding to find, govern and protect these identities.
References
- Capital One: 2019 Capital One Cyber Incident, What Happened
- US Department of Justice: Former Seattle tech worker convicted of wire fraud and computer intrusions (June 2022)
- OCC: OCC Assesses $80 Million Civil Money Penalty Against Capital One (August 2020)
- KrebsOnSecurity: Capital One Data Theft Impacts 106M People (July 2019)
- CNBC: Capital One data breach exposes tens of thousands of Social Security numbers, linked bank accounts (30 July 2019)
