What is the primary attack vector for GCP Cloud Storage?

Misconfigured IAM permissions, specifically the allUsers and allAuthenticatedUsers roles, allow unauthorized access to Cloud Storage buckets and expose sensitive data without authentication.

GCP Pentesting 101

This guide walks through what you need to get started with Google Cloud security, with a focus on penetration testing. If you are moving into GCP from another cloud or from traditional pentesting, it covers the foundations to build, the tooling to gather, and the attack paths that come up most often in Google Cloud environments.

Why learn GCP pentesting? Google Cloud is one of the top three cloud providers, and it is still growing. HG Insights put its customer base up 23 percent year over year in 2024, holding roughly 11 percent of the cloud market. As adoption rises, so does the demand for people who can find and fix the weaknesses in these environments.

Source: Google Cloud Market Share Report, HG Insights.

Key Takeaway: Getting started with GCP penetration testing means understanding cloud-native attack paths: exposed Cloud Storage buckets, SSRF against the metadata service, and IAM permission enumeration and escalation, which are the primary compromise routes in Google Cloud.

Build the foundations first

Pentesting Google Cloud takes more than running tools. You need a working knowledge of cloud security, networking, and offensive fundamentals before the attacks make sense. Start here.

Cloud computing concepts

Google Cloud works differently from an on-premises environment. Get comfortable with:

Identity and Access Management (IAM): how permissions, roles, and policies control access to GCP resources.
Virtual Private Cloud (VPC): networking in GCP, including subnets, firewalls, and routing.
Cloud Storage and databases: how Google Cloud stores data (Cloud Storage, BigQuery, Firestore) and where misconfigurations creep in.

Networking and security fundamentals

IP addressing and CIDR notation: how networks are structured in the cloud.
Firewalls and security groups: how traffic is controlled in GCP.
Common protocols: HTTP, SSH, DNS, and VPN basics.

Linux and the command line

Most pentesting tools run on Linux, so basic terminal use, file permissions, and SSH will all come in handy.

Get comfortable with GCP

Since GCP assessments center on misconfigurations and privilege escalation, spend time in the platform itself.

Create a free tier account and set up an environment to practice in.
Explore the Cloud Console so the dashboard, services, and IAM settings are familiar.
Learn the gcloud CLI, part of the Google Cloud SDK, which lets you interact with resources from the command line.
Understand IAM, including service accounts and API keys. IAM misconfigurations are among the most common weaknesses in GCP.
Know Compute Engine and GKE. Many cloud attacks target virtual machines and containerized workloads, so understanding Compute Engine and Google Kubernetes Engine pays off.

Where to learn these concepts

Google's official documentation and the Cloud Skills Boost program are both strong starting points, with structured learning paths. The Security and Identity Fundamentals path is a good first stop. Cloud Skills Boost runs on a subscription of around 29 dollars per month. If you would rather not pay for it, you can follow the same topics and build the resources by hand in your own account. New Google Cloud sign-ups come with 300 dollars in free credits, which is plenty for hands-on practice.

Legal and ethical considerations

Before you test anything, understand the rules so you stay inside GCP's policies:

Google does not require you to notify them before testing your own cloud infrastructure, but you still have to follow their Terms of Service and Acceptable Use Policy. Check their current cloud security guidance for the details.
Avoid disruptive techniques such as denial of service or heavy scanning. They can trigger alerts and disrupt the environment you are testing.
Never test anything you are not authorized to touch. Get a clear scope of engagement from the client in writing first.

Getting started with GCP pentesting

With the groundwork in place, here are some of the high-level attacks worth knowing. For deeper, hands-on versions, work through the GCP labs on our platform.

Hunting exposed Cloud Storage buckets

If you have spent any time in cloud security, you have heard about misconfigured S3 buckets on AWS. The same problem exists in Google Cloud Storage.

A Cloud Storage bucket holds files, with permissions that control who can read or access them. Misconfigurations can leave those files public, meaning anyone can reach them. Companies have exposed sensitive customer data this way, which makes hunting for open buckets a worthwhile exercise and a real risk for organizations.

The root cause usually comes down to IAM permissions, specifically the roles assigned to allUsers and allAuthenticatedUsers:

allUsers: makes the resource public to anyone on the internet, with no authentication. Anyone can reach the bucket and its contents.
allAuthenticatedUsers: often misunderstood. It does not limit access to your project. It allows anyone with a valid Google account, any Gmail or GCP account, to access the resource, which can mean millions of people if it is set incorrectly.

Many beginners assume allAuthenticatedUsers means only users in their own project. It does not. It means any Google account holder worldwide, which makes it a dangerous setting.

