Skip to content

Beginner-friendly Lab red team icon   GCP

Pivot Through Service Accounts using Dangerous Permissions

Explore how to abuse dangerous IAM permissions to move laterally and escalate privileges in a GCP environment.

Overview
In this lab, you’ll simulate the compromise of a low-privilege service account and explore how to abuse dangerous IAM permissions to move laterally and escalate privileges in a GCP environment. You'll also gain an understanding of how to detect service account abuse using Cloud Logging.
Scenario

We are on a purple team engagement for Gigantic Retail and have identified a GCP service account key file in an NTFS share. Your mission is to pivot to the cloud and increase our access in GCP, and ultimately help to close down any identified attack paths.

Lab prerequisites
  • Basic knowledge of Google Cloud
  • Familiarity with the command line

Learning outcomes
  • Get situational awareness using IAM policy and the testIamPermissions method
  • Enumerate and explore resources using the gcloud and gsutil CLI
  • Abuse the dangerous implicitDelegation , generateAccessToken and signJwt permissions
  • Identify and use GCP HMAC keys to exfiltrate files from Cloud Storage
  • Detect service account abuse using Cloud Logging
  •  
Real-world context

In real-world cloud breaches, attackers rarely stop at a single compromised identity. In order to achieve their objectives they would look to exploit misconfigured IAM bindings and overly permissive service account roles. This kind of abuse can go undetected when relying solely on project-level IAM reviews, overlooking resource-level permissions that quietly expose high-impact attack paths. It helps to take a purple approach to defense, and start understanding an environment as a threat actor would, using their tradecraft.

KEY TAKEAWAY

In Google Cloud, the ability to create tokens for a service account is equivalent to being that service account. Roles like Service Account Token Creator do not appear to grant access to anything, and they grant access to everything the target identity can reach.

What this lab covers

You establish what your identity can do, enumerate the service accounts in a project, and chain token creation permissions to move from one identity to another until you reach something worth having.

The lab is about permission chains rather than any single misconfiguration. Each binding was granted for a reason, and the escalation exists in the composition, which is why reviewing bindings individually does not find it.

It is rated intermediate and suits anyone administering Google Cloud IAM. The permission names involved are worth memorising because they appear in almost every GCP escalation path.

How GCP service account impersonation works

Google Cloud separates who you are from what you can act as. An identity granted token creation permissions on a service account can request credentials for it, then operate with that account's permissions rather than its own.

Several permissions achieve this in different ways. Generating an access token yields credentials directly. Signing a JSON Web Token allows a token to be minted and exchanged. Implicit delegation permits chaining through an intermediate service account, so a path can traverse identities the attacker cannot impersonate directly.

The consequence is a graph. A user who can impersonate account A, where A can impersonate B, where B has broad project rights, effectively has broad project rights. None of the individual bindings looks like an administrative grant, and the chain is invisible when reviewing them one at a time.

How to detect this in your own environment

Log and alert on service account impersonation events. Cloud Audit Logs record token generation and identity assertion, so the impersonation itself is visible, and in most projects it is infrequent enough to review.

Baseline which identities legitimately impersonate which service accounts. Automation does this repeatedly and predictably, so a human identity impersonating a service account, or a new pairing appearing, is worth investigating.

Watch for permission enumeration ahead of it. Repeated testing of permissions across many resources is reconnaissance, and it precedes the escalation, giving you an earlier signal than the impersonation itself.

How to prevent it

Treat token creation roles as privileged administrative grants, because that is what they are. They should be reviewed with the same care as project owner, and granted to as few identities as possible.

Analyze the chain rather than the binding. Ask which identities can reach your most privileged service accounts through any number of hops, since that is the question an attacker answers and a per-binding review does not.

Prefer workload identity federation over service account keys, and avoid granting impersonation to human users where automation could hold it instead with tighter conditions.

Real-world context

Service account impersonation is the dominant privilege escalation mechanism in Google Cloud, and it appears in essentially every published catalog of GCP escalation paths. It persists because it is a legitimate and necessary feature.

The reason it goes unnoticed is that the audit trail is thin unless someone is looking for it, and the permissions have unremarkable names. An organization carefully controlling who holds owner may have several identities that can reach owner in two hops.

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

Applying this at work

  • List every identity holding Service Account Token Creator or similar token creation roles across your projects. It is usually more than expected.
  • Map impersonation chains rather than individual bindings, and check what your most privileged service accounts are reachable from.
  • Alert on service account impersonation by human identities.
  • Replace service account keys with workload identity federation wherever the workload can support it.
  • Watch for repeated permission testing across resources, which is the reconnaissance that precedes escalation.

Frequently asked questions

What does the Service Account Token Creator role actually allow?

It allows an identity to obtain credentials for the service account and act as it. In effect it grants everything that service account can do, which is why it should be treated as a privileged administrative role.

What is implicit delegation in GCP?

A mechanism allowing a request to chain through an intermediate service account. It means an escalation path can traverse identities the attacker cannot impersonate directly, which makes chains longer and harder to spot.

Is service account impersonation logged?

Yes. Cloud Audit Logs record token generation and impersonation events. The activity is legitimate, so detection depends on baselining which identities normally impersonate which accounts.

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.