KEY TAKEAWAY
An external ID is not a secret and was never designed to be one. It exists to stop a third party being tricked into using their access on the wrong customer's account, so a trust policy that relies on the external ID alone for security is relying on a control that was built for a different problem.
What this lab covers
You fuzz a web server for files that should not be reachable, find configuration that was never meant to be public, and use what it contains to assume a role with considerably more access than you started with.
The chain runs through cross-account trust, which is one of the least understood parts of AWS. Understanding what a trust policy actually asserts, and what it does not, is what makes the escalation obvious rather than surprising.
It suits anyone assessing or defending AWS environments that integrate with third-party tooling, which in practice is most of them.
How cross-account role assumption is abused
A role in AWS has two policy layers. The permissions policy says what the role can do, and the trust policy says who is allowed to assume it. Cross-account access works by naming another account as a trusted principal in the trust policy.
The external ID was added to solve the confused deputy problem. When a vendor manages many customers' accounts, an external ID ensures the vendor cannot be manipulated into using its trusted position against the wrong customer. It is a correlation value, shared with the vendor, present in configuration and support tickets.
The failure mode is treating it as a password. If a trust policy trusts a broad principal and relies on the external ID to narrow that trust, anyone who obtains the external ID and can act from a trusted account can assume the role. Exposed configuration files are a routine way for that value to escape, and web servers serving files that were never meant to be reachable is one of the oldest problems in the field.
How to detect this in your own environment
Role assumption is recorded in CloudTrail as a management event with the identity of the caller, the role assumed and the source address. Cross-account assumption by an account you do not recognize is therefore visible without any additional logging configuration.
Baseline which external accounts legitimately assume your roles. This list is normally short and stable, because it reflects contracted vendor relationships, so any new entry is worth an alert rather than a dashboard.
Watch for role sessions from unfamiliar source addresses or with unusual session names. Session names are attacker-controlled and often left at tool defaults, which makes them a useful, if soft, indicator.
How to prevent it
Trust specific principals, not whole accounts, wherever the vendor supports it. Naming the exact role that may assume yours is materially stronger than naming the account and relying on the external ID to do the narrowing.
Treat external IDs as configuration rather than credentials, and generate them as unguessable values anyway. That costs nothing and removes the case where a predictable value is derived rather than leaked.
Stop configuration files being reachable. Serving application configuration from a web root is the actual root cause here, and directory fuzzing takes seconds. Deny access to configuration file extensions at the web server and keep runtime configuration outside the served directory.
Real-world context
Exposed configuration files containing cloud credentials are a well-documented and recurring finding. A 2022 report submitted through HackerOne to the US Department of Defense described a server exposing a configuration file that contained AWS credentials, which is precisely the entry point this lab reproduces.
Cross-account trust deserves attention because it is where security ownership becomes ambiguous. The customer writes the trust policy, the vendor holds the corresponding access, and neither side reliably audits the combination. Third-party integrations accumulate over years and are rarely revisited.
The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts and T1550 Use Alternate Authentication Material.
Applying this at work
- List every role in your accounts with a trust policy naming an external account, and confirm each still corresponds to a live vendor relationship.
- Check whether those trust policies name a specific principal or an entire account, and tighten where possible.
- Scan your own web servers for reachable configuration files. Fuzzing your own estate takes minutes.
- Alert on role assumption by any external account not on your known-good list.
- Confirm external IDs in use are random values rather than derived from customer or company names.
Frequently asked questions
Is an AWS external ID a secret?
No. It is designed to prevent a vendor being confused into acting against the wrong customer, not to authenticate the caller. It appears in configuration files and support tickets, so a trust policy should not depend on it staying private.
What is the confused deputy problem?
It is where a trusted third party is manipulated into using its legitimate access on behalf of the wrong party. External IDs address it by tying each cross-account relationship to a specific correlation value.
How should cross-account trust be scoped properly?
Name the specific principal permitted to assume the role rather than the whole account, use an unguessable external ID as an additional condition, and review the list of trusted external accounts periodically.
Do I need my own AWS account to practice this?
No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.
Which certification covers this in depth?
The Amazon Cloud Red Team Professional (ACRTP) covers AWS trust relationships, IAM abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.
.png?width=58&height=36&name=azure%20(3).png){kind=small}
.png)