AWS IAM in Depth

Almost every AWS compromise ends the same way: someone had permissions they should not have, and an attacker found the one action that turned a small foothold into full control. IAM is where all of that is decided. It is a policy engine, and a policy is just JSON that says which identities may call which API actions on which resources. Read the JSON well and you can see the whole attack path before you run anything.

A policy statement has four parts that matter. Effect is Allow or Deny. Action is the API call, like s3:GetObject or iam:CreateAccessKey. Resource is the ARN it applies to. Condition is optional extra rules. A * in Action or Resource is the thing you hunt for, because it means "everything."

{
  "Effect": "Allow",
  "Action": "iam:*",
  "Resource": "*"
}

That block on a user you control is game over. It says this identity can perform any IAM action on any resource, which includes creating a new admin user or attaching AdministratorAccess to itself.

Roles and assume-role

A role is an identity with no long-term password or key. Nobody logs in as a role. Instead, an allowed principal calls sts:AssumeRole and STS hands back temporary credentials that expire, usually in an hour. Roles are how EC2 instances, Lambda functions, and cross-account access all work.

The gate on assume-role is the role's trust policy, a separate document that names who is allowed to assume it. A trust policy with "Principal": {"AWS": "*"} and no condition lets anyone in any account assume that role. That misconfiguration is rare in production and pure gold when you find it.

The privilege escalation paths

Rhino Security published the canonical list of IAM privesc methods, and they still work because they are features, not bugs. You do not need admin to become admin. You need one of a couple dozen specific permissions on the wrong resource.

The cleanest is iam:CreateAccessKey on another user. If you can create an access key for the admin user, you just log in as admin.

$aws iam create-access-key --user-name admin

iam:AttachUserPolicy is just as good: attach AdministratorAccess to yourself and you are done. iam:PutUserPolicy lets you write an inline policy granting whatever you want. iam:PassRole combined with a service that runs code, like lambda:CreateFunction or ec2:RunInstances, lets you launch a resource carrying a high-privilege role and read its credentials. iam:CreatePolicyVersion lets you quietly swap a policy's active version for one you write.

The fastest way to check for all of these at once is Rhino's enumerate-iam tool, which brute-forces which API calls your key can make.

$python3 enumerate-iam.py --access-key AKIA... --secret-key ...

Defenders should read this list as a deny list. No human user needs iam:*. Scope IAM permissions to specific resources, keep PassRole locked to named roles, and alarm on iam:CreateAccessKey and iam:AttachUserPolicy in CloudTrail, because a legitimate admin does those rarely and an attacker does them immediately.