INFRA-CAPITALONE-2019
Cloud · AWS · AWS EC2 / S3 (misconfigured WAF and IAM role)
Summary
In 2019, a former Amazon engineer stole the personal data of about 100 million Americans from Capital One, and she did it through a chain of cloud-security mistakes that has since become a teaching classic. A misconfigured web application firewall could be tricked into making requests on the attacker's behalf, a flaw called server-side request forgery. She pointed it at a special internal address that every AWS server can reach, the one that hands out the server's temporary cloud credentials, grabbed those credentials, and because they were far more powerful than they needed to be, used them to download Capital One's data straight out of its storage. It is the textbook SSRF-to-cloud-takeover chain, and the reason AWS hardened that metadata service afterward.
How it happened
The attack was a clean four-link chain. First, a misconfigured ModSecurity web application firewall running on an AWS EC2 instance was vulnerable to server-side request forgery (SSRF): it could be tricked into making a web request to a URL of the attacker's choosing. Second, the attacker pointed that request at the EC2 Instance Metadata Service at 169.254.169.254, a special link-local address every EC2 instance can query to retrieve the temporary credentials of its attached IAM role. Third, the SSRF returned those credentials. Fourth, the firewall's IAM role was badly over-privileged, with broad access to Capital One's S3 storage, so the stolen credentials let the attacker list and download the data and exfiltrate it. The intrusion happened over 22-23 March 2019. Paige Thompson, a former AWS engineer who knew this pattern well, was arrested on 29 July 2019, and the breach was not caught by Capital One's defences at all: Thompson had posted the stolen data to a public GitHub gist under her own name, and an outside researcher tipped off the bank.
The damage
Roughly 100 million people in the US and 6 million in Canada were exposed, mostly credit-card application data (names, addresses, credit scores), including about 140,000 US Social Security numbers, 80,000 linked bank-account numbers, and around 1 million Canadian Social Insurance Numbers. Capital One paid an $80 million regulatory fine (the OCC's, for failing to manage the risk of its cloud migration) and a $190 million class-action settlement. Prosecutors established that Thompson had used the same SSRF technique against more than 30 organisations, planting cryptomining software on the servers she breached; a jury convicted her of wire fraud and computer-fraud charges in June 2022 (acquitting her of identity theft), and she was sentenced to time served and probation. The breach directly motivated AWS to release IMDSv2 in November 2019, a hardened version of the metadata service that requires a session token and limits network hops, designed to break exactly this SSRF-reads-credentials pattern.
Why Capital One still matters
It is the canonical cloud SSRF chain, and a least-privilege lesson. Every link was independently breakable: the SSRF (validate and block outbound requests to the metadata address), the metadata service (IMDSv2 requires a token an SSRF cannot easily obtain), and the over-privileged role (least privilege would have sharply limited the damage even after the credentials were stolen). The defences: enforce IMDSv2 with a hop limit of one, scope EC2 instance roles to least privilege and never grant broad S3 access, block SSRF at the application and egress layers, enable S3 Block Public Access with encryption and alerting on large reads, and watch for instance credentials being used from outside the instance, the dead giveaway. It shares the cloud-credential-theft theme with the provider-side ChaosDB flaw.
How to fix it
- Enforce IMDSv2 and revoke and rotate the exposed instance-role credentials immediately; assume anything the role could read was taken.
- Tighten the firewall and app to block SSRF and deny access to the metadata endpoint, and scope the IAM role to least privilege.
- Review CloudTrail for the stolen credentials' use and quantify exactly what was exfiltrated.
How to avoid it
- Enforce IMDSv2 (require session tokens, set the hop limit to 1) so an SSRF cannot read instance role credentials.
- Scope EC2 instance IAM roles to least privilege; never grant broad S3 list/get across all buckets.
- Block SSRF at the app and egress layers: validate and allowlist outbound URLs and deny access to 169.254.169.254.
- Enable S3 Block Public Access and encrypt sensitive data; alert on large or unusual S3 reads.
- Monitor CloudTrail and GuardDuty for instance credentials used from outside the instance or for anomalous API calls.
References
- https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/
- https://www.capitalone.com/digital/facts2019/
- https://www.occ.gov/news-issuances/news-releases/2020/nr-occ-2020-101.html
- https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker-arrested-data-theft-involving-large-financial-services-company
Related vulnerabilities
All Infra →- HIGHCVE-2024-21626
Leaky Vessels was a set of container-escape vulnerabilities disclosed on 31 January 2024 by Rory McNamara of Snyk Security Labs, the headline flaw being CVE-2024-21626 (CVSS 8.6, runc 1.1.11 and earlier). It was an order-of-operations file-descriptor leak in runc's handling of the process working directory (WORKDIR / process.cwd). During container setup runc left an internal file descriptor referencing the host filesystem namespace open before all privileged descriptors were closed, so a malicious image or a build using a malicious Dockerfile or upstream FROM could set the working directory to that leaked descriptor via a path like /proc/self/fd/7. Because chdir occurred before the descriptor was closed, the container process gained a working directory in the host filesystem and could read and write host files, breaking container isolation and escaping to the underlying host. Related Docker BuildKit issues were disclosed alongside it: CVE-2024-23651 (mount cache race), CVE-2024-23652 (build-time arbitrary delete), and CVE-2024-23653 (GRPC SecurityMode privilege check bypass). The flaw was fixed in runc 1.1.12.
- HIGHCLOUD-CLOUDSQL-PRIVESC-2023
On 24 May 2023 Dig Security disclosed a privilege-escalation chain in Google Cloud SQL for SQL Server, originally reported to Google in February 2023, that let an attacker escalate from a limited database role to full system administrator and reach the host operating system. The chain first abused a gap in GCP's security hardening to add the attacker's user to DbRootRole, an elevated GCP admin role that nonetheless lacked full SQL Server permissions, then exploited a further misconfiguration in the role permission architecture to grant the SQL Server sysadmin role and obtain complete control of the database engine. With sysadmin rights the researchers reached the underlying container and host OS, letting them list privileged paths, read sensitive files and extract secrets, including internal GCP data and credentials related to the managed service. This was a provider-side flaw under shared responsibility that customers could not patch; Google remediated it in April 2023 and it was found and reported by researchers with no evidence of exploitation in the wild.
- MEDIUMCLOUD-TOYOTA-2023
On May 12, 2023, Toyota disclosed that a cloud environment managed by its Toyota Connected subsidiary had exposed data on roughly 2.15 million customers, essentially the entire Japanese user base of its T-Connect, G-Link, G-Link Lite, and G-BOOK connected services registered since November 2013. The data was exposed from November 6, 2013 to April 17, 2023, nearly a decade, and included in-vehicle GPS terminal IDs, vehicle chassis numbers, location history with timestamps, and a subset of drive-recorder video footage, but not names, credit cards, or other directly identifying personal data. The root cause was a cloud database misconfigured to be publicly accessible instead of private, attributed to human error during setup and allowing unauthenticated internet access. Toyota cited a lack of active detection mechanisms and insufficient enforcement of data-handling rules, which is why the misconfiguration persisted undetected for years. A follow-up disclosure on May 31, 2023 found additional misconfigured cloud services exposing around 260,000 more customers.
- HIGHCLOUD-BLUEBLEED-2022
On September 24, 2022 SOCRadar discovered a misconfigured Microsoft Azure Blob Storage endpoint that exposed roughly 2.4 TB of business data spanning 65,000+ entities across 111 countries, with files dated from 2017 to August 2022, though Microsoft disputed the entity count as exaggerated. The exposed data included customer names, email addresses, phone numbers, company names, and business transaction documents such as signed invoices, proof-of-execution and statement-of-work files, and product offers. The low-level misconfiguration was that the Blob Storage endpoint's access level was set to allow anonymous public access instead of requiring authentication, so the container and its blobs were readable over the internet without any credential. Microsoft's Security Response Center attributed it to an unintentional misconfiguration on an endpoint not in use and reconfigured it to require authentication, stating it found no indication that accounts or systems were compromised.
- CRITICALCLOUD-AZURESCAPE-2021
On 9 September 2021 Palo Alto Unit 42 researcher Yuval Avrahami disclosed Azurescape, described as the first cross-account container takeover in a public cloud, in which a malicious container on Azure Container Instances could escape and gain control over other customers' containers running on the shared multitenant Kubernetes cluster. ACI ran an outdated container runtime, runC v1.0.0-rc2, which was vulnerable to CVE-2019-5736, letting the attacker break out of the container and execute code as root on the underlying Kubernetes node. From the node the researcher found the bridge pod, which serviced az container exec calls, sent a Kubernetes service-account token in the Authorization header to a Kubelet that also allowed anonymous access; decoding that token (related to CVE-2018-1002102) granted pods/exec rights across all namespaces and control of the api-server, and thus the whole multitenant cluster. This was a provider-side flaw under shared responsibility that customers could not patch; Unit 42 found it and reported it with no knowledge of exploitation in the wild.
- HIGHCLOUD-POWERAPPS-2021
On August 23, 2021, UpGuard disclosed that misconfigured Microsoft Power Apps portals exposed roughly 38 million records across 47 organizations, including American Airlines, Ford, J.B. Hunt, the Maryland Department of Health, the State of Indiana, New York City agencies, and Microsoft itself. Exposed data included names, email addresses, phone numbers, social security numbers, and COVID-19 contact tracing and vaccination appointment information. Power Apps portals surface list data through OData list feeds reachable at predictable URLs, and access to those feeds is gated by Table Permissions, but Table Permissions were disabled by default on every list. Because security was opt-in, any portal where a developer enabled an OData feed without explicitly configuring and enabling Table Permissions returned its records to any unauthenticated visitor querying the OData endpoint. This is an insecure-default access-control misconfiguration where the platform defaulted to anonymous read rather than deny.