Exploiting IAM Misconfigurations

In the cloud, privilege escalation usually means abusing IAM permissions rather than exploiting memory bugs. If a low-priv identity can modify policies, create keys, or assume roles, it can reach admin.

• Permissions that modify IAM are inherently dangerous.
• Escalation paths are policy logic, not vulnerabilities.
• The fix is least privilege, not a patch.

Certain IAM actions enable direct escalation. Watch for these on a principal you control:

• iam:CreateAccessKey on another user.
• iam:AttachUserPolicy / iam:PutUserPolicy (attach AdministratorAccess).
• iam:CreatePolicyVersion (rewrite an existing policy).
• iam:PassRole + a compute service (run code as a privileged role).
• sts:AssumeRole with a weak trust policy.

If your identity can attach policies to itself, escalation is one call away. You attach a managed admin policy and inherit full rights.

iam:PassRole lets you hand a role to a service. Combined with a service that runs your code (EC2, Lambda, Glue), you execute as that role, even if it is far more privileged than you.

iam:CreatePolicyVersion or SetDefaultPolicyVersion lets you replace a policy's active document or roll back to a more permissive past version, granting broad access without touching group membership.

Role trust policies define who may assume them. Weak trust conditions enable takeover.

• A role trusting * or a whole account can be assumed broadly.
• If you can edit a role's trust policy, add yourself as a trusted principal.
• Confused-deputy: external IDs missing on third-party integration roles.

The same patterns appear across providers.

• Azure: a User Access Administrator or Owner role assignment; Managed Identity abuse; adding credentials to a service principal.
• GCP: iam.serviceAccounts.actAs plus a compute service; setIamPolicy on a project; service-account key creation.

Rather than guessing, use tooling to surface viable escalation paths from your current identity.

Escalation often chains data-plane access into control-plane power.

• Compromise a VM, steal its instance-role credentials from metadata.
• The instance role has PassRole + Lambda, enabling admin role execution.
• From admin, create persistent access keys for stealth.

Each link is a separate finding worth reporting.

Prevention centers on least privilege and guardrails.

• Remove wildcards; scope actions and resources tightly.
• Use permission boundaries and SCPs to cap maximum privilege.
• Require external IDs on third-party roles; scope trust policies.
• Prefer short-lived role credentials over long-lived keys.
• Use access analyzers to flag risky and unused permissions.

IAM escalation can grant account-wide power. Stop at proof-of-concept: demonstrate the path without creating durable backdoors or modifying production policies you cannot revert. Always revert any policy or role changes and remove keys you create.

Coordinate disruptive steps (like rewriting a shared policy) with the client beforehand.

Confirm your IAM escalation knowledge.

You learned how IAM misconfigurations escalate privilege.

• Policy attachment, PassRole, version rollback, and AssumeRole are core paths.
• The same patterns recur across AWS, Azure, and GCP.
• Pacu and PMapper discover viable paths automatically.
• Least privilege, permission boundaries, and external IDs are the defenses.

Next: persistence and lateral movement across cloud accounts.