GCP Pentesting

Google Cloud Platform organizes everything around projects and uses service accounts (SA) as the identities of applications. Escalation in GCP almost always revolves around impersonating service accounts: with the right permissions you can obtain tokens of more privileged SAs and chain up to Owner of the project or organization. Understanding SAs, roles, and the hierarchy (organization → folder → project → resource) is the key.

Hierarchy and identities

Organization -> Folders -> Projects -> Resources
# identities
Users (Google), Groups, Service Accounts (SA: identity of apps/VMs)
# roles: primitive (Owner/Editor/Viewer), predefined, custom
# permissions are inherited downward in the hierarchy

Credentials and access

# ways in
gcloud auth login                    # user
gcloud auth activate-service-account --key-file=sa.json   # SA (leaked JSON = access)
# SA tokens from a VM (see cloud-metadata)
# a leaked service account JSON (recon-code) is direct access

Enumeration

gcloud auth list ; gcloud config list
gcloud projects list ; gcloud projects get-iam-policy <proj>
gcloud iam service-accounts list
gcloud <service> ... list            # resources by service
# tools
gcp_scanner, GCPBucketBrute, Hayat, ScoutSuite (supports GCP)

The heart: service account impersonation

# if you have iam.serviceAccounts.getAccessToken over an SA -> get its token
gcloud auth print-access-token --impersonate-service-account=<SA>@<proj>.iam.gserviceaccount.com
# iam.serviceAccounts.actAs + create a resource (function/VM/job) running as that SA
# iam.serviceAccountKeys.create -> create a key for an SA (persistence/access)
gcloud iam service-accounts keys create k.json --iam-account=<SA>

If the target SA is more privileged (Editor/Owner), you impersonate it and escalate.

Typical escalation permissions

resourcemanager.projects.setIamPolicy   -> grant yourself project Owner
iam.serviceAccounts.getAccessToken/actAs -> impersonate a privileged SA
iam.serviceAccountKeys.create            -> SA key (persistent access)
# via services: deploymentmanager, cloudfunctions/run/compute with a privileged SA
cloudfunctions.functions.create + actAs  -> function as an admin SA (cloud-serverless)

Common services

# Cloud Storage (see cloud-s3)
gsutil ls ; gsutil ls gs://<bucket>   # public/readable buckets
# Compute Engine
gcloud compute instances list ; project metadata (SSH keys, startup scripts)
gcloud compute project-info describe   # sometimes credentials in metadata
# Secret Manager
gcloud secrets list ; gcloud secrets versions access latest --secret=X
# Cloud Functions / Cloud Run (cloud-serverless)

For the defense

Least privilege: avoid broad primitive roles (Owner/Editor); scoped predefined roles.
Control impersonation: restrict iam.serviceAccounts.getAccessToken/actAs; disable SA key creation (iam.disableServiceAccountKeyCreation).
SAs without static keys: use Workload Identity; don’t expose service account JSON.
Organization Policies to restrict (domain restriction, no SA keys, no public IPs).
Cloud Audit Logs (Admin Activity + Data Access) + Security Command Center; alerts on setIamPolicy/keys.create.

Testing checklist

Access (user / SA JSON / VM token) and enumeration (gcloud)
Project and SA IAM policy (inherited roles)
Impersonate SAs (getAccessToken/actAs) toward more privilege
serviceAccountKeys.create (access/persistence)
setIamPolicy → project Owner
Public GCS buckets (Buckets and Public Storage), Compute metadata (keys)
Secret Manager and functions with a privileged SA
Map up to project/organization Owner