Capital One: how cloud access exposed 106 million people

On 17 July 2019 someone emailed Capital One’s responsible disclosure address, the inbox a company keeps for outsiders to report security problems. The email said the bank’s data seemed to be on GitHub, a public site for sharing code [1][4]. On 19 July the bank confirmed that an outsider had got into its systems [1].

The bank went public on 29 July 2019 [2]. The same day, FBI agents arrested Paige Thompson, a software engineer in Seattle [5][9]. In the months before, she had talked openly online, on Twitter and in a Slack group, about finding large stores of data on badly secured Amazon cloud servers [5].

Bradley’s video puts it as a bouncer on the front door. The bouncer checks everyone who walks in. This attacker never walked in. They rang the front desk, claimed to be the manager, and asked staff to read out what was in the vault.

Once the keys were out, the firewall stopped mattering. The attacker was making ordinary AWS requests with real credentials, so whatever the role could do, the attacker could do. The indictment says the role had permission to view and copy the stored data [3].

Capital One was not the only victim. The indictment says data was copied from more than 30 organisations, and that some victims’ servers were used to mine cryptocurrency, which is known as cryptojacking [3].

The usual telling of this breach is more certain than the court record. This is where each part comes from.

In June 2022 a federal jury convicted Thompson of seven crimes, including wire fraud, unauthorised access to a protected computer and damaging a protected computer. It acquitted her of access device fraud and aggravated identity theft. On 4 October 2022 US District Judge Robert S. Lasnik sentenced her to time served and five years’ probation. Prosecutors had asked for seven years in prison [9].

The regulator acted too. On 6 August 2020 the Office of the Comptroller of the Currency fined Capital One $80 million for failing to assess the risks properly before moving significant IT operations to the public cloud, and for not fixing the gaps in time [10].

Every step after the firewall was an AWS API call, so it could leave a record in CloudTrail, AWS’s log of activity in an account. The complaint says the bank’s logs showed the commands coming from IPredator VPN addresses and Tor exit nodes [4]. These are the signals that would stand out today.

GuardDuty is AWS’s managed threat detection service. It reads CloudTrail and network logs and raises findings like the ones above [11]. We don’t know which of today’s findings existed in 2019, so treat this as what you can have now, not as what Capital One missed.

Bradley gives three fixes in the video: require IMDSv2, give every role only what it needs, and build loud alarms for odd behaviour. Here is each one as real settings. Swap the example account number, Region, names and IDs for your own.

Fix 1: require IMDSv2. IMDSv2 makes a program on the server ask for a session token with a PUT request before it can read metadata, and it won’t hand a token to a request carrying an X-Forwarded-For header, which proxies and firewalls add. By default the token can only travel one network hop. Together these stop open firewalls, open proxies and most SSRF from reaching the keys [8]. Datadog’s 2025 report found IMDSv2 enforced on 49% of EC2 instances, up from 32% a year earlier [14]. So about half still allowed the old version.

Before you switch an instance over, check that nothing on it still uses IMDSv1. The MetadataNoToken metric counts IMDSv1 calls. If it stays at zero, the change is safe [15]. Then require IMDSv2 on the instance [16].

Then make IMDSv2 the default for new instances in every Region you use, and refuse any launch without it [17]. A hop limit of 2 lets containers on the instance still reach the service.

If you use AWS Organizations, a service control policy (SCP) holds the line across every account. This one joins three of AWS’s published examples: no launch without IMDSv2, no switching it back, and no use of role keys that came from IMDSv1 [18]. Where it says <every EC2 instance>, use the instance pattern from those examples, the one that ends in instance/*.

Fix 2: least privilege. Least privilege means each role gets only what its job needs. A firewall or web server might need to write its own logs to one place. It should not be able to list every bucket or read customer files. If the stolen keys could only do this, as Bradley puts it in the video, the trick would have led straight to a dead end.

Fix 3: loud alarms. Prevention can fail, so the last fix is noticing. Switch GuardDuty on in every Region you use [11]. For the buckets that hold personal data, log S3 data events. Advanced event selectors replace a trail’s existing selectors, so include management events in the same call [12].

Then alarm on volume. S3 request metrics are opt-in and billed at the standard CloudWatch rate. Once they are on, BytesDownloaded shows how much was read from the bucket each minute [13]. Set the threshold well above a normal busy day and send it to a channel someone watches.

If an alarm does fire and you think a role’s keys are out, the role’s Revoke active sessions option in the IAM console denies every token issued before that moment [20]. Then fix the cause, or the attacker can simply fetch new keys.

These checks only read settings. They change nothing, so they are safe to run in production.

Bradley ends the video on this: you might not be able to stop every mistake, but you want to know when one starts turning into a breach. Capital One’s mistake ran for almost four months before anyone told them.