Module 6 · Cross-Account Attacks in AWS 🔒

Multi-account AWS (or multi-subscription Azure / multi-project GCP) is the norm. Production in one account, staging in another, security tooling in a third, sometimes dozens of accounts across business units. Each cross-account boundary is a potential attack surface — and when misconfigured, a path from one compromised account to many.

Why multi-account

• Blast-radius limitation — a compromised prod account shouldn’t affect staging
• Compliance — isolate regulated workloads
• Billing separation by team/product
• Quota isolation
• Principle of least privilege across teams

Cross-account trust — the sharp edges

Over-broad trust policies

Classic mistake:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999999999999:root"},
  "Action": "sts:AssumeRole"
}

“:root” in trust policy means “any principal in account 999 with AssumeRole permission can assume this role.” You’ve delegated trust to the entire other account — including any compromised user or service there.

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::THIRD-PARTY-ACCOUNT:root"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {"sts:ExternalId": "UNIQUE_PER_CUSTOMER_SECRET"}
  }
}