How do I install the Cloud GCP skill?

Run npx skillmds@latest add noorqureshi/cloud-gcp in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Cloud GCP safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cloud GCP?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cloud GCP free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Cloud GCP?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cloud GCP by noorqureshi — Agent Skill

Name: Cloud GCP
Author: NoorQureshi

Cloud GCP

Attack Google Cloud Platform — metadata/SA token theft, IAM privilege escalation, and storage/ function misconfig. Load when the target runs on GCP, you hold a GCP SA key/token, or see gcp/gcloud/GCE/GKE/appspot. Signals: metadata.google.internal, service-account.json, storage.googleapis.com, cloudfunctions, gcloud.

NoorQureshi 9e3a59d 2.4 KB Updated Sep 17, 2026

File contents

GCP attacks

When it applies

The target is on GCP and you have some access — an SSRF into a GCE/GKE instance, a leaked service account (SA) key, or a foothold in a workload. Goal: steal credentials, escalate IAM, reach data.

Why it works

GCP identity centers on service accounts and IAM bindings that are frequently over-granted. The metadata server hands SA tokens to anything on the instance, and a small set of permissions (actAs, setIamPolicy, deploy roles) form known escalation paths to owner.

Method

Metadata → SA token (via SSRF, or on the host): GET metadata.google.internal/computeMetadata/v1/ instance/service-accounts/default/token with header Metadata-Flavor: Google (→ cloud-imds-ssrf). Also grab .../scopes and project info.
Authenticate & enumerate: gcloud auth activate-service-account --key-file=sa.json; gcloud projects get-iam-policy, list what the SA can do; ScoutSuite for the landscape.
IAM privesc paths: iam.serviceAccounts.actAs + deploy (Cloud Functions/Run/Compute) to run as a higher-priv SA; iam.serviceAccounts.getAccessToken/signJwt/implicitDelegation; setIamPolicy (editor→owner); deploymentmanager running as the default SA.
Data & services: enumerate GCS buckets (→ cloud-s3-exposure equivalents), Cloud SQL, secrets in Secret Manager, and GKE (→ cloud-kubernetes).
Prove impact with a read-only call as the escalated identity; don't create lasting bindings.

Gotchas

SA scopes (legacy) can restrict a token even with broad IAM — check both scope and IAM.
actAs + a deploy permission is the classic privesc — hunt for it specifically.
Org policies/VPC-SC may block exfil paths; note them rather than forcing.

Verify success

Escalated access proven — a call succeeding as a higher-priv SA, secret/data read you shouldn't have, or gcloud acting with permissions beyond your starting identity.

References

GCP IAM docs; Rhino Security GCP privesc research; ScoutSuite; "hacking GCP" guides.

---name: cloud-gcpdescription: Attack Google Cloud Platform — metadata/SA token theft, IAM privilege escalation, and storage/ function misconfig. Load when the target runs on GCP, you hold a GCP SA key/token, or see gcp/gcloud/GCE/GKE/appspot. Signals: metadata.google.internal, service-account.json, storage.googleapis.com, cloudfunctions, gcloud.---# GCP attacks## When it appliesThe target is on GCP and you have some access — an SSRF into a GCE/GKE instance, a leaked serviceaccount (SA) key, or a foothold in a workload. Goal: steal credentials, escalate IAM, reach data.## Why it worksGCP identity centers on **service accounts** and IAM bindings that are frequently over-granted. Themetadata server hands SA tokens to anything on the instance, and a small set of permissions(`actAs`, `setIamPolicy`, deploy roles) form known escalation paths to owner.## Method1. **Metadata → SA token** (via SSRF, or on the host): `GET metadata.google.internal/computeMetadata/v1/ instance/service-accounts/default/token` with header `Metadata-Flavor: Google` (→ `cloud-imds-ssrf`). Also grab `.../scopes` and project info.2. **Authenticate & enumerate**: `gcloud auth activate-service-account --key-file=sa.json`; `gcloud projects get-iam-policy`, list what the SA can do; ScoutSuite for the landscape.3. **IAM privesc paths**: `iam.serviceAccounts.actAs` + deploy (Cloud Functions/Run/Compute) to run as a higher-priv SA; `iam.serviceAccounts.getAccessToken`/`signJwt`/`implicitDelegation`; `setIamPolicy` (editor→owner); `deploymentmanager` running as the default SA.4. **Data & services**: enumerate GCS buckets (→ `cloud-s3-exposure` equivalents), Cloud SQL, secrets in Secret Manager, and GKE (→ `cloud-kubernetes`).5. **Prove impact** with a read-only call as the escalated identity; don't create lasting bindings.## Gotchas- SA **scopes** (legacy) can restrict a token even with broad IAM — check both scope and IAM.- `actAs` + a deploy permission is the classic privesc — hunt for it specifically.- Org policies/VPC-SC may block exfil paths; note them rather than forcing.## Verify successEscalated access proven — a call succeeding as a higher-priv SA, secret/data read you shouldn'thave, or `gcloud` acting with permissions beyond your starting identity.## ReferencesGCP IAM docs; Rhino Security GCP privesc research; ScoutSuite; "hacking GCP" guides.

Frequently asked questions