IAM Misconfigurations

In the cloud, identity is the new perimeter. IAM (Identity and Access Management) decides who can do what. A flaw in IAM lets an attacker move from a low-privilege foothold to full account control.

• Users, roles, and service accounts are identities
• Policies define permissions
• Misconfigured policies are the number-one cloud risk

Most cloud privilege escalation is an IAM problem.

AWS IAM has three building blocks you must understand:

• Users — long-lived identities with access keys
• Roles — temporary identities that can be assumed by users or services
• Policies — JSON documents granting or denying actions on resources

A policy attached too broadly is how over-permissioning happens.

The single most dangerous IAM pattern is the wildcard policy. It grants every action on every resource.

If an attacker compromises an identity with this policy, they own the entire account.

Once you hold a credential, list what it can do. IAM has read APIs that reveal attached policies.

Some accounts even grant iam:Get* and iam:List* to ordinary users, handing you a free map.

A classic escalation: a user has iam:PassRole plus a service-creation permission. They can launch a resource that assumes a high-privilege role and inherit its access.

• User has ec2:RunInstances + iam:PassRole
• They launch an EC2 instance with an admin role attached
• The instance now holds admin credentials, which they retrieve

The user never had admin directly, but escalated into it.

Individual permissions can be harmless but become escalation paths in combination. Known risky combos include:

• iam:CreatePolicyVersion — rewrite an existing policy to grant admin
• iam:AttachUserPolicy — attach AdministratorAccess to yourself
• iam:CreateAccessKey on another user — steal their identity
• sts:AssumeRole on an over-trusting role

Tools enumerate these automatically.

Roles have a trust policy defining who may assume them. An over-broad trust policy is a backdoor.

If a role trusts the whole account or even an external account by mistake, an attacker can assume it.

Manually checking every policy combination is tedious. Tools map escalation paths for you.

• Pacu — AWS exploitation framework with privesc modules
• PMapper — graphs IAM relationships and finds privesc edges
• enumerate-iam — brute-forces which API calls a key can make

Permissions can be granted two ways, and attackers check both:

• Managed policies — reusable, attached to many identities
• Inline policies — embedded directly in one user/role

Inline policies are easy to miss in audits, so they often hide excessive permissions. Always enumerate both when assessing an identity.

The fix for IAM misconfigurations is least privilege: grant only the exact permissions needed.

• Replace wildcards with explicit actions and resource ARNs
• Use roles with short-lived credentials instead of long-lived keys
• Audit unused permissions with Access Analyzer
• Enforce MFA on privileged identities

Your report should map each finding to a least-privilege remediation.

Privilege escalation testing actively changes account state. Be careful:

• Creating policies, keys, or roles is intrusive, get written approval
• Document every change so it can be reverted
• Prefer read-only enumeration to prove a path before exploiting it

Demonstrating that a privesc path exists is often enough, you do not always need to fully exploit it.

Which permission combination is a classic AWS privilege-escalation path?

You learned why IAM is the cloud's true perimeter and how attackers exploit it.

• Wildcard Action:* Resource:* policies are catastrophic
• iam:PassRole + service creation enables privilege escalation
• Over-broad trust policies let attackers assume roles
• Tools like Pacu and PMapper automate path discovery
• Remediation is always least privilege

Next we look at S3 and storage exposure.