One Misconfigured Firewall Rule, 100 Million Records
A former Amazon cloud engineer broke into Capital One using a scanning tool she wrote herself to find misconfigured AWS accounts, discussed it under a pseudonym in a private Slack channel, and posted evidence of it to a GitHub account that, unlike the Slack handle, carried her real name and résumé (a platform built for sharing your work, which she did, a little too literally) where anyone could find it. She was arrested less than two weeks after someone actually looked. The hack itself took real skill. Getting caught took almost none.
What actually happened
Paige Thompson, a former Amazon Web Services engineer, exploited a misconfigured web application firewall (WAF) on a Capital One server hosted on AWS. The misconfiguration let her send a crafted request that abused a server-side request forgery (SSRF) flaw, tricking the server into revealing temporary security credentials from AWS’s internal instance metadata service. Those credentials belonged to a role named “WAF-Role,” meant only for the firewall’s own use (and apparently trusting enough to hand the keys to whoever asked politely), but broad enough to let her list and download the contents of more than 700 of Capital One’s cloud storage buckets.
Inside those buckets sat information on roughly 100 million people in the United States and 6 million in Canada: names, addresses, credit scores, credit limits, and self-reported income from card applications going back to 2005, plus about 140,000 U.S. Social Security numbers, roughly 80,000 linked bank account numbers, and around 1 million Canadian Social Insurance numbers. Capital One says credit card numbers and login credentials were not exposed, and that over 99 percent of Social Security numbers were untouched. Thompson downloaded the data over two days, March 22 and 23, 2019. She then discussed the breach under the handle “erratic” in a private Slack channel called “Netcrave Communications,” and posted some of the stolen data to her GitHub account, the one that carried her real name. (Posting your own crime log to a platform built for other people to browse it, under the one account with your name on it, is not most people’s idea of operational security.) A different GitHub user, not anyone from her Slack circle, spotted the post on July 17, 2019, and flagged it to Capital One. The company’s internal investigation confirmed the breach and referred it to the FBI within two days. Thompson was arrested on July 29, 2019.
How the case ended
A jury convicted Thompson on June 17, 2022, of one felony count of wire fraud and six counts of unauthorized computer access and damage (four felonies, two misdemeanors). She was acquitted of the separate identity-theft and access-device-fraud counts prosecutors had also brought. On October 3, 2022, the trial judge sentenced her to time served plus five years of probation, rejecting the government’s request for a multi-year prison term. Prosecutors called the sentence unjust and appealed it.
In March 2025, a divided Ninth Circuit panel agreed with prosecutors, ruling 2-1 that the probation-only sentence was “substantially unreasonable” and sending the case back for resentencing. The appeal concerned the sentence, not the underlying convictions, which were left standing. On remand, the same trial judge reimposed essentially the same outcome in late 2025: time served, five years of supervised release with an initial period of home confinement, community service, and a multimillion-dollar restitution order. The case is now closed absent a further appeal.
The artifact: not the stolen data, the request that got the credentials
The breach did not start with a stolen password or a phishing email. It started with one HTTP request, sent to a firewall rule that should have blocked it and didn’t. That single misconfigured rule, not the 100 million records and not the Slack post, is the software artifact the entire case turns on: the gap between what the firewall was supposed to reject and what it let through.
That distinction matters for how a case like this gets proven or defended. A firewall rule is code, and code has a specific, inspectable configuration at a specific point in time. Did the rule exist as written, or was it a default that nobody customized? Was there a prior version that did block the request pattern, and if so, when and why did it change? Who had permission to modify it, and does an access log show who did? Pointing at the size of the breach doesn’t answer any of that. Pulling the configuration history of one resource does.
What a software expert witness reconstructs here
This is exactly the kind of case where a software expert witness does work a summary of the breach cannot: reconstruct the technical chain from the firewall’s misconfiguration, through the credential exposure, to the specific API calls that listed and downloaded bucket contents. Cloud platforms log almost everything (an elephant’s memory with none of the discretion), which sounds like an advantage until you realize the volume itself is the problem: a real incident produces millions of log lines, and the ten that matter look identical to the routine ones unless someone with the right method goes looking.
That method starts with establishing exactly which requests the misconfigured rule should have blocked under its documented intent, and timestamping when the vulnerable configuration was introduced and by whom. From there it means tracing the credential-issuance and data-access logs to show precisely what was read, copied, or merely listed, since those are legally different things even when a lay summary treats them as the same. A person who lists a folder’s contents did not necessarily read every file in it, and the distinction can matter enormously to both liability and damages.
Why the actor’s own bragging was almost beside the point
It is tempting to read this case as a story about a hacker who could not resist bragging, and that framing is not wrong. But it is worth separating two different questions the case data can answer: what proves someone committed an intrusion, and what proves the scope and technical mechanism of it. The Slack messages and GitHub post plausibly do the first job, but they do almost nothing for the second. Proving what a misconfigured cloud rule exposed, and to whom, requires the infrastructure’s own logs and configuration history, not a chat transcript, no matter how incriminating that transcript reads.
For Israeli companies running production workloads on AWS, Azure, or GCP, and for the lawyers who end up representing them after an incident, the lesson goes beyond firewalls: a cloud misconfiguration is a piece of code with a version history, and that history, not a public confession, is what proves what happened.
The above is general information and not legal advice. The case facts are drawn from the DOJ’s charging and sentencing announcements, Capital One’s own breach disclosure, court filings, and contemporaneous reporting, as listed in the accompanying source ledger.