Use Case: Cloud
Shared IAM role abuse
An AWS role with a wildcard trust policy was assumed from an external account that had no legitimate reason to access your environment. ManySignal mapped the assumption chain and alerted in 90 seconds.
When trust policies become attack paths
AWS IAM role trust policies define who can assume a role. Misconfigured trust policies — using wildcard conditions, overly broad principal specifications, or failing to include ExternalId conditions for third-party access — create lateral movement paths that attackers can exploit. An attacker who compromises any AWS account that matches an overly broad trust condition can assume the target role without any credential theft from the target account.
rule: cross_account_role_abuse
type: behavioral + trust_policy_analysis
sources:
- aws_cloudtrail (AssumeRole, AssumeRoleWithSAML)
trigger:
- condition: |
role_assumption.source_account NOT IN expected_trust_principals
OR role_assumption.source_account NOT IN historical_assumers(90d)
AND NOT sts.ExternalId validated
enrichments:
- trust_policy_analysis: wildcard_conditions, missing_externalid
- assumption_chain: source_account_history
- post_assumption_calls: api_calls_15m
- org_structure: aws_organizations_map
mitre: T1078.004 (Valid Accounts: Cloud Accounts), T1199 (Trusted Relationship)MITRE ATT&CK mapping
Shared role abuse FAQ
What makes cross-account role assumption suspicious?
Legitimate cross-account role use correlates with known deployment pipelines, specific business workflows, and consistent source account patterns. Suspicious use involves: an account that has never assumed this role before, an unusual source account (non-pipeline, non-jump-account), external trust relationships being used from new IPs, or role assumption immediately followed by data discovery API calls.
Does ManySignal detect confusion attacks in AWS cross-account trust?
Yes. The confused deputy problem arises when a resource-based policy uses overly broad account conditions. ManySignal checks cross-account role assumptions against the expected principal conditions in the trust policy and flags any assumption from a principal not explicitly authorized, even if the IAM policy technically allows it.
How does ManySignal handle legitimate multi-account AWS Organizations setups?
ManySignal maps the AWS Organization structure and correlates role assumption events with expected cross-account workflows. Deployments that use a central security account to assume roles in member accounts, or a CI/CD account assuming deployment roles, are whitelisted based on the source account and role naming pattern.
Can this detect attacks that chain multiple role assumptions?
Yes. ManySignal tracks role assumption chains — principal A assumes role B, which then assumes role C. Unusual chain lengths or chains that traverse trust boundaries not seen in historical data are flagged. The entity graph shows the full assumption chain for the analyst's review.
Monitor every cross-account role assumption for unauthorized use
Trust policy analysis with real-time assumption chain tracking across AWS Organizations.