Slide 11 of 28
Part 2 · How It WorksSlide 11
Slide 11 · Real Incident
Capital One — how Pattern 1 played out at scale.
July 2019. $270M in total costs. The WAF that became a proxy.
📄 U.S. DOJ · OCC · Court records · 2019–2022
TIMELINE
Capital One Breach — March to July 2019

March 22–23, 2019: Paige Thompson executes the SSRF attack. She exploits a misconfigured WAF (ModSecurity running on an EC2 instance). The WAF is configured to forward certain requests to backend services — Thompson finds it will also make outbound requests to arbitrary URLs, including the metadata endpoint.

The specific vulnerability: The WAF had a misconfigured rule that allowed a specific HTTP header to cause the WAF to make a proxied request to an attacker-specified destination. The destination could be the metadata endpoint.

What she accessed: Over 100 S3 buckets containing Capital One customer data — 100 million US and Canadian customers’ credit card applications. Data included: names, addresses, zip codes, phone numbers, email addresses, dates of birth, reported income, credit scores, credit limits, payment history, contact history, SSNs (140,000), linked bank account numbers (80,000).

Discovery: On July 17, 2019, an anonymous tipster emailed Capital One about GitHub repositories posted by “erratic” (Thompson’s online alias) that appeared to contain stolen Capital One data. Capital One alerted the FBI on July 19. Thompson was arrested on July 29, 2019. The gap between the breach (March) and discovery (July) — nearly four months — illustrates how difficult SSRF attacks are to detect without proper logging of outbound server requests.
The lesson beyond SSRF

The SSRF was the entry point. The blast radius was determined by IAM role over-permissioning — the EC2 role had access to over 100 S3 buckets it didn’t need. Least-privilege IAM would have limited the damage even if the SSRF was exploited.

← Back Pattern 2: Internal pivot →