Cross-Account Trust Abuse

Description

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.

Examples

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"]}}'

Remediation

  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.