Expose service account impersonation chains and overly permissive IAM bindings
We test your Cloud IAM configuration for privilege escalation paths, overly broad role bindings, service account impersonation chains, and cross-project trust abuse. Our testers examine primitive and custom role assignments, evaluate organization policy constraints and their gaps, assess Workload Identity Federation and Workload Identity for Kubernetes, and attempt lateral movement through generateAccessToken, actAs permissions, and inherited bindings across the resource hierarchy.
Google Cloud concentrates risk in service account impersonation and the resource hierarchy. We map every path from the identities in scope to the permissions they can reach, including the indirect ones: generateAccessToken and signJwt chains that let one principal act as another, actAs on a service account attached to a workload anyone can influence, and roles inherited down the organization, folder and project tree that nobody granted at the project level.
We test organization policy constraints as they are actually enforced rather than as intended, including which projects fall outside them, and we assess Workload Identity Federation between external systems and your projects. A trust condition that is broader than the repository or workflow it was written for is one of the most reliable footholds in Google Cloud.
Find exposed buckets, misconfigured datasets, and data exfiltration paths
We assess your Cloud Storage buckets, BigQuery datasets, Cloud SQL instances, Firestore databases, and other Google Cloud data stores for access control weaknesses, encryption gaps, and data exposure risks. Our testing covers public and allUsers bucket bindings, uniform versus fine-grained access control gaps, signed URL abuse, cross-project dataset access, and exfiltration paths through VPC Service Controls gaps, Private Google Access, and legitimate Google Cloud services.
The data findings that matter are combinations rather than single misconfigurations. We look for buckets bound to allUsers or allAuthenticatedUsers, the gap between uniform bucket-level access and legacy fine-grained ACLs that survived a migration, signed URLs with lifetimes far longer than their purpose requires, and BigQuery datasets shared across projects more widely than the owning team realises.
We also test whether VPC Service Controls actually contain the data they are meant to. A perimeter with a permissive ingress or egress rule, or a project left outside it, provides much less protection than the architecture diagram suggests, and that gap is where exfiltration paths tend to survive.
Test event-driven architectures, Cloud Run, and serverless attack surfaces
Our testers evaluate Cloud Functions, Cloud Run services, API Gateway configurations, Eventarc triggers, Pub/Sub topics, and Cloud Workflows for injection vulnerabilities, insecure environment variable and Secret Manager handling, overly permissive runtime service accounts, and event source manipulation. We assess serverless-specific risks including unauthenticated invocation through misconfigured invoker bindings, container image supply chain weaknesses in Artifact Registry, and metadata server access from within running workloads.
Serverless and container workloads in Google Cloud carry standing credentials reachable by anyone who can influence their input. We test Cloud Run and Cloud Functions for unauthenticated invocation through misconfigured invoker bindings, secrets held in environment variables rather than Secret Manager, and runtime service accounts scoped far beyond what the workload needs.
GKE gets the same treatment: Workload Identity bindings between Kubernetes service accounts and Google service accounts, access to the metadata server from inside a running pod, and node service accounts that hold project-wide permissions. We also assess the supply chain into those workloads, since an Artifact Registry repository writable by a pipeline is a route into everything that pipeline deploys.
Structured, repeatable, and aligned with MITRE ATT&CK Cloud Matrix
Every Google Cloud penetration test follows a structured methodology aligned with PTES, OWASP, and the MITRE ATT&CK Cloud matrix. We begin with threat modeling and scoping tailored to your GCP resource hierarchy, followed by reconnaissance, vulnerability identification, exploitation, and post-exploitation analysis that mirrors real adversary behavior. We go beyond automated scanning: our testers chain misconfigurations, abuse trust relationships, and exploit cloud-native features the way actual threat actors do. Deliverables include executive and technical reports with findings mapped to ATT&CK techniques and prioritized remediation guidance.
Scoping carries more weight in Google Cloud than on premises, because the resource hierarchy means the blast radius of a test can cross project and folder boundaries. Before testing begins we agree the organization, folders, projects and services in scope, confirm what is shared, and align with Google's current policy on customer-initiated testing so permitted activity is clearly separated from anything requiring prior notification.
Every finding arrives with the evidence behind it, the specific API calls involved, and the detection that should have fired. We name the source, whether that is Cloud Audit Logs, Data Access logs that are often disabled by default, or Security Command Center findings, because a finding you cannot detect next time is one you have not really fixed.
Google Cloud security specialists who build, break, and defend cloud environments
Pwned Labs is not a traditional consultancy: we are practitioners who build, break, and defend Google Cloud environments every day. We author the Google Cloud Red Team Professional (GCRTP) certification and the Google Cloud Attack and Defense bootcamp, and we actively contribute to the offensive security community through research, tooling, and training content used by thousands of professionals worldwide. Every engagement is led by operators with direct experience across enterprise Google Cloud and Google Workspace environments. We understand Google Cloud native threats because we research and simulate them daily on our own cloud security training platform.
That research feeds directly into engagements. The techniques in our Google Cloud labs and in the Google Cloud Red Team Professional (GCRTP) certification are the same ones our testers use on client work, which keeps the methodology exercised against current Google Cloud behaviour rather than a snapshot from whenever it was last written down.
If you would rather build the capability in house, GCRTP is assessed hands-on in a live Google Cloud and Google Workspace environment.