Skip to content

Add 11 IAM privilege escalation paths: cross-account trust, boundary bypass, Identity Center, deny removal#29

Open
paramanandmallik wants to merge 1 commit into
DataDog:mainfrom
paramanandmallik:add-cross-account-trust-boundary-sso-deny-paths
Open

Add 11 IAM privilege escalation paths: cross-account trust, boundary bypass, Identity Center, deny removal#29
paramanandmallik wants to merge 1 commit into
DataDog:mainfrom
paramanandmallik:add-cross-account-trust-boundary-sso-deny-paths

Conversation

@paramanandmallik

Copy link
Copy Markdown

This PR adds 11 new privilege escalation paths spanning four categories that are currently unrepresented or underrepresented in the library.

The existing pathfinding.cloud collection covers same-account AssumeRole and various PassRole combinations well, but has gaps in cross-account trust abuse scenarios. This contribution adds three STS paths documenting how roles can be compromised when trust policies lack ExternalId conditions, use wildcard principals, or when an attacker can rewrite trust policies via iam:UpdateAssumeRolePolicy to inject self-trust. These are among the most common real-world misconfigurations found in multi-account AWS environments.

The library also had no coverage of permissions boundary bypass techniques. The three new IAM paths (iam-022 through iam-024) document how boundaries can be deleted or replaced with permissive policies, restoring the full unconstrained permissions of a principal whose policies were always broader than the boundary allowed. These are particularly relevant because many organizations rely on boundaries as their primary privilege containment mechanism.

Identity Center (SSO) escalation is an entirely new category for the library. The three sso-admin paths document how attackers with SSO management permissions can create new admin permission sets, attach AdministratorAccess to existing permission sets, or inject inline admin policies — gaining organizational-wide access through the SSO portal.

Finally, two paths document deny policy removal as an escalation vector. When organizations use attached deny policies as guardrails rather than SCPs, an attacker with DetachUserPolicy or DeleteUserPolicy can remove those guardrails and re-enable previously-blocked escalation paths.

All 11 files pass validate-schema.py and include full exploitation steps (awscli), attack visualizations with conditional branching, actionable remediation guidance with SCP examples, and proper discovery attribution.

…missions boundary bypass, Identity Center escalation, deny policy removal
@sethsec

sethsec commented Jun 3, 2026

Copy link
Copy Markdown
Collaborator

Thanks for this contribution @paramanandmallik. I will review! Adding the paths that encompass permissions boundary bypasses was def on my to-do list, so thanks for getting that part started!

@paramanandmallik

Copy link
Copy Markdown
Author

Thanks for the quick response.
Happy to contribute and help move this forward. I’m glad the permissions boundary bypass paths were useful. Looking forward to your review and any feedback you may have.

@paramanandmallik

Copy link
Copy Markdown
Author

@sethsec Hi Seth, Do we have any update on this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants