Common AWS IAM misconfigurations that lead to breaches

Capital One's 2019 breach exposed data on 106 million customers. Code Spaces shut down permanently in 2014 after an attacker deleted its AWS-hosted infrastructure in hours. Neither company was hacked through a novel exploit — both fell to an AWS IAM misconfiguration: a role with too much trust, a policy with too much reach, or a credential that should never have been exposed. IAM is the control plane for everything in AWS, which is exactly why a single overlooked permission can cascade into full account takeover.

Security teams tend to treat IAM as a checkbox exercise — set up roles once, move on. But IAM is dynamic. New services get spun up, contractors get temporary access that never gets revoked, and "just this once" wildcard permissions quietly become permanent. Below are the misconfigurations that show up again and again in breach post-mortems, and what a real fix looks like.

What is an AWS IAM misconfiguration, and why does it cause breaches?

An AWS IAM misconfiguration is any identity or access setup that grants more trust than a workload or user actually needs — a policy, role, or trust relationship that an attacker can exploit to move laterally or escalate privilege. IAM sits between every AWS resource and the internet, so a misconfigured role isn't a local problem; it's a bridge. In the Capital One breach, a misconfigured web application firewall role had permission to list and read every file in the company's S3 buckets. An attacker exploited an unrelated SSRF vulnerability to get the WAF's temporary credentials, then simply asked AWS for the data those credentials were allowed to see. The application flaw got the attacker in the door; the IAM misconfiguration is what let them walk into every room in the building.

Unit 42's 2023 Cloud Threat Report found that 99% of cloud users, roles, services, and resources analyzed were granted excessive permissions beyond what they actually used — meaning almost every AWS environment has latent IAM misconfigurations waiting to be discovered, not a handful of unlucky exceptions.

What are the most common IAM mistakes teams make?

The most common IAM mistakes cluster around convenience: broad policies, long-lived credentials, and unused permissions that never get cleaned up. In practice, these are the ones we see repeatedly in customer environments and public breach reports:

• Attaching AdministratorAccess or wildcard actions ("Action": "*") to a role "temporarily" during development — and never revisiting it. Temporary is rarely temporary.
• Long-lived IAM user access keys instead of roles, often hardcoded into source code, CI configs, or shared in Slack. Hardcoded AWS keys are one of the most frequently reported causes of public GitHub secret leaks, and stolen keys give attackers persistent, un-rotated access.
• Overly broad trust policies on roles — trusting an entire AWS account, or even "Principal": "*", instead of a specific role ARN or external ID.
• Skipping Condition blocks, like aws:SourceIp, MFA requirements, or sts:ExternalId, that would otherwise scope down when and by whom a role can be assumed.
• Orphaned permissions from departed employees or decommissioned services that were never removed because nobody owns the IAM lifecycle.
• No permission boundaries on roles that can create other IAM roles, which opens the door to privilege escalation chains.

Each mistake is individually small. Combined across dozens of microservices and hundreds of roles, they add up to an attack surface nobody has fully mapped.

What does an overly permissive IAM policy actually look like in practice?

An overly permissive IAM policy is usually one written with a wildcard where a specific resource ARN or action should be. Consider a policy that grants s3:* on Resource: "*" to a Lambda function that only needs to read from one bucket. It works fine in testing — the function does its job — but it also means that if the Lambda's execution role is ever compromised (via a vulnerable dependency, for instance), the attacker inherits full read, write, and delete access to every S3 bucket in the account, not just the one the function was meant to touch.

This pattern is so common that AWS's own IAM Access Analyzer and tools like Netflix's Repokid and Cloudsplaining exist largely to hunt for exactly this gap: policies that grant far more than the service's actual usage pattern requires. The fix is not exotic — it's least privilege, scoped to specific actions and resource ARNs, ideally generated from observed access patterns (CloudTrail logs) rather than guessed at design time. The hard part is doing it continuously, because every new feature and dependency shifts what "least privilege" should actually mean for that role.

