Capital One: A Misconfigured WAF and a Former AWS Employee
A former AWS software engineer exploited a misconfigured Web Application Firewall to obtain credentials from Capital One's EC2 metadata service, then downloaded over 100 million credit applications from S3.
Background
Capital One had migrated significant workloads to AWS and used a WAF (Web Application Firewall) to protect its applications. The WAF was misconfigured in a way that allowed it to be used as a proxy to the EC2 Instance Metadata Service (IMDS).
The Attack
Paige Thompson, a former AWS systems engineer, identified the misconfigured WAF through her knowledge of AWS architecture. She sent a request through the WAF that it forwarded to the IMDS endpoint, which returned temporary IAM credentials for the WAF's attached role. Thompson used those credentials to list and download S3 buckets containing Capital One's data — over 100 million credit card applications from the US and Canada, including Social Security numbers, bank account numbers, and credit scores. She posted details about the hack in a Slack server and on GitHub, leading to her identification.
Response
Capital One was notified by a tipster who saw Thompson's posts. The company identified the breach within days and worked with the FBI. Thompson was arrested within weeks. Capital One paid an $80 million OCC fine for risk management failures and $190 million to settle a class action.
Outcome
The breach exposed 100 million credit applications. It was notable as the first major cloud infrastructure breach — demonstrating that misconfiguration, not hacking, is the primary cloud security risk. AWS subsequently deprecated IMDSv1 and introduced IMDSv2 with session-oriented authentication.
Key Takeaways
- SSRF (Server-Side Request Forgery) against cloud metadata endpoints is a critical vulnerability class
- IAM roles should follow least-privilege — no single role should have read access to all S3 buckets
- Cloud infrastructure requires continuous configuration auditing — manual review is insufficient at scale
- Insider knowledge of cloud provider architecture makes ex-employees a unique threat vector
How to Prevent This
All guidesApply least-privilege IAM policies — no wildcard permissions in production
AWS IAM wildcard policies (Action: "*", Resource: "*") are the cloud equivalent of giving every employee a master key to every door. The Capital One breach was enabled by an SSRF vulnerability that allowed the attacker to query the EC2 metadata endpoint and retrieve IAM role credentials — credentials that had far broader permissions than the application needed. The GoDaddy breach used a provisioning system credential to access data across 1.2 million customer accounts. Audit every IAM role for over-broad permissions. Use AWS IAM Access Analyzer or equivalent tools to identify unused permissions. Restrict each role to exactly the S3 buckets, EC2 instances, and services it requires for its specific function.
Block public access on S3 buckets at the account level, not just the bucket level
Misconfigured S3 buckets containing sensitive data have been a consistent cloud security failure for a decade. The fix exists: AWS S3 Block Public Access can be enforced at the account level, preventing any bucket in the account from ever being made public regardless of bucket-level settings. Enable Block Public Access at the organisation level in AWS Organizations SCPs. For buckets that legitimately need public access (static website hosting), require explicit approval and documentation. Audit all existing buckets for public access using AWS Config rules. Capital One's breach involved a misconfigured WAF role that could list and access S3 buckets — public access controls would not have stopped it, but defence in depth would have.
Enable CloudTrail, VPC Flow Logs, and GuardDuty as a minimum baseline
You cannot detect or investigate a cloud breach without logging. The three minimum logging controls in AWS are: CloudTrail (API call audit log — who did what, when, from where), VPC Flow Logs (network connection records — which IPs connected to which IPs), and GuardDuty (threat detection service that analyses CloudTrail and flow logs for anomalies). These three together provide the visibility needed to detect credential misuse, unusual API calls, and lateral movement. Enable them in every account in your AWS Organization from day one. Store CloudTrail logs in a separate security account that production accounts cannot delete.