| name | gcp-pentesting |
| description | GCP 云环境渗透测试总体方法论。当目标使用 Google Cloud Platform、发现 GCP 相关资产(GCS Bucket/Compute Engine/Cloud Functions/GKE)、获取 GCP 凭据(Service Account Key/OAuth Token/Metadata Token)、或需要对 GCP 环境进行安全评估时使用。提供从未授权枚举到提权、后渗透、GCP-to-Workspace 穿越的全流程决策树。覆盖 37+ GCP 服务攻击面 |
| metadata | {"tags":"gcp,google-cloud,service-account,compute-engine,gcs,gke,cloud-functions,iam,提权,后渗透,GCP渗透,云安全","category":"cloud"} |
GCP 云环境渗透测试方法论
GCP 是全球三大公有云之一,承载了大量企业核心业务。其独特的资源层级模型(Organization → Folder → Project → Resource)、Service Account 机制和 IAM 权限继承模型构成了与 AWS/Azure 截然不同的攻击面。本技能以攻击阶段(Phase)为主线,组织从"零凭据"到"完全控制"的完整渗透路径。
GCP 与 AWS 的核心区别
| 概念 | GCP | AWS |
|---|
| 资源层级 | Organization → Folder → Project → Resource | Account → OU → Resource |
| 身份主体 | Google Account、Service Account、Group | IAM User、IAM Role |
| 凭据类型 | SA Key (JSON)、OAuth Token、Metadata Token | AK/SK、STS Token、Instance Profile |
| 权限绑定 | 在资源上绑定(get-iam-policy) | 在主体上附加策略(Policy) |
| PassRole 等价 | iam.serviceAccounts.actAs | iam:PassRole |
| 元数据端点 | 需要 Metadata-Flavor: Google 头 | IMDSv1 无需头 / IMDSv2 需 Token |
| 访问范围 | OAuth Scopes 限制 Token 能力 | 无等价机制 |
深入参考
识别到具体攻击阶段后,加载对应参考文档获取完整技术细节:
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 凭据类型速查
| 凭据类型 | 识别特征 | 有效期 | 获取方式 |
|---|
| SA Key (JSON) | JSON 文件含 type: service_account + private_key | 永久(直到删除) | 控制台创建 / 代码泄露 |
| OAuth Access Token | 以 ya29. 开头 | 1 小时 | gcloud / Metadata / API |
| Refresh Token | 存储在 credentials.db 中 | 通常长期有效,但会受撤销、未使用、用户安全事件和 Google Cloud session control 影响 | gcloud 本地文件 |
| Metadata Token | 从 169.254.169.254 获取 | 自动轮换(~1 小时) | Compute/Functions/Run 内部 |
| OIDC Identity Token | JWT 格式 | 1 小时 | SA 签发 / Metadata |
| HMAC Key | AccessId + Secret(用于 GCS 互操作) | 永久 | gsutil hmac create |
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 | 域名枚举 + 暴力猜解 storage.googleapis.com | 数据泄露、获取凭据文件 |
| Cloud Functions URL | https://REGION-PROJECT.cloudfunctions.net/FUNC | Web 漏洞利用、未鉴权调用 |
| Cloud Run 服务 | https://SERVICE-xxx.a.run.app | Web 漏洞利用 |
| App Engine | https://PROJECT.appspot.com | Web 漏洞利用、版本枚举 |
| Firebase RTDB | https://PROJECT.firebaseio.com/.json | 直接读取数据库 |
| Compute Engine 公开端口 | Nmap + 服务指纹 | SSRF → Metadata → SA Token |
| BigQuery 公开数据集 | bq ls --project PROJECT | 敏感数据泄露 |
| Source Repositories | gcloud source repos list | 代码泄露 |
| API Keys | 前端代码 / 请求抓包 | 未限制的 API Key 滥用 |
GCS Bucket 快速枚举
curl "https://storage.googleapis.com/TARGET-BUCKET"
gcloud storage ls gs://TARGET-BUCKET 2>/dev/null
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
gsutil -m cp -r gs://TARGET-BUCKET/ ./loot/ 2>/dev/null
python3 gcpbucketbrute.py -k TARGET_KEYWORD -w wordlist.txt
Firebase 数据库快速检测
curl "https://TARGET-PROJECT.firebaseio.com/.json"
curl -X PUT "https://TARGET-PROJECT.firebaseio.com/test.json" -d '"pwned"'
公开资源综合枚举工具
python3 cloud_enum.py -k TARGET_KEYWORD
CloudBrute -d TARGET -k TARGET -w wordlist.txt
Phase 2: 凭据验证与权限评估
获取凭据后,第一步是验证有效性并评估权限范围。
2.1 凭据配置与身份验证
gcloud auth activate-service-account --key-file=sa_key.json
export CLOUDSDK_AUTH_ACCESS_TOKEN="ya29.xxxx"
gcloud projects list
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 权限枚举
gcloud projects get-iam-policy PROJECT_ID \
--flatten="bindings[].members" \
--filter="bindings.members:serviceAccount:SA_EMAIL" \
--format="table(bindings.role)"
python3 bf_my_gcp_permissions.py -p PROJECT_ID
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 自动化审计工具
| 工具 | 用途 | 命令 |
|---|
| ScoutSuite | 多云安全审计报告 | scout gcp --user-account |
| gcp_scanner | GCP 资源扫描与权限评估 | python3 __main__.py -o /tmp/out/ -g ~/.config/gcloud |
| gcp_enum | GCP 环境枚举(Bash 脚本) | ./gcp_enum.sh |
| bf_my_gcp_permissions | 暴力枚举当前凭据权限 | python3 bf_my_gcp_permissions.py -p PROJECT |
| gcpwn | GCP 渗透测试框架 | python3 main.py |
| Hayat | GCP 攻击路径发现 | hayat scan --project PROJECT |
Phase 3: 提权
GCP 提权的核心思路:利用当前权限去获取更高权限。GCP 有数百个权限,其中很多组合可以形成提权路径。两大类提权模式:
- 主体提权:冒充另一个主体(如通过
getAccessToken 冒充 SA)
- 资源提权:在特定资源上获取更多权限(如通过
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 持久化技术概览
| 服务 | 持久化方法 | 隐蔽性 |
|---|
| IAM | 创建新 SA Key、添加 IAM Binding、修改角色权限 | 低(Admin Activity 日志) |
| Compute Engine | SSH Key 注入、startup-script 后门、磁盘快照 | 中 |
| Cloud Functions | 修改函数代码、添加 allUsers invoker 权限 | 中 |
| Cloud Run | 部署后门服务、修改现有服务代码 | 中 |
| Cloud Scheduler | 创建定时任务调用 googleapis.com API | 高 |
| Pub/Sub | 添加外部订阅者持续接收消息 | 高 |
| Cloud Build | 修改触发器注入恶意构建步骤 | 高 |
| Storage | Bucket IAM 后门、HMAC Key 创建 | 中 |
| Token 窃取 | Refresh Token 持久化、SA Key 离线保存 | 高 |
| API Keys | 创建不受限制的 API Key | 中 |
| Logging | 修改 Log Sink 将审计日志导出到攻击者控制的目标 | 高 |
→ 读 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
gcloud projects get-iam-policy PROJECT_ID
gcloud iam service-accounts list
gcloud organizations list
gcloud compute instances list
gcloud storage ls
gcloud functions list
gcloud run services list
gcloud sql instances list
gcloud secrets list
gcloud container clusters list
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 服务缩写对照表
| 服务 | 攻击面关键词 |
|---|
| IAM | 权限策略、Service Account、角色绑定、提权 |
| Compute Engine | 实例、Metadata、SSH Key、startup-script |
| GCS (Cloud Storage) | Bucket 策略、ACL、公开访问、HMAC Key |
| Cloud Functions | 函数 URL、环境变量、绑定 SA |
| Cloud Run | 服务 URL、容器部署、SA 绑定 |
| GKE | RBAC、Node SA、Pod SA、集群凭据 |
| BigQuery | 数据集权限、数据导出、Row-Level Security |
| Cloud SQL | 公开访问、导出、连接 |
| Secret Manager | 密钥存储、版本访问 |
| KMS | Key Policy、加解密权限 |
| Cloud Build | 构建触发器、SA 令牌 |
| Composer (Airflow) | DAG 注入、Bucket 后门 |
| Pub/Sub | Topic/Subscription 策略 |
| Cloud Scheduler | 定时任务、OAuth/OIDC Token 获取 |
| Vertex AI | Notebook、Custom Job、Model 部署 |
| Artifact Registry | 镜像仓库策略、镜像投毒 |
注意事项
Cloud Audit Logs 审计感知: GCP 的审计日志分为两类:
| 日志类型 | 内容 | 默认启用 | OPSEC 影响 |
|---|
| Admin Activity | 资源创建/修改/删除、IAM 变更 | 始终启用,不可关闭 | 高(所有管理操作可见) |
| Data Access | 数据读取/写入(如 GCS GetObject、BigQuery 查询) | 默认关闭 | 低(但组织可能启用) |
高风险操作(必定触发 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)不受区域限制。