feat(attack-paths): Add 4 IAM privilege escalation detection queries - #11460
Conversation
|
✅ No Conflicts No conflict markers, and the branch merges cleanly into its base. |
…d graph schema Rewrite the IAM/STS/SSO privilege-escalation queries so they run correctly on the Cartography graph and on both Neo4j and Neptune sinks: - Traverse HAS_ACTION/HAS_RESOURCE child item nodes instead of reading stmt.action/stmt.resource, which are normalized off the statement node at sync - Replace any()/=~ (unsupported on Neptune) with size([...]) > 0 and CONTAINS - Type the finding probe (:HAS_FINDING) and filter ProwlerFinding on status only (the node carries no provider_uid), and restore the paths/dpf/dpfr RETURN contract - Drop four queries that duplicate existing catalog coverage (EC2-001, IAM-001, LAMBDA-001, and UpdateAssumeRolePolicy/IAM-012) - Keep the four genuinely new paths with correct reference IDs: STS-002 (cross-account trust), STS-003 (wildcard trust), IAM-022 (user permissions- boundary removal), and SSO-001 (permission-set escalation) - Rewrite the structural tests to assert these conventions Verified against the dev graph: all four execute and match the expected resources.
📝 WalkthroughWalkthroughAdds four AWS privilege-escalation attack-path queries for STS trust, IAM permissions-boundary deletion, and Identity Center permission-set escalation. Registers and documents them, with structural and Cypher compatibility tests. ChangesAWS attack-path query expansion
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Hi @paramanandmallik — thanks a lot for this, and for digging into the pathfinding.cloud paths! 🙏 Heads-up on a few things I pushed a fix commit for:
I tested all four against a real dev graph and they return the expected resources. Really appreciate the contribution — this got us solid new coverage. 🚀 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/src/backend/api/tests/test_attack_paths_queries.py`:
- Around line 141-144: Fix the assertion in the query validation test so the
searched needle and query text use the same whitespace normalization. Preserve
the intended check that no query filters the finding node on the non-existent
provider_uid property, and keep the existing query.id failure context.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 9af5d84d-70f2-4a29-ae6a-89fb2a50c58d
📒 Files selected for processing (2)
api/src/backend/api/attack_paths/queries/aws.pyapi/src/backend/api/tests/test_attack_paths_queries.py
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/src/backend/api/attack_paths/queries/aws.py`:
- Around line 3617-3618: Update the IAM action predicates in the affected
attack-path queries to match Neptune-compatible glob patterns, supporting exact
actions, service-wide patterns such as iam:*, and partial * or ? wildcards in
action names. Avoid any() and =~, and apply the same matcher consistently to the
logic around the existing act.value filters.
- Around line 3615-3618: Update the IAM-022 query to model an actual
self-boundary removal: require the authorized principal to be the targeted AWS
user, ensure a permissions boundary is attached to that user, and match the
policy statement resource to the same user. Exclude roles, unrelated users, and
statements lacking a concrete boundary-removal target while preserving valid
wildcard action handling.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: cf446600-daf5-452f-ae49-ddbaf6b5b220
📒 Files selected for processing (2)
api/changelog.d/attack-paths-pathfinding-privesc-queries.added.mdapi/src/backend/api/attack_paths/queries/aws.py
…t order The provider_uid finding-probe assertion stripped spaces from the query text but kept a space in the needle, so it could never match. Remove the space so the check actually catches a provider_uid filter on the finding node. Also sort the import block to satisfy ruff (I001).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@api/src/backend/api/tests/test_attack_paths_queries.py`:
- Around line 140-143: Update the assertion in the query test to use a
whitespace-tolerant regular expression that matches provider_uid only within the
ProwlerFinding node pattern. Replace the space-only normalization and global
substring check, preserving the test’s intent to reject provider_uid filtering
on findings while allowing the property on unrelated nodes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: f75bcdd9-bafa-49b3-bcf3-b9804ca0b3f8
📒 Files selected for processing (1)
api/src/backend/api/tests/test_attack_paths_queries.py
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #11460 +/- ##
==========================================
+ Coverage 94.37% 94.51% +0.14%
==========================================
Files 268 270 +2
Lines 41109 41885 +776
==========================================
+ Hits 38796 39588 +792
+ Misses 2313 2297 -16
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
6e9db59
Changes made
|
Resolve the aws.py Attack Paths conflict by keeping the union of all queries (the 20 pathfinding privesc queries from this PR plus STS-002/003, IAM-022 and SSO-001 merged from #11460) and re-sorting the whole pathfinding privesc section and the AWS_QUERIES list by service then number, so the previously appended queries land in their correct ordered positions (e.g. IAM-022/023 after IAM-021, SSO-* between SSM and STS).
…privesc queries Apply the same resource-scoping used for their IAM-022/SSO-001 siblings (#11460): - IAM-023: require the iam:DeleteRolePermissionsBoundary statement resource to cover the assumable target role's ARN (not just that the action exists), and note in the description that boundary attachment is not recorded in the graph. - SSO-002/003: require the sso action on a wildcard resource, since permission sets are not graph nodes and cannot otherwise be scoped to the actor.
Context
Adds 8 openCypher queries that detect IAM privilege escalation patterns in AWS environments. These queries analyze Cartography-ingested graph data to identify principals with dangerous permission combinations that enable lateral movement and privilege escalation.
What's Included
aws-iam-privesc-cross-account-no-external-idaws-iam-privesc-wildcard-trustPrincipal: "*"→ universal accessaws-iam-privesc-update-trust-self-assumeaws-iam-privesc-passrole-lambdaaws-iam-privesc-passrole-ec2aws-iam-privesc-create-policy-version-self-escalationaws-iam-privesc-boundary-removalaws-sso-privesc-permission-set-escalationResearch Source
All queries are based on documented attack paths from pathfinding.cloud PR #29. Each query's
attributionfield links directly to the corresponding documented path.Compatibility
$provider_uidfor account scoping and include the Prowler findings joinWhat Was Tested
test_attack_paths_queries.py)Checklist
$provider_uidfor account scopingAWS_QUERIESlistSummary by CodeRabbit