noorqureshi/security-skills/cloud-gcp

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

1. 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.

1. 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.

1. 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.

1. Data & services: enumerate GCS buckets (→ cloud-s3-exposure equivalents), Cloud SQL,

secrets in Secret Manager, and GKE (→ cloud-kubernetes).

1. 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.