GCP Penetration Testing Training

Google Cloud Platform is the least-covered major cloud provider in offensive security training, which creates both a skills gap and an opportunity. GCP's security model differs from AWS and Azure in fundamental ways, resource hierarchy (organizations → folders → projects), IAM binding inheritance, and the pervasive use of service accounts as the primary non-human identity mechanism. Applying AWS or Azure attack patterns to GCP without understanding these differences leads to missed findings and incomplete assessments.

GCP's attack surface has been publicly demonstrated by researchers and threat actors alike. The Cloud Build privilege escalation (where the default Cloud Build service account could modify its own IAM bindings) represented a systemic design flaw. Google Workspace compromise through service account domain-wide delegation continues to be a high-impact finding on real engagements. These are GCP-specific issues that require GCP-specific training.

GCP Attack Techniques Covered

GCP IAM Exploitation

GCP IAM operates on a resource hierarchy where bindings cascade downward, a role granted at the organization level applies to every project beneath it. Key attack techniques include:

• Service account impersonation, using iam.serviceAccounts.getAccessToken or iam.serviceAccounts.signBlob to generate tokens for higher-privilege service accounts
• IAM policy enumeration, identifying overly permissive bindings at project, folder, or organization level using getIamPolicy
• Custom role abuse, finding custom roles with dangerous permission combinations that don't exist in predefined roles
• Domain-wide delegation exploitation, service accounts with domain-wide delegation in Google Workspace can impersonate any user, accessing their Gmail, Drive, and Calendar
• Cross-project service account access, exploiting trust relationships where Project A's workloads can assume service accounts in Project B

Cloud Build Privilege Escalation

Cloud Build is one of the most powerful attack vectors in GCP. The default Cloud Build service account has extensive permissions including the ability to:

• Read and write to all Cloud Storage buckets in the project
• Push and pull container images from Container Registry / Artifact Registry
• Deploy to Cloud Functions, Cloud Run, and App Engine
• Access secrets from Secret Manager (if configured)

Compromising a Cloud Build trigger, through a poisoned repository, malicious pull request, or CI/CD configuration injection, provides access to all of these capabilities. Build steps execute arbitrary code with the service account's permissions, making Cloud Build a lateral movement goldmine.

GKE Container Attacks

Google Kubernetes Engine deployments expose both Kubernetes-native and GCP-specific attack surfaces:

• Workload Identity abuse, mapping between Kubernetes service accounts and GCP service accounts creates escalation paths
• Metadata server access, GKE nodes expose the GCP metadata endpoint (169.254.169.254) to pods by default unless Workload Identity or metadata concealment is configured
• RBAC misconfiguration, overly permissive ClusterRoleBindings that grant pod-to-pod or pod-to-API-server access
• Container escape, breaking out of a compromised pod to the underlying GKE node and accessing its service account credentials

BigQuery Data Exfiltration

BigQuery datasets often contain the most valuable data in a GCP environment, analytics data, user records, financial information, and machine learning training data. Attack techniques include:

• Enumerating BigQuery datasets across all accessible projects
• Exploiting overly permissive dataset-level or table-level IAM bindings
• Using BigQuery's data transfer service to exfiltrate data to attacker-controlled projects
• Accessing BigQuery through compromised service accounts with bigquery.tables.getData permission

Cloud Functions and Cloud Run Abuse

GCP's serverless compute platforms present attack opportunities similar to AWS Lambda but with GCP-specific characteristics:

• HTTP-triggered functions with missing or misconfigured authentication (allUsers invoker binding)
• Environment variable and Secret Manager access from function execution context
• Service account credential extraction from the metadata service within function containers
• Cloud Run container image inspection for embedded secrets and misconfigurations

Google Workspace Integration Attacks

The boundary between GCP and Google Workspace is porous. Service accounts with domain-wide delegation can access any user's Gmail, Drive, Calendar, and Admin SDK. Compromising a Workspace admin account provides access to the GCP organization through Workspace-GCP identity federation. This cross-product attack surface is unique to Google's ecosystem.

The GCRTP Bootcamp

The Google Cloud Red Team Professional (GCRTP) bootcamp at Pwned Labs focuses specifically on GCP offensive security. Labs run on real GCP projects with real services, not emulated environments.

Curriculum covers:

• GCP IAM exploitation and service account abuse
• Cloud Build privilege escalation and CI/CD pipeline attacks
• GKE container security and Kubernetes attack chains
• BigQuery data access and exfiltration techniques
• Google Workspace compromise through domain-wide delegation
• Cloud Functions and Cloud Run exploitation
• Detection and monitoring with Cloud Audit Logs and Security Command Center

Tools used include the gcloud CLI for direct API interaction, ScoutSuite and Prowler for multi-cloud configuration assessment, and Pwned Labs' own open-source tooling built for GCP-specific attack paths that generic scanners miss, including google-workspace-enum for Google Workspace enumeration and google-spray for password spraying against Google identities.

The GCRTP certification exam tests practical execution: a multi-stage attack against a live GCP environment covering initial access through data exfiltration, with detection engineering recommendations.

Why GCP-Specific Training Is Critical

Most cloud security training either ignores GCP entirely or covers it as an afterthought. This creates a dangerous skills gap: organizations running production workloads on GCP are being assessed by practitioners trained exclusively on AWS or Azure. GCP's resource hierarchy, IAM model, and service architecture are different enough that AWS/Azure skills don't transfer cleanly.

The GCRTP bootcamp fills this gap with practitioner-focused, hands-on training built for the GCP attack surface as it actually exists.