AWS misconfiguration breaches: six incidents and what they teach
Most AWS breaches do not start with a clever exploit. They start with a setting: a bucket left public, a permission left too broad, a key left in code. This guide looks at six well-documented incidents, what the misconfiguration was, and the AWS Security Hub control that flags the same problem today. Every fact links to the company’s own statement, a regulator or the researcher who found it.
Six incidents
-
Capital One, 2019: a misconfigured firewall and an over-permissive role
What happened: An outsider accessed customer data in March 2019. Capital One says about 100 million people in the US and about 6 million in Canada were affected, mostly through credit card applications, including about 140,000 US Social Security numbers.
The misconfiguration: The US Department of Justice says the intrusion occurred through a misconfigured web application firewall, and Capital One describes a configuration vulnerability. Published analyses of the case describe the firewall being used to obtain temporary credentials for its IAM role, which had enough access to list and download data from S3.
The consequence: The Office of the Comptroller of the Currency imposed an $80 million civil money penalty in August 2020, citing weak risk assessment before the bank moved IT operations to the public cloud.
What would flag it today:
EC2.8EC2 instances should use Instance Metadata Service Version 2 (IMDSv2), which AWS released after this breach, andIAM.21IAM customer managed policies should not allow wildcard actions for services. -
Uber, 2016: an AWS key in a code repository
What happened: According to the US Federal Trade Commission’s revised complaint, intruders downloaded files from Uber’s Amazon S3 datastore in late 2016, including about 25.6 million names and email addresses and 607,000 names and driver’s licence numbers, held in unencrypted database backups.
The misconfiguration: An AWS access key sat in plain text in code in a private GitHub repository, which engineers reached through personal accounts without multi-factor authentication.
The consequence: Uber agreed to an expanded FTC order in 2018, partly because it did not disclose the breach for about a year.
What would flag it today: No posture check can see a key leaked into a repository.
IAM.3IAM users’ access keys should be rotated every 90 days or less only checks how old each key is: it cannot tell whether a key has leaked, and a leaked key works until someone deactivates it, so regular rotation just shortens that window. Replacing long-lived keys with IAM roles removes keys that can sit in code for years, although the temporary credentials roles issue still need protecting. -
Twilio, 2020: a bucket anyone could write to
What happened: Twilio’s incident report says a party modified a copy of its TaskRouter JavaScript SDK in July 2020, so that browsers loading it fetched a URL associated with card-skimming attacks. Twilio replaced the file about nine hours later and found no evidence that customer data was accessed.
The misconfiguration: The S3 bucket policy for that path allowed anyone on the internet to read and write. The write permission had been added years earlier while troubleshooting a build system, and never removed.
What would flag it today:
S3.3S3 general purpose buckets should block public write access, andS3.8S3 general purpose buckets should block public access. -
Deep Root Analytics, 2017: voter records in a public bucket
What happened: Researchers at UpGuard found an S3 bucket belonging to a data analytics firm that held information on more than 198 million US voters, about 1.1 TB of which could be downloaded without logging in. It was secured two days after discovery.
The misconfiguration: The bucket was publicly readable with no authentication.
What would flag it today:
S3.2S3 general purpose buckets should block public read access,S3.8for the bucket andS3.1for account-wide Block Public Access. -
Verizon and NICE Systems, 2017: a supplier’s public bucket
What happened: UpGuard found a public S3 bucket run by NICE Systems, a Verizon supplier, holding customer names, addresses, account details and PINs. UpGuard estimated up to 14 million customers; Verizon put the figure at 6 million.
The misconfiguration: The bucket was configured to allow public access. The data belonged to Verizon’s customers, but the bucket belonged to a supplier.
What would flag it today:
S3.2,S3.8andS3.1, in the supplier’s account. Your own checks only protect accounts you control, so ask suppliers how they check theirs. -
Accenture, 2017: keys and passwords in public buckets
What happened: UpGuard found four publicly downloadable S3 buckets containing a plaintext access key for an AWS Key Management Service account, VPN keys, private keys and a backup holding nearly 40,000 plaintext passwords. Accenture secured them the next day.
The misconfiguration: Public buckets, made far worse by storing secrets in them in plain text.
What would flag it today:
S3.2,S3.8andS3.1. Storing secrets in AWS Secrets Manager rather than in files would have limited the damage even with a public bucket.
The patterns behind them
- Public storage is the most common cause. Four of the six involve S3 buckets that anyone could read or write. Block Public Access, which AWS has turned on by default for new buckets since April 2023, stops most of these, as long as nobody turns it off.
- Permissions were broader than the job needed. A web firewall did not need to read every bucket, and a build process did not need public write access.
- Temporary changes became permanent. Twilio’s write permission was added for troubleshooting and survived for years. Continuous checks catch drift that a one-off review misses.
- Long-lived keys leak. Keys in code, files and backups turn up in places nobody expected. Roles and short-lived credentials remove the problem.
We see the same patterns in the accounts we scan today. Our guide to ten common AWS misconfigurations covers how to fix each one.
Check your own account
You can check the most important of these settings by hand in under 30 minutes with our five AWS security checks, or understand what each Security Hub finding means with our guide to Security Hub findings in plain English.
bearhug runs these checks continuously through Security Hub and GuardDuty, explains every finding in plain English and fixes common issues, such as a public bucket or an open port, in one click with rollback. See how our AWS misconfiguration scanner works.