Lion Cipher Lab
Exploit the AWS cross-account confused deputy — then close it with an ExternalId
- Cloud Security
- Advanced
- ~75 min
- Free · no account required
Why it matters
Nearly every SaaS security or cloud-cost vendor you integrate ('give us a cross-account role and we'll scan your account') relies on cross-account AssumeRole. Get the trust policy wrong — omit the ExternalId — and you have handed a capability to a shared 'deputy' that any of the vendor's other tenants, or anyone who learns your role ARN and the vendor's account id, can aim at your account. It is one of the oldest and most repeated cloud misconfigurations, AWS built an entire condition key specifically to prevent it, and reviewers still miss it. Doing the attack once makes the fix…
What you'll learn
- the confused-deputy trust model: why a role that trusts a third-party vendor account is exploitable without an ExternalId
- standing up a multi-account AWS simulation locally with LocalStack (no real cloud, no cost)
- writing a cross-account AssumeRole trust policy and reproducing the vulnerable version
- assuming a victim role across accounts as the 'wrong' customer to prove the escalation
- adding the sts:ExternalId condition and proving the same AssumeRole is now denied
- why ExternalId (not the vendor account id alone) is the control, and where it must be enforced
Steps in this lab
- The confused deputy in one picture
- Start a local multi-account AWS with LocalStack
- Create the victim role with the VULNERABLE trust policy
- Exploit: the deputy assumes the victim role for the attacker
- Fix: require an ExternalId in the trust policy
- Re-prove: wrong / missing ExternalId is denied, correct one works
- What to remember — and the named failure modes
- Tear down