What AWS security misconfigurations actually cost

AWS security misconfigurations are wrongly set permissions, access controls, or storage policies in Amazon Web Services that expose data without an attacker needing any exploit. They drive more cloud breaches than malware. A Threat Stack report referenced by Aquasec found more than 73% of companies have at least one critical security misconfiguration in production at any given time. This post walks through four real postmortems pulled from regulatory filings and security research: what happened, how long it sat undetected, what it cost, and the one control that would have stopped it.

Key Takeaways

• Capital One's 2019 breach cost over $270M in fines and settlements and started with a single SSRF request against IMDSv1.

• Toyota left AWS access keys in a public GitHub repository for nearly five years, exposing 296,019 customer records.

• Pegasus Airlines exposed 6.5TB of flight operations data in a single S3 bucket with no authentication required.

• Three controls (IMDSv2, S3 Block Public Access at the account level, secrets scanning) would have prevented all four cases below.

Why do misconfigurations beat malware in cloud breaches?

Cloud breaches rarely involve novel exploits. Attackers make valid API calls against services configured to allow them. The misconfiguration is the vulnerability. The attacker's sophistication is incidental.

Across documented AWS incidents, initial access required no zero-day. It required a public bucket, a forgotten key, or an IAM role granted "for now" and never narrowed. Permissions stack up across deployments. Nobody audits the accumulation. Several AWS defaults remain permissive by design: IMDSv1 on older EC2 instances, public ACLs on S3 buckets created before 2023, and IAM keys that never expire unless you write a policy to rotate them.

The pattern is consistent in every public postmortem we reviewed. Misconfiguration introduced months or years before discovery. No continuous monitoring watching for that specific exposure condition. Detection only after an external researcher, a leaked dataset, or a regulator forced the issue into the open. The gap between exposure and discovery is rarely measured in hours.

Capital One, 2019: one SSRF request, 106 million records

In March and April 2019, an attacker exploited a misconfigured AWS WAF to perform a server-side request forgery (SSRF) attack against the EC2 Instance Metadata Service (IMDSv1). The metadata service returned temporary IAM credentials for the role attached to the instance. That role had broad S3 read permissions across Capital One's account. The result: records for 100 million US customers and 6 million Canadians.

Capital One paid an $80 million civil money penalty to the Office of the Comptroller of the Currency in 2020, followed by a $190 million class action settlement. The attacker, Paige Thompson, was identified after she posted stolen data references on GitHub three months after the breach.

The root cause chain is the lesson. The WAF misconfiguration allowed the SSRF. IMDSv1 returned credentials with no hop-limit protection. The IAM role was scoped to "all of S3" rather than specific bucket prefixes. Enforcing IMDSv2 across the account closes the SSRF-to-metadata path entirely. Least-privilege IAM scoped to bucket prefixes contains the blast radius even if credentials leak. GuardDuty anomaly detection flags S3 listing patterns no application has ever performed before. Any one of those three controls breaks the chain.

Pegasus Airlines, 2022: 6.5TB sitting in a public bucket

In January 2022, Zscaler ThreatLabz researchers discovered a publicly accessible S3 bucket belonging to Pegasus Airlines containing 6.5TB across 23 million files. No authentication required to list or download. Electronic Flight Bag data, navigation charts, crew personal identity documents, and source code for internal operational tools, all readable by anyone who guessed or scanned the bucket URL.

The root cause was a single setting. The bucket was created without enabling S3 Block Public Access, a control that is opt-in rather than enforced by default on AWS accounts created before April 2023. There was no logging configured either, which means we cannot tell whether anyone reached the data before Zscaler did.

What would have caught this is the cheapest control in cloud security. S3 Block Public Access can be enforced at the account level, one toggle, every bucket. AWS Config rule s3-bucket-public-read-prohibited flags any drift back to public. Amazon Macie scans S3 contents for PII and raises priority when it finds sensitive data in a public location. None of these require a dedicated team to run.

Toyota, 2017 to 2022: AWS keys on GitHub for five years

In October 2022, a security researcher discovered that Toyota had accidentally committed AWS access keys to a public GitHub repository in December 2017. The credentials remained valid and publicly accessible for nearly five years. During that window, location data and vehicle identification numbers for 296,019 Toyota customers in Japan sat reachable by anyone who pulled the repo.

