AWS_IAM_FULL_CONTROL

Summary

Forestall ACL Alias	AWS_IAM_FULL_CONTROL
Edge Type	Attack Path
Affected Object Types	IAM User, IAM Role, IAM Group, IAM Policy
Exploitation Certainty	Certain
AWS IAM Action	iam:* (all IAM actions)

Description

AWS_IAM_FULL_CONTROL fires when a principal (User or Role) holds an Allow policy statement whose Action is iam:*.

The attacker has full control over IAM objects and can call any IAM operation against them. A single iam:* statement covers every individual IAM escalation primitive, so Forestall ISPM collapses them all into one edge.

When this edge exists, the individual per-action edges (e.g., AWS_CREATE_DELETE_ACCESS_KEY, AWS_ATTACH_USER_POLICY, AWS_PUT_ROLE_POLICY) are not emitted for the same statement. One edge covers every path.

See also: AWS_FULL_CONTROL. That is the broader god-mode edge, emitted when Action is * (all AWS services, not just IAM).

Edge Scope

A statement qualifies when its Action is iam:* with Effect: Allow. The scope of the edge follows the statement's Resource:

• Resource: "*" (or unscoped): full control over every IAM object in the account. All users, roles, groups, and policies.

• Specific Resource ARNs: full control limited to the objects those ARNs resolve to.

Self-edges are not emitted. A principal controlling only itself is not an attack path.

Identification

via AWS CLI

# List all policies attached to a user
aws iam list-attached-user-policies --user-name <username>
aws iam list-user-policies --user-name <username>

# Get policy document, look for Action: "iam:*"
aws iam get-policy-version \
  --policy-arn <policy-arn> \
  --version-id $(aws iam get-policy --policy-arn <policy-arn> \
    --query 'Policy.DefaultVersionId' --output text)

# List all policies attached to a role
aws iam list-attached-role-policies --role-name <rolename>

# Simulate whether a principal has iam:* access
aws iam simulate-principal-policy \
  --policy-source-arn <principal-arn> \
  --action-names "iam:CreateUser" "iam:AttachUserPolicy" "iam:CreateAccessKey"

Exploitation

An iam:* grant hands you every IAM escalation primitive at once. Each primitive has its own edge page with the exact commands, mitigation, and detection. Pick the path that fits the target.

IAM User

You can create a fresh access key on the target user for persistent programmatic access. See the AWS_CREATE_ACCESS_KEY edge for complete abuse details. You can set or reset the user's console password to log in as them directly. See the AWS_CREATE_LOGIN_PROFILE and AWS_UPDATE_LOGIN_PROFILE edges for complete abuse details. You can attach an administrator-equivalent managed policy to the user. See the AWS_ATTACH_USER_POLICY edge for complete abuse details. You can write a permissive inline policy directly on the user. See the AWS_PUT_USER_POLICY edge for complete abuse details. You can add the user to a privileged group to inherit its permissions. See the AWS_ADD_MEMBER edge for complete abuse details.

IAM Role

You can rewrite the role's trust policy to allow yourself to assume it, then assume the role directly. See the AWS_UPDATE_TRUST_AND_ASSUME and AWS_ASSUME_ROLE edges for complete abuse details. You can attach an administrator-equivalent managed policy to the role. See the AWS_ATTACH_ROLE_POLICY edge for complete abuse details. You can write a permissive inline policy directly on the role. See the AWS_PUT_ROLE_POLICY edge for complete abuse details.

IAM Group

You can add yourself, or any principal you control, to the group to inherit its permissions. See the AWS_ADD_MEMBER edge for complete abuse details. You can attach an administrator-equivalent managed policy to the group. See the AWS_ATTACH_GROUP_POLICY edge for complete abuse details. You can write a permissive inline policy directly on the group. See the AWS_PUT_GROUP_POLICY edge for complete abuse details.

IAM Policy

You can push a new, permissive policy version and set it as the default, so every principal already attached to the policy inherits the new grant. See the AWS_CREATE_POLICY_VERSION and AWS_SET_DEFAULT_POLICY_VERSION edges for complete abuse details.

Mitigation

1. Never grant iam:* in a policy statement. Name the specific IAM actions the principal actually needs.

2. Apply permission boundaries to cap the maximum effective permissions of users and roles, regardless of what their attached policies say.

3. Use SCPs at the Organizations level to deny iam:* for all non-administrative accounts.

4. Enable AWS IAM Access Analyzer to flag policies with broad IAM grants.

5. Audit policies attached to users, roles, and groups regularly for wildcard action patterns.

Detection

All of the following IAM API calls appear in CloudTrail. Alert on any of them where the caller is not a known automation role or break-glass account.

Event	Description	Key Fields
iam:CreateAccessKey	New programmatic credentials created	userAgent, requestParameters.userName
iam:CreateLoginProfile / iam:UpdateLoginProfile	Console password created or changed	requestParameters.userName
iam:AttachUserPolicy / iam:AttachRolePolicy	Managed policy attached	requestParameters.policyArn
iam:UpdateAssumeRolePolicy	Trust policy modified on a role	requestParameters.roleName
iam:CreatePolicyVersion	New policy version created	requestParameters.policyArn, requestParameters.setAsDefault
iam:SetDefaultPolicyVersion	Policy default version changed	requestParameters.policyArn, requestParameters.versionId
iam:AddUserToGroup	User added to a group	requestParameters.groupName, requestParameters.userName

References

• AWS IAM Actions Reference

• AWS IAM Privilege Escalation - Rhino Security Labs

• AWS IAM Permission Boundaries

• AWS Service Control Policies

• CloudTrail Event Reference - IAM