Learn how a former cloud engineer exploited misconfigurations to breach one of America’s largest banks.
• A former cloud engineer used insider knowledge to exploit cloud misconfigurations and steal credentials from AWS metadata services
• Over-permissioned IAM roles turned a single compromised component into access to hundreds of sensitive data buckets
• Regulators issued the first major penalty for cloud security failures, setting precedent for future enforcement
• Proper SSRF hardening, least privilege IAM policies, or IMDSv2 would have stopped the attack at multiple points
A former Amazon Web Services engineer knew exactly where to look. Paige Thompson built a tool to scan AWS for misconfigured accounts. When she found Capital One’s vulnerable web application firewall, she used a technique called server-side request forgery to steal credentials and access over 700 data storage buckets.
The breach exposed fundamental failures in cloud security. Capital One had migrated to AWS without a proper risk assessment. Internal auditors missed obvious issues. An IAM role attached to the firewall had access to sensitive data it never should have had access to.
Internal employees had warned about the WAF vulnerability before the attack. Those warnings went unaddressed.
This case study examines the technical attack chain, regulatory response, and practical lessons for security teams managing cloud infrastructure.
The Capital One data breach exposed personal information from 106 million credit card applicants. A former Amazon Web Services engineer exploited cloud misconfigurations to steal data from over 700 storage buckets containing credit applications and financial records.
Server-Side Request Forgery (SSRF) is an attack technique where an attacker tricks a server into making unauthorized requests on their behalf. In cloud environments, SSRF can be used to access internal services like the AWS metadata service, which provides temporary credentials to compute instances. These stolen credentials can then be used to access other cloud resources.
The attack occurred between March and July 2019. The Capital One hacker, Paige Thompson, operated under the handle “erratic” and built a custom scanning tool to find vulnerable AWS accounts. She used server-side request forgery against Capital One’s WAF to steal credentials and access customer data.
Capital One discovered they had been hacked on July 19, 2019, after a GitHub user noticed suspicious data and alerted the company through their responsible disclosure program. Thompson had posted stolen data on GitHub and bragged about the Capital One hack in Slack channels and social media.
The FBI arrested Thompson in July 2019. In June 2022, a jury found her guilty of wire fraud and five counts of unauthorized access to protected computers. The investigation revealed she had also targeted over 30 other organizations using similar techniques.
The attack exploited a chain of cloud misconfigurations. Unrestricted outbound access enabled credential theft, and an over-permissioned IAM role turned those credentials into access to customer data.
Capital One’s web application firewall ran on an EC2 instance that could make outbound requests to internal AWS services. Thompson sent specially crafted requests that made the server query AWS’s metadata service - a request it should never have been able to make.
The attack surface exposed by this misconfigured component gave Thompson the entry point she needed.
The AWS metadata service provides information about running instances, including temporary security credentials. Thompson exploited the SSRF vulnerability to query AWS’s metadata service, which returned temporary credentials.
Her queries returned the IAM role attached to the EC2 instance along with temporary access credentials. The role, named “ISRM-WAF-Role,” provided access to AWS services including S3 storage buckets.
Capital One used IMDSv1, the original metadata service version, which responded to simple HTTP requests without authentication. AWS later released IMDSv2 specifically to address this attack pattern. IMDSv2 requires session tokens, making SSRF exploitation significantly harder.
With valid credentials for the ISRM-WAF-Role, Thompson could make authenticated API calls to AWS services. She used the AWS command-line interface to list S3 buckets and access their contents.
The IAM role had permissions to list and read data from over 700 S3 buckets. These buckets contained credit card applications, personal information, and financial records dating back to 2005.
Thompson exfiltrated approximately 30 GB of customer data over several months. The data included names, addresses, dates of birth, credit scores, credit limits, balances, and payment history. More critically, the stolen records included roughly 140,000 Social Security numbers and 80,000 linked bank account numbers.
Multiple controls failed here. Any single one working would have stopped the attack.
IAM (Identity and Access Management) roles in cloud environments define what permissions cloud resources have. An IAM role attached to an EC2 instance determines what AWS services that instance can access. The principle of least privilege requires roles to have only the minimum permissions necessary for their function.
The WAF ran on an EC2 instance with unrestricted outbound network access. This let Thompson make requests to internal AWS services, including the metadata endpoint. Restricting outbound traffic or blocking access to the metadata service would have stopped the attack.
The ISRM-WAF-Role had permissions to access S3 buckets containing sensitive customer data. A WAF only needs to inspect and filter traffic - it has no reason to read from data storage. Someone granted the role far more permissions than the firewall actually needed.
When Thompson stole credentials for this role, she inherited all its permissions. If the role had been properly scoped with minimal permissions, the stolen credentials would have been worthless for accessing customer data.
Organizations commonly over-permission IAM roles to avoid troubleshooting access issues. Some developers use policies that grant administrative access to everything. This convenience creates exactly the scenario Thompson exploited.
Thompson accessed Capital One’s AWS environment for four months before being discovered. The company’s intrusion detection systems failed to identify unusual API calls, data access patterns, or bulk data transfers.
Effective data breach monitoring requires visibility into cloud API activity. Unusual patterns like listing hundreds of S3 buckets or downloading large volumes of data should trigger alerts.
Capital One only discovered the breach when an external researcher noticed Thompson’s GitHub post and reported it through responsible disclosure. Without that tip, the attack might have continued indefinitely.
The Capital One breach drew significant regulatory attention and established precedent for cloud security enforcement. Financial penalties exceeded $270 million across multiple settlements.
In August 2020, the Office of the Comptroller of the Currency assessed an $80 million civil money penalty against Capital One. This was the first significant OCC penalty for a cloud-related data breach.
The OCC found that Capital One had “failed to establish effective risk assessment processes prior to migrating significant information technology operations to the public cloud environment.” The company also failed to fix identified deficiencies in a timely manner.
The regulator noted that Capital One’s internal audit unit had failed to identify numerous weaknesses in the cloud environment. When auditors did raise concerns, the board failed to take effective action.
Beyond the monetary penalty, Capital One had to establish a compliance committee and submit written plans for improving risk management. The OCC consent order remained in effect until September 2022.
The Federal Reserve entered into a cease and desist order with Capital One’s parent holding company. While this action didn’t include a monetary penalty, it required the board to submit detailed plans for improving risk management and internal controls.
The Fed terminated its enforcement action in July 2023, determining Capital One had achieved a level of safety and soundness that no longer required extra oversight.
The Capital One data breach lawsuit consolidated claims from millions of affected customers. In December 2021, Capital One agreed to pay $190 million to settle. The settlement fund compensated individuals whose personal information was exposed in the breach.
Paige Thompson faced federal charges for wire fraud and unauthorized access to protected computers. In June 2022, a Seattle jury found her guilty on all counts. The crimes carried potential sentences of up to 20 years.
In October 2022, the judge sentenced Thompson to time served plus five years of probation with location and computer monitoring. Prosecutors had requested seven years in prison. In March 2025, an appeals court ruled the sentence was too lenient and sent the case back for resentencing.
The Capital One breach provides important lessons for any organization operating in cloud environments. As one of the largest bank data breaches in history, it showed how failures in cloud security can have massive consequences.
Cloud security requires different thinking than traditional network security. The Capital One breach exploited cloud-specific components that don’t exist in on-premises environments.
Start with a proper risk assessment before migrating to the cloud. The OCC found Capital One had skipped this step. This directly led to the security gaps Thompson exploited. Understand what cloud services you’re using and how they interact.
Harden all internet-facing components against SSRF. Web application firewalls, reverse proxies, and any service that makes outbound requests can potentially be exploited to access internal services. Validate and restrict outbound request destinations.
Use IMDSv2 for AWS environments. The session-based metadata service significantly reduces SSRF risk compared to IMDSv1. AWS released this service specifically in response to attacks like the Capital One breach.
The excessive permissions on the ISRM-WAF-Role turned a WAF compromise into a massive data breach. If the role only had permissions necessary for firewall operations, Thompson couldn’t have accessed S3 buckets.
Review IAM roles regularly. Remove permissions that aren’t actively needed. Avoid policies that grant broad access just to make things work. The temporary convenience creates permanent risk.
Monitor for third-party cyber risk in cloud environments. Vendors and partners accessing your cloud resources need the same least privilege treatment as internal services.
Capital One’s monitoring gaps let the attack continue until an external tip exposed it. Proper monitoring would have identified the activity much sooner.
Monitor CloudTrail logs for unusual API activity. Listing hundreds of S3 buckets or accessing buckets that specific roles don’t normally touch should generate alerts. Track data transfer volumes and flag unusual patterns.
Implement runtime detection for cloud workloads. Watch for unexpected network connections, credential usage patterns, and data access behaviors. The attack chain involved multiple detectable activities.
Dark web monitoring can also provide early warning. Thompson bragged about the attack on Slack and posted stolen data publicly. Monitoring hacker forums and social platforms for mentions of your organization provides another detection layer.
The OCC specifically cited Capital One’s board for failing to act on concerns that the internal audit raised. Boards don’t need to understand SSRF or IAM policies, but they should ensure management has proper security governance in place before approving major cloud migrations.
Require regular reporting on cloud security posture. Track metrics like IAM policy complexity, public-facing assets, and detection coverage. Hold management accountable for addressing identified gaps.
Every control failure in this breach was preventable. The attack didn’t require advanced techniques. It succeeded because basic cloud security practices weren’t followed.
Key lessons for security teams:
Capital One paid over $270 million in fines and settlements. Don’t skip risk assessments or ignore internal warnings.
For more case studies on major breaches and their lessons, see our data breach examples.
Check if your organization’s credentials have been exposed with a dark web scan.
Thompson built a custom scanning tool to find AWS accounts with exposed services. Her previous employment at AWS gave her deep knowledge of common cloud security mistakes. She found Capital One’s WAF running on an EC2 instance with unrestricted outbound access and exploited it using server-side request forgery.
Server-Side Request Forgery (SSRF) tricks a server into making requests on behalf of an attacker. Thompson used SSRF against Capital One’s firewall to query the AWS metadata service, which returned temporary credentials. Those credentials let her access 700+ S3 buckets containing customer data.
The IAM role attached to the WAF’s EC2 instance (ISRM-WAF-Role) had permissions to read S3 buckets. A WAF only needs to filter traffic - it has no reason to access data storage. If the role had minimal permissions, the stolen credentials would have been useless for accessing customer data.
Multiple controls could have stopped the attack. Hardening the WAF against SSRF would have blocked initial access. Using IMDSv2 (released after this breach) would have prevented credential theft. Applying least privilege to the IAM role would have denied S3 access. Continuous dark web monitoring would have detected Thompson’s public posts about the attack sooner.
The OCC issued its first significant penalty for a cloud-related data breach. AWS responded by releasing IMDSv2, which requires session tokens for metadata service requests and reduces SSRF risk. The breach established precedent for regulatory scrutiny of cloud security practices.
Yes, Capital One was hacked in 2019 in one of the largest bank data breaches in U.S. history. A former AWS engineer named Paige Thompson exploited cloud misconfigurations to steal 106 million credit applications. Capital One paid $80 million in regulatory fines and $190 million in class action settlements.
Authentication Dark Web Monitoring Credential Monitoring Security Tools
Top 10 Account Takeover Solutions at a Glance Platform Category Best For Breachsense Credential Intelligence Dark web …
Dark Web Monitoring Compromised Credentials DarkOwl Threat Intelligence Credential Monitoring
What Does DarkOwl Do? DarkOwl is a darknet data platform. They collect content from across the dark web and make it …