AWS privilege escalation is a permission problem. A principal that holds one of a known set of dangerous actions can promote itself to administrator without touching a host. The catalog below is the union of the BishopFox iam-vulnerable paths and the Rhino Security Labs method list, grouped by the primitive each one abuses.

The paths#

• PassRole: iam:PassRole combined with a service-creation action (EC2, Lambda, Glue, CloudFormation, Data Pipeline, CodeBuild, SageMaker) to run code as a privileged role.
• Policy manipulation: editing IAM policy directly, through new default policy versions and attaching or inlining user, group, and role policies.
• Credential creation: minting new credentials for a principal you can write to, through access keys and console login profiles.
• Existing resources: escalating through resources that already run with a privileged role, by updating stacks, dev endpoints, and function code, or minting presigned URLs and Instance Connect access.
• Group membership: iam:AddUserToGroup to join a group that carries more permissions.
• Trust policy: rewriting a role's AssumeRolePolicyDocument so you can assume it.

Choosing a path#

The quietest paths require no new resource: a CreatePolicyVersion or AttachUserPolicy changes the principal in place. Paths that create a resource (an EC2 instance, a Lambda) are louder but work when the only lever you hold is PassRole plus a run action. PMapper and Pacu's iam__privesc_scan enumerate which of these the current principal can reach.

References#

• BishopFox: iam-vulnerable
• Rhino Security Labs: 21 ways to escalate privileges in AWS
• HackTricks Cloud: AWS privilege escalation
• Pacu (Rhino Security Labs)
• Hacking the Cloud: AWS