Haxoris Wiki

Cross-Account Trust Abuse

How Cross-Account Trust Abuse works

Overly permissive role trust policies allow external principals to assume roles in your account, including third‑party vendors or unknown accounts. Absence of sts:ExternalId, missing aws:PrincipalOrgID, lack of MFA/session constraints, and wildcard principals make unintended access likely. Attackers who compromise a partner then pivot into your account via weak trusts.

Cross-Account Trust Abuse in practice

Review Trust Policies

aws iam get-role --role-name <role> --query 'Role.AssumeRolePolicyDocument'

Look for Principal: {AWS: "*"} or broad external ARNs without Condition.

Attempt Cross-Account AssumeRole

aws sts assume-role --role-arn arn:aws:iam::<acct>:role/<role> --role-session-name ext --profile <external>

If assumption succeeds unexpectedly, trust is too broad.

Enumerate and validate at scale

aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument!=null].[RoleName,AssumeRolePolicyDocument]'
aws accessanalyzer list-findings --analyzer-name <org-or-account-analyzer> \
  --filter '{"isPublic":{"eq":["true"]}}'

How to fix and prevent Cross-Account Trust Abuse

  1. Restrict Principal to specific account IDs and, where applicable, require sts:ExternalId.
  2. Add conditions (aws:PrincipalOrgID, aws:SourceArn/aws:SourceAccount for service roles, IP/VPC conditions) and use SCPs to block risky trusts; require MFA via aws:MultiFactorAuthPresent for human users.
  3. Monitor CloudTrail for unexpected AssumeRole from external accounts; limit sts:DurationSeconds; use permission boundaries on roles that can modify trusts.

Last updated

References