GCP Penetration Testing Guide

“Unlike AWS, in GCP the list of permissions is decoupled from the resources. The resources for which a permission assignment would apply is called a scope.”

Spin up a Compute Engine instance in a default GCP project, accept the defaults, and you have just attached an identity with the Editor role over everything in that project to a machine that is about to run somebody’s web application. That is not an exotic misconfiguration. That is the “next, next, finish” path. GCP Penetration Testing Guide is a technical manual about what an attacker does with that fact, and it deliberately skips web application exploitation to stay on the control plane.

Deconstructing the Resource Hierarchy

Exploiting GCP starts with knowing where a permission actually lands. The guide maps the hierarchy first — Organisation, then Folders, then Projects, then the resources themselves — because inheritance flows downward and nothing about the console makes that obvious at a glance.

The operational point it draws out is that GCP’s IAM model is not AWS’s. AWS leans on identity-attached policies; GCP binds roles to a resource at a scope, and the binding cascades to everything beneath it. Get a role at the Project level and you have it on every bucket, instance and secret inside. The practical consequence for an attacker is that the interesting question is never “what can this credential do” but “at what scope was that granted” — a roles/viewer at the Organisation node is worth far more than an Owner on one Project.

The Attack Surface: Service Accounts

Non-human identities are where GCP compromises actually happen. Service accounts do not expire on their own, they have no MFA to bypass because MFA does not apply to them, and nobody gets a prompt when one is used at three in the morning from an unfamiliar ASN. The guide works through the three variants:

• Default service accounts: Created automatically for Compute Engine and App Engine, and historically granted the Editor basic role across the whole Project. Newer organisations get this off by default via the automaticIamGrantsForDefaultServiceAccounts org policy, but the constraint is not retroactive — every project created before someone set it still carries the grant, and those are the ones you find.
• User-managed service accounts: Created deliberately for a specific workload. Better in principle, and in practice they accumulate roles over years because removing one risks breaking a job nobody owns any more.
• Google-managed service accounts: Owned by the provider, used by services acting on your behalf. Mostly out of reach, but worth understanding so you can tell a legitimate agent call from an impersonated one in the logs.

The trade-off nobody states out loud: replacing default service accounts with least-privilege custom ones is straightforwardly correct and reliably breaks something in a pipeline that a developer wired up eighteen months ago. Budget for the breakage rather than pretending it will not happen.

Weaponizing JSON Key Files

An attacker on a compromised GCP instance is not looking for a local root password. They are looking for a service account key file — and more often, for the metadata server at 169.254.169.254, which will hand out a live OAuth 2.0 access token to anything that can make an HTTP request from the instance. That is the mechanism behind most GCP SSRF escalation. The guide covers locating exported JSON keys, authenticating with them via gcloud auth activate-service-account, and pivoting from one web server to the infrastructure that governs it.

The detection angle matters as much as the attack. A stolen JSON key is a long-lived bearer credential with no session, no device and no expiry, so the only evidence you will ever get is the Cloud Audit Log entry showing the call. Which is a problem, because Data Access logs are opt-in and billed by volume — meaning the reads an attacker performs are precisely the category most organisations have switched off to control cost. Admin Activity logs are always on and free; they will show you the role binding being created, not the data being taken.

Who Is This Book REALLY For?

• Cloud penetration testers: GCP has its own vocabulary and its own API surface, and AWS experience transfers less cleanly than people expect. This gives you the IAM mapping needed to escalate inside a Project — particularly the iam.serviceAccounts.actAs and getAccessToken permissions, which are the two quiet paths to owning an identity you were never granted.
• Cloud architects: The concrete argument for why the Compute Engine default service account should be stripped, and why per-workload identities cost more to maintain and are still worth it.
• Incident responders: How gcloud behaves when driven by a stolen key, so you know what the resulting audit trail looks like — and where it will be silent.

The Bottom Line

GCP Penetration Testing Guide makes an unglamorous case well: cloud breaches rarely involve breaking cryptography. They involve one over-permissioned identity, granted at a scope somebody chose because it was quicker than working out the right one, sitting on a machine that was always going to be reachable eventually.