Red Gcp Cloud Pentesting

---
name: red-gcp-cloud-pentesting
description: GCP offensive testing — principal and project identification, org/folder/project IAM inheritance, service accounts, Cloud Asset Inventory, storage, secrets, KMS, Compute, Cloud Run and Cloud Functions, GKE boundaries, Cloud Build, and Artifact Registry with gcloud as the…
domain: red
category: cloud-security
hide: true
license: Apache-2.0
metadata:
  manifest_entry: src/corpus/red-gcp-cloud-pentesting/SKILL.md
---
# GCP Cloud Pentesting

## Purpose
Full GCP offensive methodology: from project IDs/buckets discovered black-box to mapped IAM inheritance, service-account identity, and resource access with a validated credential. Modern tooling only — gcloud, Cloud Asset Inventory, Policy Analyzer, and native IAM/resource APIs. (Forseti is retired: the upstream project is archived; its inventory concepts live on in Cloud Asset Inventory.)

## Entry Conditions
- Black-box: project IDs, `storage.googleapis.com` buckets, Firebase configs, or `run.app`/`cloudfunctions.net` endpoints from `cloud-attack-surface-discovery`
- Credentialed: service-account JSON, OAuth token, or ADC credential from `cloud-credential-abuse`

## Discovery Signals
- Project IDs: bucket names (`gs://<project>-*`), Firebase `projectId`, API error messages
- Service-account emails in configuration, IAM bindings, metadata leaks
- `*.googleapis.com` endpoints in client code

## Attack Model

```text
project identified → IAM effective policy resolved (org→folder→project inheritance)
→ service-account identities mapped
→ resources enumerated (storage, secrets, compute, run, functions, build)
→ data access + escalation candidates → verified impact
```

## Methodology

### Step 1: Identity and Project Context
```bash
gcloud auth activate-service-account --key-file <sa.json>   # or token
gcloud auth list && gcloud config get-value project
gcloud organizations list 2>/dev/null        # org visibility requires orgIAM
gcloud projects list                        # what can this principal see?
gcloud projects describe <project> --format "value(projectId, lifecycleState)"
# Effective principal: the SA email + the project numbers of everything reachable
```

### Step 2: IAM with Inheritance
```bash
gcloud projects get-iam-policy <project> --flatten="bindings[].members"
gcloud resource-manager folders list --organization <org> 2>/dev/null
gcloud organizations get-iam-policy <org>            # ORG-level grants flow DOWN
# Resolve the effective policy: a member bound at org level inherits into every project
# Policy Analyzer (where available) answers "who effectively can X":
gcloud policy-intelligence troubleshoot-policy iam --resource-type project --principal-email <sa> --permission storage.objects.get --project <project>
```
Key inheritance trap: an org/folder-level grant is invisible when reading only the project policy but still effective. Always resolve top-down.

### Step 3: Asset and Resource Enumeration
```bash
# Cloud Asset Inventory — the modern one-shot inventory (replaces Forseti-era approaches):
gcloud asset list --project=<project> --content-type=resource 2>/dev/null || \
gcloud asset search-all-resources --scope=projects/<project>
# Service accounts and their roles:
gcloud iam service-accounts list --project <project>
gcloud projects get-iam-policy <project> --flatten="bindings[].members" | grep -B2 "<number>-compute@developer"
# The DEFAULT compute/App Engine SAs frequently still hold roles/editor — check explicitly
# Storage / secrets / KMS:
gcloud storage ls && gcloud storage ls gs://<bucket>
gcloud secrets list && gcloud secrets versions access latest --secret=<name>
gcloud kms keyrings list --location <loc> && gcloud kms keys list --keyring <kr> --location <loc>
# Compute / Run / Functions:
gcloud compute instances list && gcloud compute instances describe <i> --format "value(serviceAccounts[].email,metadata)"
gcloud run services list --format "value(metadata.name,spec.template.spec.serviceAccountName)"
gcloud functions list
# Build / registry:
gcloud builds list && gcloud artifacts repositories list
```

### Step 4: Chains
- SA keys/JSON or tokens → `cloud-credential-abuse` expansion
- Escalation candidates (actAs/TokenCreator/setIamPolicy) → `gcp-iam-privilege-escalation`
- Storage exposure → `cloud-storage-exposure-testing`
- Cloud Run/Functions identity → `serverless-cloud-security`
- GKE: project IAM ↔ cluster boundary here (node SAs, workload identity pools); RBAC/internals → `container-security`
- Cloud Build: build config = code execution with the build SA (roles/editor by default historically)

## Evidence Contract

```text
candidate (permission/asset/SA)
→ live call with the validated credential proves access
→ concrete data or action (object read, secret accessed, instance described with creds, build triggered within scope)
→ report with project/scope context
```

**NOT evidence**: asset listing alone (no access proven), a broad role name without effective-permission demonstration, GCPBucketBrute/CSPM output without retrieval, org visibility without action proof

## Common Misses
- Org/folder IAM inheritance (top-level grants acting in every project)
- Default compute/AppEngine SAs with `roles/editor`
- Cloud Build as an execution primitive (build SA privileges)
- Cloud Asset Inventory never used (per-service enumeration misses cross-project items)
- Workload identity federation configs (external issuers minting tokens)
- Artifact Registry exposure (public repos, pull-through cache)

## False Positives / Non-Findings
- Projects in `DELETE_REQUESTED` lifecycle state
- SAs with roles but no keys/tokens reachable (record as exposure risk)
- Buckets existing (existence ≠ access — see `cloud-storage-exposure-testing`)

## Arsenal Tool Strategy
- `terminal_execute` with gcloud + Cloud Asset Inventory + Policy Analyzer — the baseline
- GCPBucketBrute optional for bucket enumeration (anonymous AND authenticated runs; custom keywords)
- Ledger: project map, effective IAM per principal, verified accesses

## Specialist Handoffs
`gcp-iam-privilege-escalation`, `cloud-storage-exposure-testing`, `cloud-secrets-data-access`, `serverless-cloud-security`, `cloud-cross-account-tenant-trust`

## Stopping Rule
Stop when: the principal's effective IAM (all hierarchy levels) is resolved, assets of the reachable projects are enumerated, high-value data/identities are chased, and the strongest escalation candidates are verified or blocked.