Attacking and Defending IAM Identity Center: Permission Sets, Persistence, and Detection

IAM Identity Center is the front door to most multi-account AWS estates. It federates a workforce directory to every account in the organization and brokers short-lived role sessions through permission sets. That makes it one of the highest-value targets in the environment: an attacker who controls the identity source, a delegated administrator, or the Identity Center instance itself does not need to touch a single IAM user or access key to land administrative sessions across the entire organization. This article walks the mapping model, the blast radius when it is subverted, the persistence techniques that survive a password reset, the session and MFA hardening that shrinks the window, and the exact CloudTrail events from sso.amazonaws.com and sso-directory.amazonaws.com you should be alerting on.

How Identity Center maps users to accounts

Three objects compose every access grant. A permission set is a template that materializes as an IAM role (named AWSReservedSSO_<name>_<suffix>) in each target account, carrying managed policies, inline policy, an optional permissions boundary, and a session duration. A principal is a user or group in the identity store, sourced from the Identity Center directory, an external SAML/SCIM IdP, or AWS Managed Microsoft AD. An account assignment binds a principal to a permission set in a specific account. When a user authenticates to the access portal, Identity Center provisions the role if needed and hands back temporary STS credentials for the AWSReservedSSO role in each account they are entitled to. Access is therefore the product of who is in a group, what the group is assigned, and how long the resulting session lasts. Compromise any one of those three and you have changed who can do what, everywhere. The trust chain only goes as deep as its weakest link, and the blast radius is the whole organization. If the external IdP feeding Identity Center over SAML or SCIM is compromised, the attacker controls authentication outright: they can mint assertions for a privileged user, or use the SCIM provisioning token to push a new user into a group already assigned an administrative permission set, and Identity Center will faithfully federate them. No CreateAccountAssignment ever appears in the victim's CloudTrail because the grouping happened upstream in the IdP. Delegated administration is the second blast door: a member account designated as the Identity Center delegated admin can manage permission sets and assignments for the entire organization, with the sole exception of the management account itself. A foothold in that one delegated account is functionally a foothold in organization-wide access management.

Key takeaway: in a federated setup the real identity perimeter is your IdP and your SCIM token, not AWS. The org trail shows the federated login and the role assumption, but the act of granting access can happen entirely in the IdP where AWS has no visibility. Monitor both planes, and treat the SCIM provisioning token like a root credential.

Persistence techniques an operator leaves behind

• Create a new permission set with an innocuous name and attach AdministratorAccess (or a custom inline policy with iam:* and sso:*), then provision it so the AWSReservedSSO role lands in target accounts.
• Add an account assignment binding an attacker-controlled or low-profile existing principal to that permission set in production and in the security tooling account.
• Inflate the permission set session duration to the PT12H maximum, so a single portal login yields 12-hour credentials instead of one hour, widening the gap between detection and expiry.
• Assign the admin permission set to a large group rather than a single user, so the grant is harder to spot in per-user access reviews.
• Where the directory is the Identity Center store, create a user or group via sso-directory and add it to an already-privileged group, decoupling persistence from the IdP entirely.

Hardening: MFA, session duration, and least privilege

Prevention shrinks both the entry and the dwell time. Enforce phishing-resistant MFA: set the Identity Center MFA policy to require WebAuthn/FIDO2 security keys or passkeys, disallow the email OTP fallback, and set the behavior for users without a registered device to block sign-in rather than allow-and-enroll, closing the self-enrollment hole. Drive permission-set session duration down to the lowest value the workload tolerates (one hour is the default and a sane ceiling for human access; reserve longer durations for narrow, justified cases). Scope permission sets with inline policies and permissions boundaries instead of blanket AdministratorAccess, and put a Service Control Policy in front of the AWSReservedSSO role-naming pattern so even a granted admin set cannot touch specific guardrails. Restrict who can be a delegated administrator, and never delegate Identity Center management into an account with a wide blast radius or weak controls.

Detection: the audit events that matter

Identity Center emits to two CloudTrail sources. sso.amazonaws.com carries the sso-admin management plane: CreatePermissionSet, PutInlinePolicyToPermissionSet, AttachManagedPolicyToPermissionSet, UpdatePermissionSet (session-duration changes live here), ProvisionPermissionSet, CreateAccountAssignment, and DeleteAccountAssignment. sso-directory.amazonaws.com carries identity-store changes: CreateUser, CreateGroup, AddMemberToGroup, and UpdateUser. The highest-signal alerts are an AttachManagedPolicyToPermissionSet referencing AdministratorAccess, any CreateAccountAssignment targeting a sensitive account, an UpdatePermissionSet that raises sessionDuration toward PT12H, and AddMemberToGroup against a known-privileged group. Run the query org-wide from the management or delegated-admin account, since that is where these events surface, and alert on anything whose actor is outside your small allow-list of identity administrators. Wire the same conditions into an EventBridge rule that snapshots the permission set, diffs it against the last known-good provisioned version, and pages when the actor is off the allow-list.

-- Athena over the organization CloudTrail trail: high-signal Identity Center changes
SELECT eventtime,
       eventname,
       useridentity.arn        AS actor,
       sourceipaddress,
       json_extract_scalar(requestparameters, '$.managedPolicyArn')  AS managed_policy,
       json_extract_scalar(requestparameters, '$.sessionDuration')   AS session_duration,
       json_extract_scalar(requestparameters, '$.targetId')          AS target_account,
       json_extract_scalar(requestparameters, '$.permissionSetArn')  AS permission_set
FROM cloudtrail_logs
WHERE eventsource IN ('sso.amazonaws.com', 'sso-directory.amazonaws.com')
  AND eventtime > to_iso8601(current_timestamp - interval '14' day)
  AND (
        eventname IN (
          'CreatePermissionSet', 'ProvisionPermissionSet', 'UpdatePermissionSet',
          'PutInlinePolicyToPermissionSet', 'CreateAccountAssignment', 'DeleteAccountAssignment',
          'CreateUser', 'CreateGroup', 'AddMemberToGroup'
        )
        OR (eventname = 'AttachManagedPolicyToPermissionSet'
            AND json_extract_scalar(requestparameters, '$.managedPolicyArn') LIKE '%AdministratorAccess%')
        OR (eventname = 'UpdatePermissionSet'
            AND json_extract_scalar(requestparameters, '$.sessionDuration') IN ('PT8H', 'PT12H'))
      )
ORDER BY eventtime DESC;

Containment differs from ordinary IAM because AWSReservedSSO roles look like normal IAM roles once assumed and revoking the user is not enough. An AssumedRole session for an AWSReservedSSO role created or assigned within the last hour by a non-administrator is itself a strong incident signal. Delete the rogue assignment, remove the principal from the privileged group (and rotate the SCIM token for an IdP-sourced compromise), then kill live sessions by attaching a deny-all or aws:TokenIssueTime-keyed revocation policy to the affected AWSReservedSSO roles. Finally, reconcile every permission set and assignment against an authoritative baseline such as Terraform state or Organizations exports, because an operator who reached the sso-admin API rarely plants just one grant.