Most AWS security teams know that IAM is the centre of gravity for cloud security. Fewer teams systematically test what an attacker can reach by chaining role assumptions across the account. Role chaining is a legitimate and useful AWS feature. It is also one of the most powerful tools available to an attacker who gains a foothold, because the chain can move them from a low privileged starting position to the credentials they actually want.
How The Chain Actually Forms
A user holds permission to assume a role. The role has permission to assume another role. The other role can assume a third role in a different account. None of these individual relationships looks dangerous in isolation. Followed end to end, the chain can carry a compromised credential across account boundaries and into permissions that the original principal was never supposed to hold. A capable AWS pen testing engagement should explicitly map the role chain graph and surface paths that the access reviews missed.
External Identifiers Are Often Misused
The external identifier feature in role trust policies is meant to prevent the confused deputy problem. In practice it gets set to predictable values, shared across multiple integrations or left empty altogether. An external identifier that anyone can guess provides no protection. Treat the external identifier as a shared secret, generate it from a strong random source and rotate it when the integration changes.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
The most uncomfortable role chain I have followed during an assessment went from a developer with permissions on a single CI/CD account through three role assumptions to administrator in the production account. Each step was justified by a real business need. Nobody had asked what the chain looked like end to end.
External Access Deserves Particular Scrutiny
Cross account trust relationships involving external partners deserve particular scrutiny. A role that any AWS account principal can assume, with an unenforced external identifier, is effectively public. Treat external account access as a regulated privilege. Document each trust relationship, review them periodically and remove the ones that no longer have a current purpose. Worth treating external accounts as a separate risk category in the access management programme. The default reviews focused on internal users miss patterns that only emerge when external relationships are considered specifically.
Tooling Helps But Does Not Solve The Problem
Tools that visualise IAM relationships have improved significantly. Use them to surface candidate chains rather than to make a final judgement. The interesting question is not whether a path exists technically but whether the path has a legitimate purpose. Pair the tooling with a best pen testing company that exercises the chains and reports the ones that produce meaningful privilege escalation. The combination is far more useful than either approach alone.
IAM is the perimeter in the cloud. Map your chains as if your business depended on it, because it does. Role chaining is invisible until somebody maps it. Map it deliberately and the surprises stop being surprises. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.
