Case Study 29.1: Capital One S3 Breach and the Uber Credential Exposure

From SSRF to $80 Million Fine — The Cloud Misconfiguration Heard Around the World

Background

On July 29, 2019, Capital One Financial Corporation disclosed one of the largest data breaches in financial services history. A former Amazon Web Services employee, Paige Thompson (operating under the alias "erratic"), had exploited a misconfigured web application firewall (WAF) to access the personal information of approximately 106 million Capital One customers and applicants in the United States and Canada. The breach resulted in an $80 million fine from the Office of the Comptroller of the Currency (OCC), a $190 million class-action settlement, and a fundamental rethinking of cloud security across the industry.

The breach is particularly instructive because it did not rely on a zero-day vulnerability or sophisticated malware. It exploited a chain of misconfigurations that, individually, might have seemed minor but together created a path from an unauthenticated web request to mass data exfiltration.

The Attack Chain

Step 1: Server-Side Request Forgery (SSRF). Capital One's web application firewall, a reverse proxy built on ModSecurity running on EC2, contained a misconfiguration that allowed server-side request forgery. Thompson crafted requests that caused the WAF to make HTTP requests to internal resources on the attacker's behalf.

The critical request targeted the EC2 Instance Metadata Service (IMDS) at http://169.254.169.254/. At the time, AWS only offered IMDSv1, which required no authentication — any HTTP GET request from the instance would return metadata.

Step 2: IAM Credential Theft. Through the SSRF vulnerability, Thompson queried the metadata service endpoint:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

This returned the name of the IAM role attached to the EC2 instance. A subsequent request to:

http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

returned temporary AWS credentials (access key ID, secret access key, and session token) for that role.

Step 3: Overly Permissive IAM Role. The IAM role attached to the WAF instance had permissions far beyond what the WAF needed. Critically, it had s3:GetObject and s3:ListBucket permissions on a wide range of S3 buckets — including buckets containing customer data. This violated the principle of least privilege.

Step 4: S3 Data Exfiltration. Using the stolen credentials, Thompson listed Capital One's S3 buckets and identified those containing sensitive data. She then downloaded massive amounts of customer information, including: - Names, addresses, dates of birth, and self-reported income for approximately 106 million individuals - Social Security numbers for approximately 140,000 customers - Linked bank account numbers for approximately 80,000 customers - Credit scores, credit limits, balances, and payment history

Step 5: Boasting and Discovery. Thompson posted about the breach on social media and Slack channels, which ultimately led to her identification and arrest. She was convicted on multiple counts of wire fraud and computer fraud in June 2022.

The Uber Parallel

The Capital One breach shares structural similarities with the Uber data breach disclosed in 2017 (though it occurred in 2016). In Uber's case:

Credential Exposure via GitHub. Uber engineers had committed AWS access keys to a private GitHub repository. Attackers who gained access to the repository extracted these credentials.

S3 Data Access. The exposed credentials had permissions to access S3 buckets containing rider and driver data. The attackers downloaded personal information for approximately 57 million users and 600,000 drivers.

Cover-Up Attempt. Rather than disclosing the breach, Uber's then-CSO Joe Sullivan paid the attackers $100,000 through the bug bounty program and had them sign non-disclosure agreements. Sullivan was later convicted of obstruction of justice and misprision of a felony — the first criminal conviction of a corporate security executive for covering up a data breach.

Both incidents demonstrate the same fundamental pattern: compromised credentials plus overly permissive S3 access equals massive data exposure.

Technical Analysis

Why the WAF was vulnerable to SSRF. The WAF was configured as a reverse proxy that forwarded requests to backend servers. A misconfiguration in the proxy rules allowed user-controlled input to influence the destination of internal requests. The WAF did not have adequate egress filtering to prevent connections to the metadata service endpoint.

Why IMDSv1 was exploitable. IMDSv1 uses a simple HTTP GET request with no authentication. Any process on the instance that can make HTTP requests — including web applications exploited via SSRF — can access the metadata service. This is a design limitation that AWS subsequently addressed with IMDSv2.

