Cloud IAM privilege escalation: the patterns that keep working
AWS, GCP, and Azure all have rich permission models. Every one of them has a half-dozen escalation paths that work depressingly often. Here are the ones I check first on every cloud pentest.
Cloud IAM is the single highest-leverage attack surface in modern infrastructure. Get root in an AWS account and most of the rest of the security review is academic. Despite a decade of public research and well-known escalation patterns, the same handful of mistakes keep showing up on every cloud pentest I run.
On AWS, the four patterns I check first are: iam:PassRole misuse (a user with limited permissions can pass a powerful role to a service that will assume it on their behalf), Lambda execution role escalation (a user with lambda:UpdateFunctionCode can replace the code of a function whose execution role has more permissions than they do), CloudFormation drift (a user with cloudformation:CreateStack can deploy a stack whose role has more permissions), and SSM Parameter Store secrets that grant access to other services. None of these are novel. All of them work in production accounts I've reviewed in the last six months.
On GCP, the dominant pattern is service account impersonation chains. A user with iam.serviceAccountTokenCreator on one service account can impersonate it; that service account has roles/owner on a project; you now have owner. The chain is often three or four hops long, and it's invisible without explicit graph analysis because no single permission grant looks dangerous. Tools like GCP Scout and roles-eye can find these, but very few teams run them on a continuous basis.
On Azure, the equivalent is privileged role assignments through Azure AD and the conditional access policies that don't apply to them. Application registrations with high API permissions are a frequent escalation path, especially when the application's client secret has been committed to a repo or stored in a place that's accessible to a wider audience than intended. The Azure resource graph is a very different model from AWS or GCP and the escalation paths look different — but they exist.
The control that actually moves the needle on this entire class of issue is the same on every platform: continuously enumerate the effective permissions of every principal, graph the escalation paths, and treat every change to the graph as a security event. Static IAM policy review at the time of authorship is necessary but not sufficient. The attack surface is the runtime graph, not the policy document.