Borrowing a more powerful identity (GCP impersonation)
In GCP, the right to impersonate a service account is the right to become it. One serviceAccountTokenCreator binding can chain a low-privilege identity up to a powerful one. Here is the path, and the fix.
In GCP you rarely escalate by gaining a permission. You escalate by borrowing an identity that already has it.
What it is
GCP lets a principal with roles/iam.serviceAccountTokenCreator on a service account generate access tokens for it, effectively becoming that account. An attacker who holds (or can grant themselves) this on a more privileged service account impersonates it, and if that account can in turn impersonate others, chains the impersonation up to project or organization rights. This is T1078 (valid accounts) with T1548 (abuse elevation control mechanism).
Why it works
Impersonation is a legitimate feature, the binding is easy to grant too broadly, and a chain of token-creator bindings is rarely mapped. The tokens are short-lived, but the access is real.
How to detect it
In Cloud Audit Logs, look for GenerateAccessToken or impersonation by a principal that does not normally do it, and chains of impersonation pointing toward privileged accounts.
The fix that holds
Audit and minimize serviceAccountTokenCreator grants, separate sensitive service accounts, alert on unexpected impersonation, and map the impersonation graph so a chain to organization admin cannot hide.
Practice it
We built a service-account impersonation scenario in GraphLattice Range so teams learn to trace the chain and cut the bindings that enable it.