How does IAM privilege escalation work in AWS?

IAM privilege escalation in AWS happens when an attacker with limited permissions uses those permissions to grant themselves — or a role they control — broader access, without ever needing admin credentials to start. Security researchers at Rhino Security Labs cataloged more than 20 distinct IAM privilege escalation paths in AWS, and most rely on permissions that look harmless in isolation:

• iam:CreatePolicyVersion lets a user rewrite the permissions on a policy they're already attached to.
• iam:AttachUserPolicy or iam:AttachRolePolicy lets a user attach AdministratorAccess to themselves or a role they control.
• iam:PassRole combined with permission to launch an EC2 instance or Lambda function lets an attacker pass a highly privileged role to a resource they control, then use that resource to act as the role.
• iam:CreateAccessKey on another user lets an attacker mint new long-lived credentials for a more privileged identity.

None of these require a zero-day. They require a policy reviewer who didn't think through the second-order effect of granting a single, seemingly narrow permission. This is why IAM privilege escalation is so often discovered by red teams and so rarely caught by manual review — the exploit path spans multiple policies that look fine individually.

What real breaches were caused by IAM misconfigurations?

Several of the most costly cloud breaches on record trace back directly to IAM misconfiguration rather than a novel exploit. Capital One (2019) is the clearest case: 106 million customer records exposed because a WAF role had S3 permissions far beyond what the application needed. Code Spaces (2014) never recovered after an attacker gained access to its AWS console — reportedly through compromised credentials with excessive privileges — and deleted backups, EBS snapshots, and S3 buckets, forcing the company to shut down within days. Tesla (2018) had an unauthenticated Kubernetes console expose AWS credentials that attackers used to run cryptocurrency mining inside Tesla's own AWS account, pivoting through IAM roles that had more reach than the workload required.

The common thread isn't sophistication. It's that once an attacker gets any foothold — an exposed dashboard, a leaked key, a vulnerable dependency — the IAM configuration decides whether that foothold stays contained or turns into full account compromise.

How can teams actually catch these misconfigurations before attackers do?

Teams catch IAM misconfigurations by treating access policy the same way they treat code: reviewed, tested, and continuously monitored, not set once and forgotten. Concretely, that means:

1. Run IAM Access Analyzer and CloudTrail-based least-privilege tooling on a schedule, not as a one-time cleanup project.
2. Alert on policy changes that introduce wildcards, broad trust principals, or AdministratorAccess attachments, especially outside of change windows.
3. Map privilege escalation paths across roles, not just review individual policies in isolation — the danger is almost always in the combination.
4. Enforce permission boundaries on any role or user that can create or modify IAM entities.
5. Rotate and eliminate long-lived access keys in favor of short-lived, role-based credentials wherever possible.

None of this is a one-time audit. IAM drifts every time someone ships a feature, adds a dependency, or provisions a new service — which is why point-in-time reviews consistently miss the misconfigurations that cause real breaches.

How Safeguard Helps

Safeguard treats IAM as part of the software supply chain, not a separate cloud posture problem bolted on after deployment. We continuously map the identities, roles, and trust relationships tied to your build and deployment pipelines — the same CI/CD systems, containers, and dependencies we're already analyzing for supply chain risk — and flag overly permissive IAM policies, privilege escalation paths, and unused permissions before they ship into production.

Because Safeguard correlates IAM findings with the actual software components and pipelines that use them, teams get context most cloud security posture tools miss: not just "this role has s3:*," but "this role belongs to a Lambda that ingests a third-party dependency with a known vulnerability, and a compromise there would grant broader S3 access than the function needs." That connection — from dependency risk to IAM blast radius — is what turns a routine misconfiguration into a critical, actionable finding, and it's what lets security teams fix the handful of issues that actually matter instead of triaging hundreds of low-signal alerts.

If your organization is running production workloads on AWS, an IAM review isn't optional maintenance — it's one of the highest-leverage security investments available, precisely because so few environments have ever had one done properly.