Here is a quick, high-level look at the Exposed Cloud Storage lab on our platform. It is not a full walkthrough. Say we have a bucket named it-storage-bucket. We can use ffuf to fuzz for files with a common wordlist:

ffuf -w backup_files_only.txt -u https://storage.googleapis.com/it-storage-bucket/FUZZ -mc 200 -c

That turns up a backup.7z file we can download. There is also a purpose-built tool for brute-forcing GCP Cloud Storage called GCPBucketBrute, which enumerates and discovers exposed buckets:

python3 gcpbucketbrute.py -k pwned -u

This scans for buckets using the keyword "pwned" while staying completely unauthenticated. We have a growing set of GCP labs, and several of them put you hands-on with real Cloud Storage misconfigurations.

Getting a foothold through SSRF

Server-Side Request Forgery (SSRF) lets an attacker make a vulnerable server send requests to internal or external resources. In GCP, SSRF can be used to reach the metadata service, internal APIs, and sensitive credentials.

There is a catch. In 2020, Google began requiring the Metadata-Flavor: Google header on requests to the metadata server. That stops most standard SSRF attacks from pulling metadata directly, since most SSRF bugs do not let you set request headers.

Bypassing the header restriction. Legacy protocols like gopher:// can still be abused in some cases. Where an application is vulnerable to SSRF and supports gopher, an attacker can inject raw, header-controlled requests and get around the metadata header requirement.

This is the basis of the Exploit SSRF with Gopher for GCP Initial Access lab. Given a vulnerable application that fetches profile images, we can point it at the internal metadata server using gopher:

gopher://metadata.google.internal:80/xGET%2520/computeMetadata/v1/instance/service-accounts/%2520HTTP%252f%2531%252e%2531%250AHost:%2520metadata.google.internal%250AAccept:%2520%252a%252f%252a%250aMetadata-Flavor:%2520Google%250d%250a

Breaking that down:

gopher://metadata.google.internal:80/ targets the metadata service on port 80.
/computeMetadata/v1/instance/service-accounts/ requests service account metadata.
The Host header is set to metadata.google.internal.
The Metadata-Flavor: Google header is included, which is required to reach the metadata service.

From there we can ask the metadata server to print the access token for the attached service account:

gopher://metadata.google.internal:80/xGET%2520/computeMetadata/v1/instance/service-accounts/[email protected]/token%2520HTTP%252f%2531%252e%2531%250AHost:%2520metadata.google.internal%250AAccept:%2520%252a%252f%252a%250aMetadata-Flavor:%2520Google%250d%250a

With that access token, you can use the gcloud CLI to act as the attached service account.

If you are lucky, the instance is running a default service account, which is bad news for the defender. Default service accounts often carry overly permissive roles, and in many cases hold the Editor role on the project. That effectively hands you the environment: you can create, modify, or delete resources at will. The takeaway is simple. A default service account is a serious risk.

IAM enumeration

IAM enumeration is an essential step for finding misconfigurations and privilege escalation paths in GCP. In this section we look at how to enumerate IAM permissions, and even brute-force them quietly without generating detailed cloud logs.

While working on a project for Pwned Labs, we came across the testIamPermissions endpoint in GCP. We are not claiming to be first here, since early traces of this method show up in ThunderCTF. It turns out the endpoint lets you brute-force IAM permissions and confirm which valid permissions your account holds.

You can try this on a project you create in your own account, or work through our lab, Illuminate GCP by Fuzzing IAM Permissions.

How it works. GCP provides the testIamPermissions API so users can check whether they hold specific permissions on a resource. That same feature can be used to enumerate which permissions an account has, essentially brute-forcing valid IAM permissions without generating detailed security logs:

POST https://cloudresourcemanager.googleapis.com/v1/projects/{resource}:testIamPermissions

The request body contains an array of permission strings to test:

{
  "permissions": [
    "resourcemanager.projects.get",
    "artifactregistry.repositories.get"
  ]
}

Authentication. Include an OAuth 2.0 access token in the request headers. You can obtain one from the gcloud CLI and pass it as a bearer token when you call the endpoint.

The response lists back only the permissions your identity actually holds, which lets you map your access one batch at a time.

Bottom line

Securing GCP means understanding the full attack chain: from initial reconnaissance through exposed buckets and metadata service abuse, to privilege escalation via IAM enumeration, and on to full environment compromise. On the defensive side, apply least-privilege IAM policies, restrict service account permissions, enforce VPC Service Controls, and monitor access to the metadata service to break these paths before they start.