Capital One Breach: How a Cloud Misconfiguration Exposed 106 Million Records

On July 29, 2019, Capital One Financial Corporation disclosed that a data breach had exposed the personal information of approximately 106 million individuals across the United States and Canada. The breach was carried out by Paige Thompson, a former Amazon Web Services (AWS) software engineer, who exploited a misconfigured web application firewall (WAF) to access Capital One's data stored on AWS. The incident became a landmark case in understanding the shared responsibility model of cloud computing and the third-party risks inherent in cloud infrastructure.

The Attack: Server-Side Request Forgery

Thompson exploited a server-side request forgery (SSRF) vulnerability in a misconfigured WAF that Capital One had deployed on its AWS infrastructure. The misconfiguration allowed the WAF to be tricked into making requests to the AWS metadata service, which returned temporary credentials associated with an IAM role. That role had overly broad permissions to access Capital One's S3 storage buckets containing customer data.

The attack occurred on March 22 and 23, 2019. Thompson used the obtained credentials to list the contents of Capital One's S3 buckets and then downloaded data from those buckets. She later posted about the breach on social media and in public Slack channels, which led to a tip from a security researcher to Capital One's responsible disclosure program on July 17, 2019.

What Was Exposed

The compromised data included credit card application information dating back to 2005. This encompassed names, addresses, phone numbers, email addresses, dates of birth, and self-reported income. For some applicants, the data also included Social Security numbers (approximately 140,000), linked bank account numbers (approximately 80,000), credit scores, credit limits, balances, and payment history. In Canada, approximately 1 million Social Insurance Numbers were compromised.

The Shared Responsibility Problem

The Capital One breach brought the cloud shared responsibility model into sharp public focus. Under this model, the cloud provider (AWS, in this case) is responsible for security "of" the cloud — the underlying infrastructure, compute, storage, and networking. The customer (Capital One) is responsible for security "in" the cloud — including how they configure their services, manage access controls, and protect their data.

The misconfigured WAF and the overly permissive IAM role were Capital One's responsibility, not AWS's. However, the incident raised questions about whether cloud providers should implement additional guardrails to prevent common misconfigurations, particularly for the metadata service endpoint that Thompson exploited. AWS subsequently released IMDSv2 (Instance Metadata Service Version 2), which provides additional protections against SSRF attacks by requiring session-oriented requests.

Legal Consequences

Paige Thompson was arrested on July 29, 2019, the same day Capital One publicly disclosed the breach. She was indicted on charges of computer fraud and abuse, wire fraud, and access device fraud. In June 2022, a federal jury in Seattle convicted Thompson on seven counts, including wire fraud and unauthorized access to a protected computer. She was sentenced in October 2022.

Capital One faced significant regulatory and legal consequences. The Office of the Comptroller of the Currency (OCC) assessed an $80 million civil money penalty against Capital One in August 2020, citing the bank's failure to establish effective risk assessment processes before migrating significant IT operations to the cloud. The OCC specifically noted deficiencies in Capital One's risk management for cloud-based operations. Capital One also agreed to a $190 million class action settlement with affected consumers.

Implications for Vendor Risk Management

The Capital One breach offers critical lessons for organizations managing vendor risk in cloud environments:

• Cloud provider is a critical vendor: AWS, Azure, and GCP should be assessed as critical third-party vendors, with specific attention to the boundaries of the shared responsibility model and how the organization's own configurations create or mitigate risk.
• Configuration management is a TPRM concern: When assessing vendors that operate in the cloud, TPRM questionnaires and assessments must go beyond asking "do you use cloud services?" to evaluating how cloud resources are configured, audited, and monitored.
• Insider threat from vendor employees: Thompson's status as a former AWS employee, while not directly relevant to the technical attack vector, highlighted the broader insider threat concern. Organizations must consider that vendor employees (current and former) may have knowledge of their systems' architecture.
• FAIR quantification for cloud risk: Using the FAIR framework, organizations can model cloud misconfiguration scenarios to quantify potential loss exposure and prioritize investment in configuration auditing, automated compliance checks, and cloud security posture management (CSPM) tools.

The Capital One incident ultimately demonstrated that migrating to the cloud does not transfer risk — it transforms it. Organizations must evolve their third-party risk management programs to account for the unique risk dynamics of cloud infrastructure, including the configurations, access controls, and monitoring practices that remain firmly within the customer's domain of responsibility.