Home / Knowledge hub / Cloud privilege escalation
Knowledge hub
Cloud privilege escalation
Using a small cloud permission to gain a much larger one inside the same account.
What it means
Every cloud identity, whether a person, a role or a service, has permissions that say what it may do. Cloud privilege escalation is when an identity with limited permissions uses them to obtain bigger ones, until it can do things nobody meant to allow.
The steps are often ordinary. A permission to change a policy, to attach a role, or to start a function with a powerful role is enough. Each step is allowed. The sum of them is not what anyone intended. Reading each permission alone will not show it.
Why it matters
Cloud accounts hold the data, the servers and the keys. An identity with full control can read every database, delete backups or create new users to stay in. A stolen low-level key from a build tool or a leaked token can become that identity if a path exists.
This is the cloud version of privilege escalation. It is easy to miss in reviews, because each permission looks small when read alone, and the danger sits in how permissions combine. The overly permissive IAM pages are close neighbours. Map the combinations, not just the list.
How it shows up
Well-known examples include a permission to pass a powerful role to a new function or server, permission to create a new version of a policy, and permission to change who can assume a role. Metadata credentials taken through a web flaw can start the chain, as with IMDS abuse.
To reduce it, grant least privilege, avoid wildcards on actions that change permissions, restrict who may pass roles, and use boundaries or organisation-level limits. Review what each role could reach, not only what it lists. Alert on unusual permission changes in the audit trail.
Questions people ask
Cloud privilege escalation, answered
What is iam:PassRole?
It is an AWS permission that lets an identity hand a role to a service, such as a new server or function. If the role passed is more powerful than the caller, the caller gains that power by proxy.
Limit which roles can be passed.
Is this only an AWS problem?
No. Every major cloud has permissions that can change other permissions or act with another identity. The names differ, the idea does not.
Learn the risky permissions of each provider you use.
How is it different from lateral movement?
Lateral movement is going sideways to reach other systems. Privilege escalation is going upward to gain more rights. Attackers often do both in turn.
Cloud accounts make both quick.
How do we find escalation paths?
List what each identity may do, then ask which of those permissions can change policies, roles, keys or code that runs with other identities. Tools exist to map this, and manual review of high-risk roles works too.
Start with identities that touch the internet.
Does multi-factor authentication stop it?
It protects sign-in by people. It does not help once a stolen access key or token is in use, and it does not limit what an allowed identity can do.
Limit permissions as well.
Related
Terms that sit next to this one
Privilege escalation
Gaining rights you were never given, sideways or upwards.
Overly permissive IAM
Cloud permissions broader than a job needs, so one leak reaches far.
IAM role
A set of cloud permissions that a person or service can temporarily assume.
Least privilege
Giving every person and service the minimum access the job requires.
Lateral movement
Moving from the first thing reached to the things worth taking.
How far does one foothold reach?
Where a web flaw hands over credentials, we show the request that did it. In white-box mode the finding also points to the line of code. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.