Illuminate GCP by Fuzzing IAM Permissions

What this lab covers

You work out what your credentials can do without being able to read any IAM policy, then use that knowledge to find container images and storage that reveal more of the environment.

This is the GCP counterpart to IAM enumeration in other providers, with a distinctive twist. The platform offers an explicit mechanism for testing permissions, which makes enumeration reliable rather than inferential.

It assumes no prior GCP experience and is a good starting point for the Google Cloud labs.

How permission fuzzing works in GCP

Google Cloud exposes a method that takes a resource and a list of permissions and returns which of them the caller holds. It exists so applications can adapt their interface to the user's access, and it is available even where the caller cannot read the policy itself.

That makes enumeration a matter of supplying candidate permission names. The full set of permissions is public and documented, so an attacker iterates through the relevant ones against each resource and receives an authoritative answer about their own access.

The output is more reliable than reading a policy would be, because it reflects the effective result after all inherited bindings, conditions and denies. It answers what the caller can actually do rather than what the configuration appears to say.

How to detect this in your own environment

Permission testing appears in Cloud Audit Logs, and large volumes of it against many resources are a strong reconnaissance signal. Legitimate applications test a small, fixed set relevant to their interface.

Look for breadth rather than volume. An identity testing permissions across many unrelated resources and services is behaving nothing like an application adapting a user interface.

Correlate with what follows. Enumeration precedes action, so permission testing followed by first-time use of a discovered capability is a much stronger signal than either alone.

How to prevent it

You cannot meaningfully prevent an identity from discovering its own permissions, and blocking the method would break legitimate applications. The control is to ensure the answer is uninteresting.

Reduce standing permissions so enumeration reveals little. This is the same conclusion as every other cloud enumeration technique, and it is the one that actually works.

Use IAM conditions and organization policies to constrain what bindings can grant, so that even a broad-looking role is bounded in practice by resource and context conditions.

Real-world context

Permission enumeration is a standard early step in Google Cloud assessments, and tooling exists specifically to automate it. It is not a vulnerability but a documented feature, which is why the defensive answer is permission hygiene rather than blocking.

The related storage naming issue is worth noting alongside it. Bucket names in Google Cloud share a global namespace, and organizations name them predictably, so a discovered convention often reveals resources that permission enumeration alone would not.

The activity maps to MITRE ATT&CK T1087 Account Discovery and T1069 Permission Groups Discovery.

Applying this at work

• Run permission enumeration against your own service accounts and see what a compromise of each would reveal.
• Review standing permissions on identities that do not need them, particularly broad viewer roles granted for convenience.
• Alert on high-volume permission testing across unrelated resources.
• Check whether your storage naming convention makes resources guessable from your company and environment names.
• Apply IAM conditions to bound what broad roles can reach.

Frequently asked questions

What is testIamPermissions used for legitimately?

It lets an application determine which actions the current user can perform so it can adapt its interface, for example hiding buttons the user cannot use. It is a documented and widely used feature.

Can I stop attackers enumerating their permissions this way?

Not without breaking legitimate applications, since the method exists for that purpose. The effective control is reducing standing permissions so that the answer is not useful.

Why is this more reliable than reading the IAM policy?

Because it returns the effective result after inheritance, conditions and denies are applied. Reading a policy shows configuration, whereas this answers what the caller can actually do.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.