Module 6 · Cross-Account Attacks in AWS

Last updated: April 29, 2026

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.

Fix: specify exact principals (arn:aws:iam::999:role/ci-pipeline-role), add conditions (source IP, MFA, external ID).

Missing External ID

External ID is a shared secret between accounts used to prevent the “confused deputy” problem. Commonly required by third-party SaaS integrations (Datadog, Splunk, security vendors).

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

Without External ID, if attacker compromises the third-party account they can assume your role without knowing the secret. With External ID, attacker must also know the unique string.

Over-permissive role permissions

Cross-account role with AdministratorAccess = gives the other account full control of yours. Scope cross-account roles tightly: specific actions on specific resources.

AWS Organizations / SCPs — the ceiling

Service Control Policies (SCPs) at the organisation level cap maximum permissions across ALL accounts. Even if an account admin grants broader IAM, SCP denies at the root.

Typical SCP guardrails:

• Deny leaving the organisation
• Deny disabling CloudTrail, GuardDuty, Config
• Deny region-egress (block unused regions)
• Deny access-key creation for IAM users (enforce SSO federation)
• Require MFA for sensitive actions

Attack paths between accounts

1. Over-broad AssumeRole — root-trusting role, attacker in compromised upstream assumes
2. Shared resources — S3 bucket policy “Principal: *”, EBS snapshot shared publicly, RAM-shared resources to wrong account
3. VPC peering misconfig — routes accepted from compromised VPC
4. KMS key policy over-broad — other account can decrypt sensitive data
5. Lambda function invocation permissions — other account can invoke your Lambda with arbitrary payload
6. Account enumeration — misconfigured CloudFront, ALB, Route 53 reveals internal account IDs

Detection

• IAM Access Analyzer — AWS-native; surfaces resources shared outside the zone of trust (external to your org)
• CloudTrail organisation trail — central logging of all account API calls
• AWS Config aggregator — central configuration compliance view
• GuardDuty central delegated admin — managed threat detection across all accounts
• Security Hub — aggregate findings from all accounts

Account structure best practices

• Landing Zone / Control Tower — AWS-managed multi-account baseline
• Dedicated accounts: security (audit, logs), shared services (DNS, networking), each environment (prod, staging, dev) per team
• SCPs at OU level encoding compliance requirements
• Centralised logging — CloudTrail + VPC Flow + Config all to a dedicated security account with Object Lock
• Periodic review — audit cross-account trusts, shared resources, IAM Access Analyzer findings

Quick reference summary

• Cross-account trust misconfig = classic path from one compromise to many
• Avoid :root in Principal; specify exact role/user ARN
• Use External ID for third-party integrations
• SCPs at organisation level cap maximum permissions
• IAM Access Analyzer surfaces external-access resources
• CloudTrail org trail + Security Hub + GuardDuty central admin for visibility
• Landing Zone / Control Tower for baseline