BIPI
BIPI

GCP IAM Misconfiguration Exploitation and Service Account Pivoting

Cloud Security

GCP IAM has fewer high-profile breaches but a deeper trust model. This post covers service account impersonation, token creator abuse, and project pivoting.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 12, 2024 · 10 min read

#gcp#iam#pentesting#service-account#cloud

GCP IAM is structurally cleaner than AWS but operationally messier in most enterprises. The Resource Manager hierarchy of organization, folders, and projects creates inherited bindings that are easy to misjudge, and service account keys remain the most common pivot when one of them leaks.

Initial enumeration

  • gcloud projects list to discover scope of the compromised principal
  • gcloud projects get-iam-policy on every accessible project
  • GCP IAM Recommender output for sensitive roles flagged for downgrade
  • ScoutSuite or Prowler GCP for a posture baseline across services

Service account impersonation chains

The role roles/iam.serviceAccountTokenCreator lets a principal mint short-lived access tokens for a target service account. If a user can mint a token for an editor service account on another project, they have effectively crossed a trust boundary that the project owner believes is solid. This is the single most underestimated GCP escalation path.

  1. gcloud iam service-accounts get-iam-policy on every reachable service account
  2. Look for tokenCreator or serviceAccountUser granted to broader groups
  3. gcloud auth print-access-token --impersonate-service-account to mint
  4. Use the new token to enumerate that account's permissions and chain

Service account key abuse

Service account JSON keys are long-lived credentials with no built-in rotation. They land in source repos, CI environments, and developer laptops. Once you have one, gcloud auth activate-service-account with the key file and you are the service account. Audit logs see it, but only as the service account, so attribution is poor.

Compute and storage pivots

  • Compute metadata at 169.254.169.254 returns the attached service account token, same model as AWS
  • GCS buckets with allUsers or allAuthenticatedUsers IAM bindings allow public or any-Google-account read
  • Cloud Functions and Cloud Run inherit a default compute service account unless overridden
  • Cloud Build runs with a powerful default builder identity that can deploy across the project
GCP gives you tokenCreator as a feature. Attackers use it as a trampoline.

Detection

  1. Cloud Audit Logs Admin Activity capture IAM mutations and service account key creation
  2. Data Access logs are off by default for most services and worth enabling for IAM and storage
  3. Event Threat Detection catches some abuse patterns but is far less mature than GuardDuty
  4. VPC Service Controls violations indicate cross-perimeter access attempts

Remediation

  1. Ban service account key creation via the iam.disableServiceAccountKeyCreation org policy
  2. Replace long-lived keys with workload identity federation from CI providers
  3. Remove roles/editor and roles/owner from groups, replace with custom roles per workload
  4. Enable VPC Service Controls around sensitive projects to contain credential abuse
  5. Audit serviceAccountTokenCreator bindings monthly and require justification
40%
of GCP customers we audit have at least one allAuthenticatedUsers GCS binding
5x
the typical service account count versus declared identities in IaC

Closing

GCP rewards a careful reading of IAM policies and a careful reading of service account graphs. The tools are simpler than AWS but the trust model is wider, and the audit logging defaults are weaker. Start by listing every service account key in the org. The number will surprise you.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.