The Breach Heard Around the World
July 2019. Paige Thompson, a former AWS engineer, accessed the personal data of over 100 million Capital One customers and applicants. Names, addresses, credit scores, Social Security numbers, bank account numbers. The largest financial data breach in US history at the time.
The vulnerability she exploited wasn't obscure. It wasn't a novel zero-day discovered after years of research. It was a misconfigured IAM role — a permissions setting that should have been narrow and specific, but was instead broad enough to let her walk out with everything.
Capital One spent $80 million in regulatory fines and an estimated $150 million in remediation costs. The reputational damage was incalculable. And the root cause was something any IAM audit would have found.
"The vulnerability wasn't a sophisticated exploit. It was a permissions setting that gave one user far more access than she ever needed."
A Technical Misstep Becomes a Catastrophe
Thompson used a server-side request forgery (SSRF) vulnerability in Capital One's AWS infrastructure to trick a web application into making requests on her behalf. That application ran on an EC2 instance with an attached IAM role. The role's permissions were far broader than they needed to be.
Using the SSRF vulnerability, Thompson queried the EC2 metadata service — a standard AWS feature — to retrieve the temporary credentials attached to that IAM role. With those credentials, she had access to over 700 S3 buckets. She exfiltrated 106 gigabytes of data over several months without triggering a single alert.
The attack was technically sophisticated in its execution, but its foundation was entirely mundane: a role with too many permissions, attached to a system exposed to the internet, with no behavioral monitoring to detect unusual access patterns.
-
01
Overly permissive IAM role violating least privilege The EC2 instance's IAM role had ListBucket and GetObject permissions across hundreds of S3 buckets. The role should have been scoped only to the specific resources that application needed to function.
-
02
No behavioral monitoring or anomaly detection 106 gigabytes of data was exfiltrated over months. No alert fired. No threshold was breached in a system configured to notice. The data left silently because nobody had defined what "unusual" looked like.
-
03
IMDSv1 enabled without restriction AWS had already released IMDSv2 — a session-oriented version that prevents SSRF-based credential theft. Capital One was still running IMDSv1. The fix existed. It wasn't applied.
Why IAM Is the First Line of Defense
In cloud environments, identity is the perimeter. There is no physical boundary, no network edge that means what it once did. Every action taken against your cloud infrastructure — reading data, writing it, deleting it, spinning up resources — is authorized through an identity and its associated permissions.
When that identity is misconfigured, when it carries permissions it doesn't need, the security model collapses. An attacker who finds a way to assume that identity — through SSRF, credential theft, social engineering, or a dozen other vectors — inherits everything it's allowed to do. They don't look like an attacker. They look like an authorized user. Traditional security tools don't flag authorized users.
This is why IAM misconfiguration is consistently ranked among the top causes of cloud breaches. The access is granted legitimately. The misuse is invisible to controls built to detect unauthorized behavior.
The Bigger Problem: Security Incentives Are Misaligned
IAM misconfiguration at scale is rarely the result of negligence. It's the result of rational behavior in a system with bad incentives. Broad permissions are faster to configure. Least privilege takes time to define correctly. Under delivery pressure, engineers choose broad permissions and move on. The IAM debt accumulates quietly.
Cloud environments compound the problem. Hundreds of services, each with its own permission model. Roles created for one purpose that drift into serving others. Permissions added incrementally and never reviewed. What starts as a pragmatic shortcut becomes structural exposure nobody owns.
Capital One had an AWS environment complex enough that a single misconfigured role could reach 700 S3 buckets. The question isn't whether your environment has similar exposure. The question is whether you know where it is.
How to Fix IAM Before It's Too Late
Enforce least privilege rigorously, not aspirationally. Every role and policy should be scoped to the minimum permissions required for its specific function. Permission reviews shouldn't happen annually — they should happen every time a role is created or modified, and on a rolling schedule for existing roles.
Enable and monitor AWS CloudTrail and S3 access logs. The tools to detect the Capital One attack existed when it happened. They weren't configured to alert on the behavior that mattered. Define what anomalous access looks like for your environment — volume thresholds, unusual API calls, access from unexpected sources — and build alerts around it.
Migrate to IMDSv2 across all EC2 instances. IMDSv2 requires a session token that a server-side request forgery attack cannot obtain. The Capital One breach vector — SSRF exploiting the metadata service — is significantly harder to execute against IMDSv2. AWS now defaults to it. Verify your environment isn't still running the vulnerable version.
The Final Lesson: Your Identity Layer Is Your Attack Surface
Capital One had security teams, compliance programs, and AWS expertise. None of it caught a misconfigured role before an attacker did. The gap wasn't capability — it was visibility. Nobody had a clear, current picture of which identities could access which resources, under what conditions, and whether those permissions still made sense.
That gap exists in most cloud environments. It grows every time a new service is provisioned, every time a role is created under deadline pressure, every time a permissions review is deferred to next quarter. The attacker who eventually finds it doesn't need sophistication. They need time and a misconfiguration to exploit.
The question worth asking today: if someone assumed your most permissive IAM role right now, what could they access? If you don't know the answer with confidence, that's where the work starts.
Taking Action: The RRS IAM Compliance Deep-Dive
The Capital One breach is a case study in what happens when IAM posture is assumed rather than verified. The controls existed. The visibility didn't. Most environments we assess have the same pattern — security confidence built on assumption, not evidence.
Risk Ready Identity conducts focused IAM assessments that map your current permissions posture, identify over-privileged roles and stale access, and give you a prioritized remediation roadmap. Two weeks. No lengthy engagement. A clear picture of what an attacker would find before they find it themselves.
The breach that costs you most is the one you didn't know was possible.
IAM insights. No pitch. No filler.
Case studies and field reports from inside the environments where identity governance breaks down — and how to fix it.
Subscribe — it's free