BIPI
BIPI

AWS IAM Identity Center Attack Paths 2025: SSO Abuse, Permission Set Escalation and Cross-Account Pivoting

Cloud Security

Attackers who compromise a single IAM Identity Center session can pivot across dozens of AWS accounts in minutes. This post maps the real attack paths, shows how permission sets become escalation highways, and explains what defensive controls actually stop lateral movement.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 1, 2025 · 11 min read

#aws#iam#sso#privilege-escalation#cloud-security

AWS IAM Identity Center — formerly AWS Single Sign-On — changed how enterprises manage multi-account access. One identity provider, one place to grant access, propagation to every account in the organization. That convenience is also what makes it a high-value target. Compromise the identity plane and every account boundary collapses.

Penetration tests and red team engagements in 2025 show a consistent pattern: attackers who start with a phished AWS SSO credential or a stolen SAML assertion rarely stay in the initial account. Within 30 minutes of initial access, cross-account pivoting to production, billing, and security tooling accounts is routine. The attack surface grew significantly when organizations adopted multi-account AWS Organizations structures and delegated identity to a single hub account.

94%
of large AWS customers use IAM Identity Center as their primary access broker as of 2025
23 min
median time from initial SSO session compromise to cross-account pivot in red team exercises
61%
of permission sets in production carry more privileges than the user's documented role requires
IAM Identity Center turns a credential compromise into an organization-wide incident. The blast radius is proportional to how broadly you trusted it.

How IAM Identity Center works — and where trust lives

Identity Center stores permission sets centrally. A permission set is a collection of IAM policies. When a user authenticates, Identity Center vends short-lived credentials for each assigned account and permission set combination. The credentials are STS-issued and carry no obvious marker that they originated from SSO. CloudTrail logs them under the identity-center-assumed-role ARN pattern, but many SIEM detections do not parse that correctly.

The trust model has one central point: the identity store. If an attacker can authenticate to the identity store — whether through phishing, credential stuffing, or session token theft — they inherit every permission set assigned to that user across every account in the organization.

Attack path 1 — session token theft via SSRF

An SSRF vulnerability in a public-facing EC2 or ECS workload can retrieve the instance metadata service credentials at 169.254.169.254. If that workload runs with an IAM role that has access to Identity Center APIs, the attacker can call sso:ListAccountRoles and sts:AssumeRoleWithWebIdentity to enumerate every account the role touches. We have seen this path used to escalate from a CVSS 5.3 SSRF to full organization-wide access in a single engagement.

Attack path 2 — permission set escalation via iam:PassRole

The iam:PassRole permission inside a permission set is routinely over-granted. A developer permission set that includes iam:PassRole and ec2:RunInstances allows the holder to launch an instance with any IAM role in the account, including roles with AdministratorAccess. Enumerating passable roles requires only iam:ListRoles, which is almost universally granted to developers for debugging purposes.

  • iam:PassRole + ec2:RunInstances — launch an instance with an admin role, retrieve metadata credentials.
  • iam:PassRole + lambda:CreateFunction — attach a high-privileged execution role to a new Lambda.
  • iam:PassRole + glue:CreateJob — exfiltrate data using a Glue job running as a data-access role.
  • iam:CreateRole + iam:AttachRolePolicy — create a custom role with AdministratorAccess and assume it.

Attack path 3 — cross-account pivoting via resource-based policies

AWS resource-based policies on S3 buckets, SQS queues, KMS keys, and Lambda functions can grant access to any principal in the organization. If a permission set in one account allows the attacker to write a Lambda function, and a KMS key in the security tooling account trusts all principals in the organization, the attacker can use the Lambda in the first account to call KMS:Decrypt in the security tooling account. The pivot never touches IAM Identity Center APIs and leaves minimal CloudTrail signal unless you are specifically looking for cross-account kms:Decrypt calls.

What defenders get wrong

  1. Not alerting on sso-directory:DescribeUser and sso:ListAccountRoles from unexpected source IPs.
  2. Treating Identity Center CloudTrail events as lower priority than IAM events.
  3. Assigning broad permission sets to the management account, which has implicit trust across the org.
  4. Not using permission set boundaries — Service Control Policies on the management account are the only guardrail.
  5. Ignoring the sso-oauth:CreateTokenWithIAM API, which can mint tokens without user interaction.

Defensive controls that actually work

The most impactful control is splitting the management account from every workload account and restricting Identity Center administration to a break-glass role that requires MFA and logs to an immutable CloudTrail bucket. No developer permission set should ever touch the management account.

Second, audit permission sets quarterly. The principle of least privilege erodes over time. A permission set that was appropriate for a migration project in 2023 is now an over-privileged standing entitlement. Use AWS Access Analyzer's IAM findings to surface unused actions within the last 90 days and remove them.

Permission set hygiene checklist

  • No permission set contains iam:* without a permissions boundary.
  • No permission set is assigned to the management account except break-glass roles.
  • All permission set assignments are reviewed in access certification cycles, not just user access reviews.
  • CloudTrail data events enabled for sso-directory API calls.
  • SIEM alert for cross-account role assumptions chaining more than two hops within 10 minutes.

Closing

IAM Identity Center is the right architecture for multi-account AWS. The problem is not the product — it is that its centralization of trust demands centralization of controls that many organizations have not implemented. Map your permission set assignments, audit passable roles, enable the right CloudTrail event categories, and treat the identity store as a Tier-0 asset. The blast radius of a compromise is a policy choice, not a fate.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.