Most AWS breaches do not start with a CVE. They start with a stolen credential, a leaked secret or a setting left open, and the public record says so consistently across a decade of incidents.

That matters for prioritization. Lists like the CISA Known Exploited Vulnerabilities catalog are excellent for patching software, but AWS-managed services are not something you patch. The risk you control lives in identity, configuration and the workloads you run on top.

This post uses only published data: incident catalogs, breach disclosures, court records and vendor research reports. Every number below links to its source.

The data behind this post

The evidence comes from three kinds of sources. Each has blind spots, so the post leans on findings that show up in more than one.

Source What it measures Scope
AWS Customer Security Incidents (Rami McCarthy) Public AWS customer breaches with a known root cause Excludes simple exposed data stores
Datadog State of Cloud Security 2025 Posture of real AWS, Azure and Google Cloud accounts Thousands of organizations
Google Cloud Threat Horizons H1 2026 Initial access in cloud incidents Google and Mandiant investigated H2 2025 activity
Verizon DBIR 2026 Initial access across all breaches 22,000+ breaches, Nov 2024 to Oct 2025
Unit 42 EleKtra-Leak research How fast leaked AWS keys are abused Honeypot experiment
Breach disclosures and court records Individual incidents (Capital One, Uber, Codefinger and others) Case studies

One caution applies throughout. Public breach data over-represents incidents that companies had to disclose, and vendor reports describe their own customers.

Finding 1: Stolen credentials are the most common way in

Across the cloud-specific data, identity is the leading entry point. Datadog notes that its earlier research found long-lived credentials to be the most common cause of publicly documented cloud breaches.

The exposure is still large. In Datadog’s 2025 data, 59% of AWS IAM users have an active access key older than one year, and over half of those keys had gone unused for more than 90 days. The 2024 edition put the same figure at 60%, so a year brought almost no change.

Incident response data agrees. Google’s Mandiant attributed 83% of initial access in platform-agnostic cloud and SaaS incidents to identity, and Palo Alto Networks tied 65% of initial access to identity in its 2026 incident response report, per the same article.

The breach that set the pattern. In 2016, attackers used an AWS access key an Uber engineer had posted on a code-sharing site. The FTC’s revised complaint says they downloaded unencrypted files with over 25 million names and email addresses and 600,000 driver’s license numbers of US users. Uber’s earlier 2014 breach followed essentially the same path: a key posted publicly on GitHub.

An important counterpoint. The trend is shifting at the edges. Google reports that in H2 2025, software exploitation (44.5%) overtook weak or missing credentials (27.2%) as the top initial access vector in Google Cloud for the first time. Verizon’s 2026 DBIR shows the same shift across all breaches, with vulnerability exploitation at 31% versus 13% for credential abuse. Credentials remain the core cloud risk, but patching exposed workloads now matters more than it did two years ago.

Finding 2: Keys leak through code, CI and web servers, and attackers find them in minutes

The credentials in Finding 1 have to come from somewhere. The data points to code repositories, build systems and misconfigured web servers.

Leaks are growing, not shrinking. GitGuardian found 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% rise and the largest single-year jump it has recorded. It also found internal repositories were six times more likely to contain hardcoded secrets than public ones. Earlier, Unit 42’s Cloud Threat Report found 83% of organizations had hard-coded credentials in production code repositories.

Attackers are faster than you. In Unit 42’s EleKtra-Leak honeypot, an attacker detected and used AWS keys within five minutes of their exposure on GitHub. Over five weeks in 2023, researchers counted 474 unique miners that were potentially attacker-controlled EC2 instances. AWS’s automatic quarantine policy helped, but the researchers believe the actor can also find keys AWS does not detect.

Web servers leak too. In 2024, Unit 42 uncovered an extortion campaign that harvested .env files from about 110,000 domains, yielding more than 90,000 unique environment variables, 7,000 of them for cloud services. Unit 42 named three failures: exposed environment files, long-lived credentials and no least-privilege architecture. None of it involved a flaw in AWS itself.

The lesson from these three data points is that secret scanning helps, but it cannot outrun a five-minute exploitation window. Removing long-lived keys removes the thing worth stealing.

Finding 3: Workloads are a credential source, and IMDSv1 is still common

An application bug on EC2 can become an AWS breach when the attacker can reach the instance metadata service and steal the role’s credentials.

The case study everyone cites. In 2019, a former AWS engineer used a tool she built to scan AWS for misconfigured accounts and then downloaded data from more than 30 entities, including Capital One. Capital One described the root cause as a server-side request forgery (SSRF) vulnerability, and a court filing cited a misconfigured web application firewall. The breach affected more than 100 million customers. Capital One was fined $80 million and settled customer lawsuits for $190 million, and the attacker was convicted in 2022.

The fix exists, but adoption is slow. IMDSv2 blocks this class of SSRF credential theft. Datadog’s yearly data shows how slowly it spread:

Year of report EC2 instances enforcing IMDSv2 Source
2025 About 1 in 2 Datadog 2025
2024 32% Datadog 2024
2023 21% Datadog 2023
2022 7% Datadog 2023

The gap is not technical. In 2024, 70% of EC2 instances had used only IMDSv2 in the past two weeks, so they could have enforced it with no functional impact.

Workloads also carry too much privilege. Datadog’s 2024 data found more than 18% of EC2 instances had sensitive permissions, so anyone who compromises one can steal powerful credentials. The same report found 10% of third-party integrations had risky permissions, up to full account takeover.