The mistake is one every engineering team has made at smaller scale. Access keys hard-coded into application source code rather than read from a secrets manager. Repository visibility changed to public during a refactor or open-source push, with no pre-merge secret scan in the pipeline.

Three controls would have caught this before it ever shipped. Pre-commit hooks like git-secrets or GitGuardian block credential patterns at the developer's machine, before the push leaves the laptop. IAM access key rotation policies flag or auto-expire keys older than 90 days, so even leaked credentials die on a schedule. AWS IAM Access Analyzer identifies resources reachable from outside the account. Toyota's five-year exposure window is what happens when none of those are in place. Most teams we audit have none of them in place either.

What do all four aws security misconfigurations share?

Across Capital One, Pegasus Airlines, Toyota, and the 2021 Twitch source code leak (125GB exposed via misconfigured S3 ACLs), three failure modes repeat. Permissions set too broadly at deployment and never reviewed. Public access left on and never audited. Credentials stored where automated scanners can reach them.

None of these attacks required advanced capability. Each one exploited a documented, fixable AWS default. The detection gap in every case was weeks to years, because nothing was watching for the specific condition that created the exposure. If you are preparing for a compliance audit, this is the failure surface auditors care about. See our notes on surviving your first pentest and the NIS2 compliance checklist for B2B SaaS for the controls that directly map to these findings.

Which tools catch AWS misconfigurations before attackers do?

AWS Security Hub, Prowler, and AWS Config together cover the control failures present in all four postmortems. None require a dedicated security team to operate. Security Hub's Foundational Security standard runs over 180 automated checks across an AWS account and benchmarks results against CIS standards.

The shortlist worth running this quarter:

• AWS Security Hub: continuous checks against AWS FSBP and CIS benchmarks. Flags overprivileged IAM, public S3, disabled CloudTrail, missing MFA, IMDSv1 in use.

• AWS Config: rule-based detection, including s3-bucket-public-read-prohibited, iam-no-inline-policy, and access-keys-rotated (catches keys older than 90 days).

• Prowler: open-source CLI with 300+ checks mapped to CIS, GDPR, HIPAA, and ISO 27001. Runs against any AWS account, no agents, free.

• Amazon Macie: scans S3 buckets for PII and credentials, alerts when sensitive data sits in a publicly accessible bucket.

• IAM Access Analyzer: identifies IAM roles, S3 buckets, and KMS keys reachable from outside your account or organization.

If you have run none of these against your production account in the last 90 days, that is the first audit to schedule. The output is usually short and uncomfortable.

Frequently Asked Questions

What is the most common AWS security misconfiguration?

Overly broad S3 bucket permissions and overprivileged IAM roles. The Capital One and Pegasus Airlines cases are both instances of permissions granted at deployment and never narrowed. Most accounts have at least one bucket or role that grants more access than the application actually uses.

How often are S3 buckets misconfigured?

Frequently enough that researchers find new public buckets containing sensitive data every month. The structural problem is that S3 Block Public Access was opt-in until April 2023, so older accounts inherited permissive defaults. New accounts have it enforced by default, but bucket policies and ACLs can still re-open access if misconfigured.

What tools detect AWS misconfigurations?

AWS Security Hub, AWS Config, and Prowler cover the largest surface. Security Hub runs continuous CIS benchmark checks. Config offers rule-based drift detection. Prowler is open source and runs 300+ checks against any AWS account without installing agents. Together they catch the issues behind the breaches above.

Are AWS misconfigurations covered by NIS2 or DORA?

Yes. Both frameworks require documented controls over access management, configuration management, and continuous monitoring of cloud infrastructure. Public S3 buckets and unrotated IAM keys are findings auditors will raise directly.

Find what's exposed before someone else does

Most B2B AWS accounts we audit have three to five of the exact misconfigurations above sitting in production right now: public buckets, IAM roles scoped too wide, keys older than the engineer who created them. If you want a clear picture of what's actually exploitable in your stack, book a Free Cybersecurity Audit. Thirty minutes, named findings, no PDF report theater.