All research
Cloud

The cloud mistake behind the Capital One hack

The data left Capital One’s cloud over two days in March 2019. The bank found out almost four months later, from a stranger’s email. Here is how it got out, and the alarm that would have caught it sooner.

Published
Reading time
6 min
Bradley Carpenter cupping his ear under the words “How long till anyone noticed?”, beside a drawing of files being copied from one computer to another1 min · Watch on Instagram ↗
Watch on Instagram
Also onYouTubeTikTok
The full deep diveCapital One: how cloud access exposed 106 million people

Two days to copy, four months to notice

Capital One says the data was copied on 22 and 23 March 2019. The bank learned about it on 17 July, when someone emailed its responsible disclosure address, the inbox a company keeps for outsiders to report security problems. The email said the bank’s data seemed to be sitting on GitHub, a public site for sharing code.

From the copying to the first warning
  • Copying the data2 days
  • Until the first warning117 days

Counted from 22 March 2019, the first day Capital One gives for the copying, to the email on 17 July [1].

That warning came from outside. The person behind the theft had been posting about it online, in a Slack group and on Twitter, and a file on GitHub held the commands used and a list of 700 folders. Someone saw it and told the bank.

By then the copy was huge. Capital One says it affected about 100 million people in the US and about 6 million in Canada. Most of it was credit card applications from 2005 to early 2019: names, addresses, dates of birth and incomes. It also held about 140,000 US Social Security numbers, about 80,000 linked bank account numbers and about 1 million Canadian Social Insurance Numbers [2]. The bank says no credit card numbers or log-in details were taken.

A drawing from the short: a black computer joined by a red dotted line to a red computer, with document icons beside both
From the short: files leaving the bank’s cloud for a machine the attacker ran. The indictment says it was a server at the attacker’s own home.

How it got out

The US indictment describes four steps. None of them needed a stolen password.

The steps in the indictment, in order
  • 1. Find a weak firewallThe attacker built scanners to find cloud servers whose web application firewall, the filter that sits in front of a website, was set up so that commands from outside could reach the server and run.
  • 2. Ask it for its keysCommands sent through that firewall fetched the server’s security credentials: the temporary keys AWS, Amazon’s cloud, gives a server so it can use other services.
  • 3. List the storageWith those keys, the attacker listed the bank’s storage folders, which AWS calls buckets.
  • 4. Copy it homeThen the data was copied to a server at the attacker’s home, through a VPN and Tor to hide where the requests came from.

Step 2 is the clever part. Tricking a server into fetching its own keys is called server-side request forgery, or SSRF, and we walk through it in our deep dive on SSRF credential theft. The court papers themselves only say “misconfigured web application firewalls”. The SSRF detail comes from security reporting at the time.

The bigger mistake was what those keys were allowed to do. A firewall has no reason to read customer records. This one’s keys could list and copy the bank’s data, so stealing them was enough.

Capital One wasn’t the only target. The indictment says data was copied from more than 30 organisations, and that some of their servers were used to mine cryptocurrency.

The alarm that would have caught it

Bradley’s point in the short is that you can’t stop every misconfiguration, but you can notice when one turns into a theft. The criminal complaint says the bank’s logs showed the commands coming from Tor and a VPN service. Set against a firewall’s normal day, the theft stands out in three ways.

  1. 1
    Where its keys are usedThe source address on each request
    Normal for a firewall serverThe server itself, inside AWS
    What happened hereTor exit nodes and a VPN service
  2. 2
    What its keys are asked to doThe actions its role performs
    Normal for a firewall serverWrite its own logs
    What happened hereList the buckets, then copy them
  3. 3
    How much data it readsBytes downloaded from storage
    Normal for a firewall serverSmall and steady
    What happened hereNearly 30 GB of applications

Each of those can be an alert today. GuardDuty, AWS’s own threat detection service, has a finding for the first one: keys made for one server being used from an address outside AWS. A second finding covers calls from Tor.

Check your own AWS account

  1. In the EC2 console, open each instance and look for IMDSv2. It should say Required. Optional means the older metadata service, the one this kind of trick abuses, still answers.
  2. Open the role attached to any internet-facing server and read what it allows. A web server or firewall that can list or read every storage bucket has far more than it needs.
  3. Turn on GuardDuty in every Region you use. It flags a server’s keys being used from outside AWS, and calls coming from Tor.
  4. Ask whoever runs your cloud one question: if a server started copying gigabytes out of storage tonight, who would know by morning?

The deep dive on this breach has the exact commands and policies for each of these.

What we check on a real case

When a cloud server’s keys might have been taken, these are the questions we answer first, in this order.

  1. Who used the keys, and from where

    Every call made with the role is in CloudTrail, AWS’s record of account activity. Calls from anywhere other than the server the role belongs to come first.

  2. What they listed and read

    Listing buckets is logged by default. Reading the files inside is only logged if S3 data events were switched on, so we check that early.

  3. How much left

    S3 data events and request metrics show which files were read and how many bytes went out. That shapes who has to be told.

  4. Close the door properly

    Revoke the role’s active sessions, require IMDSv2 on the server, and cut the role down to the one bucket and action it needs.

What this doesn’t prove

Written from the public reports listed under Sources, checked 13 Nov 2026.

  • The court papers never use the words SSRF or metadata service. That detail comes from reporting at the time, including a source quoted by KrebsOnSecurity. It fits everything in the indictment, but it wasn’t tested in court.
  • We don’t know what alerts Capital One had switched on. We only know the warning that started the investigation came from outside.
  • Capital One says the weakness was a configuration mistake that could happen on its own servers too, not a flaw in the cloud itself.
  • Capital One says the US government believes the data was recovered, with no evidence it was used for fraud or shared. That can’t be checked from the outside.

Sources

  1. 2019 Capital One Cyber Incident: What HappenedCapital One, read 13 Nov 2026
  2. Capital One Announces Data Security IncidentCapital One, 29 Jul 2019
  3. United States v. Paige A. Thompson, superseding indictment (CR19-0159, W.D. Wash.)US Department of Justice, 17 Jun 2021
  4. Woman Arrested in Massive Capital One Data Breach (on the criminal complaint)GovInfoSecurity, 30 Jul 2019
  5. Capital One Data Theft Impacts 106M PeopleKrebsOnSecurity, 30 Jul 2019
  6. What We Can Learn from the Capital One HackKrebsOnSecurity, Aug 2019
  7. GuardDuty IAM finding typesAWS documentation, read 13 Nov 2026

Want us to look at your machines?

If something like this has turned up at your company, or you want to know whether it could, we can help, and we’ll tell you plainly what we find.

Talk to us

More shorts

See all research