Unpatched software is rising as an entry point. Datadog’s 2026 DevSecOps report found 87% of organizations run at least one known exploitable vulnerability in deployed services. Verizon’s 2026 DBIR, as summarized by Tenable, found organizations fully remediated only 26% of CISA KEV vulnerabilities, and median time to patch grew from 32 to 43 days. This is where the KEV catalog belongs in an AWS program: on your internet-facing EC2, container and Lambda workloads. Your AWS KEV list applies the same “known exploited” idea to AWS conditions that never get a CVE.

Finding 4: Attackers move in minutes, and the payoff has changed

Once attackers hold a key, the time to damage is now measured in minutes. On November 28, 2025, Sysdig observed an attacker go from credential theft to admin privileges in about eight minutes, with strong signs the steps were generated by an LLM. The keys came from a public S3 bucket, and the attack moved across 19 distinct AWS principals. Escalation worked because a Lambda function had an administrative execution role attached, a known and documented path.

What attackers do with access has also broadened beyond data theft:

Outcome Real example What it cost or did
Ransomware on S3 Codefinger, January 2025 Encrypted S3 data with AWS’s own SSE-C using stolen keys, then set lifecycle rules to delete files within seven days. No AWS vulnerability was involved. How one RCP stops it.
Abuse of AI services (LLMjacking) Sysdig research, 2024 Worst-case Bedrock bill estimated at over $46,000 per day, potentially up to $100,000 per day on newer models. One victim owed $30,000 after three hours. How to stop LLMjacking.
Cryptomining EleKtra-Leak, 2020 to 2023 Attacker spun up EC2 instances in every reachable region to mine Monero.
Extortion .env campaign, 2024 Data taken from S3 and replaced with a ransom note.
Data theft Capital One, 2019 100+ million customers affected; $80M fine plus $190M settlement.

Two things stand out. Every example started with a credential the victim controlled, and several abused normal AWS features rather than a bug. That is why prevention and guardrails matter more than detection alone: a human-paced response cannot beat an eight-minute escalation.

Finding 5: Exposed storage is shrinking, but old configurations linger

Public S3 buckets are the oldest cloud breach story, and secure defaults are slowly closing them. In 2022 alone, Datadog counted close to 20 publicly reported breaches caused by public S3 buckets.

The numbers have improved since AWS began blocking public access on new buckets in April 2023. By 2024, 79% of S3 buckets were covered by S3 Public Access Block, up from 73% a year earlier, and 1.48% were effectively public. The 2025 study, however, found that adoption of public access blocks is now plateauing. New defaults protect new buckets; they do nothing for buckets created years ago.

Misconfiguration as an entry point is real but second to identity. Google’s data put misconfiguration at 29.4% of cloud initial access in H1 2025, behind weak or absent credentials at 47.1%. It then fell to 21% in H2 2025.

Misconfiguration also feeds the other findings. The eight-minute Sysdig intrusion started with keys in a public bucket, and the .env campaign started with a web server serving its configuration file to anyone who asked.

From root cause to control

Each control below is tied to a root cause that appears in the public record. They are ordered by how often that root cause shows up in the data above.

Priority Root cause in the data Evidence Control that addresses it
1 Long-lived IAM access keys 59% of IAM users have keys older than a year; Uber, EleKtra-Leak, Codefinger IAM Identity Center for people, roles and OIDC federation for workloads and CI; an SCP that blocks creating IAM users, as Datadog recommends
2 Secrets in code, CI and web servers 28.65M secrets leaked on GitHub in 2025; 110,000 domains with exposed .env files Secret scanning with push protection in every repo and pipeline; never ship credentials in config files
3 Over-privileged identities 18% of EC2 instances with sensitive permissions; admin Lambda role in the 8-minute intrusion Least privilege with IAM Access Analyzer; remove admin roles from workloads
4 SSRF to instance metadata Capital One; only about half of EC2 instances enforce IMDSv2 Enforce IMDSv2 on every instance and as the regional default
5 Native features abused after compromise Codefinger SSE-C ransomware; LLMjacking on Bedrock Organization guardrails, such as an RCP that blocks SSE-C, as Rewind did, and deny lists for unused AI models and regions
6 Stolen keys used from outside your network Every credential case above Data perimeters using conditions such as aws:PrincipalOrgID and source VPC
7 Unpatched internet-facing workloads 87% run a known exploitable vulnerability; only 26% of KEV fixed Patch exposed EC2, containers and Lambda dependencies against CISA KEV first
8 Public storage Close to 20 public S3 breaches in 2022; adoption now plateauing Account-level S3 Block Public Access, protected by an SCP
9 Slow detection Admin access in 8 minutes CloudTrail in all regions, GuardDuty, and automated response for key misuse

The first two rows matter most. If no long-lived key exists, there is nothing to leak in a repository, a .env file or a public bucket.

Conclusion

A decade of public AWS breaches tells a consistent story: attackers log in rather than break in. Uber in 2016 and the Sysdig intrusion in 2025 started the same way, with a valid key found where it should not have been.

What has changed is speed and payoff. Keys are found in five minutes, admin rights follow in eight, and the result can be ransomware, a five-figure daily AI bill or stolen data. Exploitation of unpatched software is also rising, so CISA KEV deserves a place in your program, aimed at the workloads you run on AWS.

If you do only three things after reading this, remove long-lived access keys, enforce IMDSv2 everywhere and put organization-level guardrails in place. The public record suggests those three would have stopped or contained most of the incidents above.

Sources

Incident catalogs and breach analyses

Industry reports

Threat research

Case records and news coverage