BIPI
BIPI

The Cloud IAM Audit That Catches Real Privilege Escalation

Cloud Security

Cloud security posture tools flag misconfigurations. They miss most of the actual privilege-escalation paths. The five AWS IAM combos we look for first, and how to find them.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 22, 2025 · 7 min read

#aws#iam#cloud-security#privilege-escalation

Most cloud security tools flag the wrong thing. They tell you about overly permissive S3 buckets, misconfigured security groups, and roles with wildcards in their trust policies. Those are real findings. They are also not how attackers usually escalate. The escalations we see in incident response come from the legitimate IAM permissions a user already has, chained in ways the team did not design.

These chains are invisible to most automated scanners because each individual permission is intentional. The scanner sees a developer with iam:CreateAccessKey and notes nothing. It sees a CI service principal with permissions to assume any role in the org and notes nothing. The escalation is in the combination.

Five privilege-escalation patterns we look for first

These are AWS-flavoured but the same shapes exist in GCP and Azure under different names.

  1. iam:CreateAccessKey on another user. A low-privilege user with this permission can mint long-lived credentials for any IAM user, including admins. Common mis-grant inside 'developer' policies that copied from an internal admin's policy.
  2. iam:PassRole + a compute service. Pass a high-privileged role to ec2:RunInstances, ecs:RunTask, or lambda:CreateFunction and you have escalated to whatever that role can do. The classic exploit chain in pacu and similar tools.
  3. iam:UpdateAssumeRolePolicy on a high-privileged role. Modify the trust policy to add yourself as a principal and now you can sts:AssumeRole into the higher tier. Often missed because UpdateAssumeRolePolicy looks like 'admin' not 'escalation.'
  4. lambda:UpdateFunctionCode on a function with a higher-tier execution role. Push new code, the function runs as the privileged role, you exfiltrate or pivot. This is how a lot of CI/CD compromises end.
  5. iam:AttachUserPolicy or iam:PutUserPolicy on a self-managed user. Attach AdministratorAccess to your own user and the escalation is one API call. This sounds dumb. We find it monthly.

How we run the audit

The standard tools (CSPM platforms, cloud-native security hubs) do not graph these chains. We build the graph manually, or with open-source tools.

Step one is the inventory. Pull every IAM user, role, group, and their attached policies. Resolve any policy that uses managed-policy ARNs to the underlying statements.

Step two is the join. Build a graph where nodes are principals and edges are 'can escalate to.' An edge exists if the principal has a permission combination that lets it impersonate, modify, or take over the target principal. Tools like CloudGoat and pacu encode the logic. We open-source our internal graph generator on engagements that ask.

Step three is the prune. Most graphs have hundreds of edges that are non-exploitable in practice (the target role does not exist, the resource scope is too narrow). Manual review of the high-value paths, especially anything that ends at AdministratorAccess or a Tier 0 role, is where the real findings live.

What gets remediated, in what order

  • Self-modification (iam:Put/AttachUserPolicy on self) is always a finding. Remediate first.
  • iam:CreateAccessKey scoped to specific users only. Never wildcard.
  • iam:PassRole scoped to specific roles via a Resource constraint. Never wildcard.
  • iam:UpdateAssumeRolePolicy restricted to identity-team principals only.
  • Lambda execution roles right-sized: never use a Tier 0 role for a Tier 2 function.

Closing

Cloud privilege escalation is rarely a single bad permission. It is a chain of three or four legitimate permissions that nobody designed together. The audit that catches it is the one that thinks in graphs, not lists. Most teams have never run that audit. The first time we do it on an engagement we usually find at least two clean escalation paths to root.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.