Why the IAM role was overly permissive. Capital One used a role that had broad S3 access because it simplified deployment — the same role was used across multiple services. This "convenience over security" approach is extremely common in cloud environments, where the pressure to ship features often overrides the discipline of least-privilege IAM design.

Why the S3 data was not additionally protected. The customer data in S3 was not tokenized or encrypted at the object level. While S3 server-side encryption was enabled, it protects against physical theft of drives, not against access by an authenticated AWS principal with s3:GetObject permission.

Lessons for Ethical Hackers

1. Always test for SSRF. In cloud environments, SSRF is not just a medium-severity finding — it is potentially critical because of its ability to access metadata services and steal IAM credentials. Test all user-controlled URL parameters, webhook configurations, and file upload features for SSRF.

2. Check IMDSv1 availability. During any cloud engagement, verify whether IMDSv1 is still enabled on EC2 instances. Its presence should be reported as a finding even without an exploitable SSRF, because it represents unnecessary risk.

3. Map IAM trust relationships. Do not assume that IAM roles follow least privilege. Enumerate all policies attached to roles used by compute resources and verify that their permissions match the resource's actual requirements.

4. Test S3 access from every credential set. When you obtain AWS credentials during testing, always enumerate and test S3 bucket access. Even "read-only" access to the wrong bucket can constitute a critical finding.

5. Look for credentials in code repositories. Search GitHub, GitLab, Bitbucket, and internal repositories for AWS access keys, Azure service principal credentials, and GCP service account keys. Tools like trufflehog, git-secrets, and gitleaks automate this search.

Remediation and Industry Impact

Capital One's breach catalyzed several industry-wide changes:

AWS IMDSv2. Amazon introduced IMDSv2, which requires a PUT request to obtain a session token before accessing metadata. This token-based approach effectively mitigates SSRF-based credential theft because SSRF typically only allows GET requests. AWS eventually added the ability to require IMDSv2 and disable IMDSv1 at the instance and account level.

AWS VPC Endpoints for S3. Organizations increased adoption of VPC endpoints to ensure S3 traffic never traverses the public internet, reducing the attack surface.

Cloud Security Posture Management. The breach accelerated enterprise adoption of CSPM tools that continuously monitor for IAM misconfigurations, public S3 buckets, and other cloud security issues.

Regulatory Action. The OCC's $80 million fine signaled that regulators view cloud misconfigurations as seriously as they do traditional security failures. This fine was levied not because Capital One used cloud services, but because their cloud security controls were inadequate.

Discussion Questions

1. The Capital One WAF was a custom-built component rather than a managed AWS service (AWS WAF). How would using a managed service have changed the attack surface? What trade-offs exist between custom and managed cloud security components?

2. Thompson was a former AWS employee. Should cloud providers implement additional controls for former employees? How does insider knowledge change the threat model for cloud security?

3. Compare the Capital One and Uber incidents. Both involved compromised credentials and S3 data access, but the organizations responded very differently. How do breach response decisions affect the ultimate impact of a security incident?

4. Capital One received an $80 million fine despite using AWS — a platform that offers extensive security features. What does this tell us about the shared responsibility model in practice versus in theory?

5. If you were the penetration testing firm hired to assess Capital One's AWS environment before the breach, what specific tests would have identified the vulnerabilities that Thompson exploited? Design a testing checklist.

Timeline

References

• Department of Justice. "Seattle Tech Worker Arrested for Data Theft Involving Large Financial Services Company." Press Release, July 29, 2019.
• Office of the Comptroller of the Currency. "OCC Assesses $80 Million Civil Money Penalty Against Capital One." Enforcement Action 2020-049.
• Krebs, Brian. "Capital One Data Theft Impacts 106M People." KrebsOnSecurity, July 30, 2019.
• AWS. "Instance Metadata Service Version 2 (IMDSv2)." AWS Documentation.
• Gruss, Leif. "Capital One Cloud Breach: Lessons Learned." SANS Institute, 2020.
• United States v. Paige A. Thompson. Western District of Washington, Case No. CR19-159.