AWS_FULL_CONTROL

Summary

Forestall ACL Alias	AWS_FULL_CONTROL
Edge Type	Attack Path
Affected Object Types	IAM User, IAM Role, IAM Group, IAM Policy, Identity Center, Permission Set, SSO Group
Exploitation Certainty	Certain
AWS IAM Action	* (all AWS actions, god mode)

Description

AWS_FULL_CONTROL is emitted when a principal (User or Role) holds an Allow policy statement whose Action is the wildcard *. That is every AWS action across every service.

This is AWS's god-mode edge. It is broader than AWS_IAM_FULL_CONTROL, which covers only iam:*. A principal with Action: "*" can perform any IAM operation and any operation in any other AWS service: EC2, S3, STS, Lambda, Organizations, and everything else.

A single * statement subsumes every individual escalation primitive across all services, so Forestall ISPM collapses them into this one edge.

When this edge is present, the per-action escalation edges (e.g., AWS_CREATE_DELETE_ACCESS_KEY, AWS_ATTACH_USER_POLICY, AWS_IAM_FULL_CONTROL) are not emitted for the same statement. AWS_FULL_CONTROL alone signals that every attack path is open, IAM and non-IAM alike.

Edge Scope

A policy statement qualifies when its Action is * with Effect: Allow. The target objects depend on the statement's Resource:

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

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

Self-edges are not emitted. A principal controlling 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: "*"
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 unrestricted access
aws iam simulate-principal-policy \
  --policy-source-arn <principal-arn> \
  --action-names "iam:CreateUser" "s3:PutObject" "ec2:RunInstances" "sts:AssumeRole"

Exploitation

Action: "*" hands you every escalation primitive at once, in IAM and beyond. Each IAM 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.

IAM Identity Center (SSO)

Action: "*" includes sso:*, so it subsumes SSO full control the same way it subsumes IAM full control. When AWS_FULL_CONTROL is present, the separate AWS_SSO_FULL_CONTROL edge is not emitted. The god-mode edge already covers it. The SSO control plane only answers from the Organizations management account or an Identity Center delegated-administrator account, so these paths open when the principal lives in such an account.

You can assign a privileged permission set to an SSO principal you control and take over the target account. See the AWS_SSO_ASSIGN_PERMISSION_SET edge for complete abuse details. You can rewrite a permission set's policies so every account it is assigned to inherits the new grant. See the AWS_SSO_UPDATE_PERMISSION_SET edge for complete abuse details. You can add an SSO principal you control to a privileged SSO group to inherit its assignments. See the AWS_SSO_ADD_MEMBER edge for complete abuse details.

Over the SSO plane this edge targets the Identity Center instance, its Permission Sets, and its SSO groups. It is not drawn to individual SSO users, which are endpoints rather than pivots.

Because the grant is not limited to IAM, the same identity can also act directly in every other service, including S3, EC2, STS, Lambda, and Organizations. Those paths fall outside this edge, but they are open all the same.

Mitigation

1. Do not grant Action: "*" in IAM policy statements. Scope actions to the specific services and operations each principal needs.

2. Apply permission boundaries to IAM users and roles to cap effective permissions even when policies are overly broad.

3. Use Service Control Policies (SCPs) at the Organizations level to deny * for non-administrative accounts.

4. Enable AWS IAM Access Analyzer to surface policies that grant wildcard actions.

5. Periodically audit IAM policies attached to users, roles, and groups for wildcard action patterns.

Detection

Monitor these CloudTrail events to catch exploitation of full control:

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

Alert when the caller is not a known automation role or break-glass account. Because Action: "*" covers non-IAM services too, also watch for high-risk events elsewhere, such as s3:PutObject, ec2:RunInstances, and sts:AssumeRole.

References

• AWS IAM Actions Reference

• AWS IAM Privilege Escalation - Rhino Security Labs

• AWS IAM Permission Boundaries

• AWS Service Control Policies

• CloudTrail Event Reference - IAM