Escalate GCP privileges with Implicit Delegation

What this lab covers

You establish your effective permissions, identify service accounts you can act through, and chain delegation to reach an identity with meaningfully more access than the one you started with.

The lab isolates delegation specifically, which is worth doing because it is the least intuitive part of Google Cloud IAM. Most people can reason about direct impersonation and stop there.

It assumes no prior GCP experience. Along the way it covers serverless functions and their storage, which are common holders of the permissions that make chains possible.

How implicit delegation works

Google Cloud allows an identity to request credentials for a service account it holds token creation rights over. Implicit delegation extends this by permitting a chain, where the request is made through one or more intermediate service accounts rather than directly.

The practical consequence is reach. If you can act as account A, and A can act as B, delegation allows you to obtain credentials for B without holding any permission on B yourself. The binding that matters is on the intermediate identity, not on the target.

This exists for legitimate architectural reasons, allowing services to act on behalf of one another without each caller needing explicit grants everywhere. It also means the effective permission graph is considerably larger than the set of direct bindings suggests, and larger than any per-binding review will reveal.

How to detect this in your own environment

Cloud Audit Logs record token generation, including the delegation chain used. That detail is the most useful evidence available here, because it shows the path rather than just the destination.

Baseline which chains occur legitimately. Applications delegate along fixed routes, so a new chain appearing, or a human identity initiating one, is worth investigating.

Watch for permission enumeration immediately beforehand. Chains are discovered rather than known, so reconnaissance across service accounts typically precedes the escalation and offers an earlier signal.

How to prevent it

Audit the graph, not the bindings. Ask which identities can reach your most privileged service accounts through any number of delegation hops, since that is what an attacker computes and what a binding-by-binding review will not show.

Grant token creation rights sparingly and treat them as administrative. They do not look like access grants and they are equivalent to being the target identity.

Apply IAM conditions to bound impersonation where possible, and prefer architectures where services authenticate to each other with narrowly scoped identities rather than through long delegation chains.

Real-world context

Delegation and impersonation are the primary privilege escalation mechanisms in Google Cloud and appear in every published catalog of GCP escalation paths. They are features rather than flaws, which is why they persist.

The organizational cause is familiar. Permissions are granted to make a deployment work, ownership of the resulting bindings is unclear, and nobody recomputes the graph afterwards. An environment with carefully controlled owner assignments can still have several routes to owner-equivalent access.

The pattern maps to MITRE ATT&CK T1548 Abuse Elevation Control Mechanism, T1078.004 Cloud Accounts and T1550.001 Application Access Token.

Applying this at work

• Enumerate every identity holding token creation roles and compute the chains they enable, rather than listing bindings.
• Identify your most privileged service accounts and determine what can reach them in any number of hops.
• Alert on delegation chains that have not been seen before, and on human identities initiating them.
• Apply IAM conditions to constrain impersonation by resource and context.
• Review service accounts attached to serverless functions, which frequently hold more than the function requires.

Frequently asked questions

What is implicit delegation in Google Cloud?

A mechanism allowing a request for credentials to pass through one or more intermediate service accounts. It means an identity can obtain credentials for a target it holds no direct permission on, provided a chain exists.

Why is this harder to audit than direct impersonation?

Because the permission that enables the hop sits on the intermediate identity rather than the target. Reviewing who can impersonate a sensitive account directly will not reveal a path that arrives through two other accounts.

Is delegation recorded in audit logs?

Yes. Cloud Audit Logs record token generation including the delegation chain, which is the most useful evidence available, since it shows the route taken rather than only the identity reached.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.