GCP 到 Google Workspace 穿越攻击方法论

GCP 与 Google Workspace 同属 Google Cloud 生态，二者通过 IAM 和 OAuth 深度绑定。当攻击者拿到 GCP Service Account 或 Project 权限后，若目标组织同时使用 Google Workspace（原 G Suite），就可能从云基础设施穿越到企业办公系统, , 直接访问全员邮件、文件、日历、通讯录乃至管理控制台。

为什么这个穿越如此致命：

• 影响面极大：一个配置了 Domain-Wide Delegation（DWD）的 Service Account 可冒充组织内任意用户
• 权限升级无感知：DWD 滥用不需要目标用户交互或确认，被冒充的用户完全无感
• 数据价值极高：企业邮件（Gmail）、共享文件（Drive）、会议日程（Calendar）、组织架构（Admin Directory）全部可被访问
• 攻击路径隐蔽：通过 Service Account 生成的 OAuth Token 访问 Workspace API，不同于用户直接登录，很多组织缺少对此类访问的监控

深入参考

识别到具体 Workspace 后渗透场景后，加载参考文档获取完整技术细节：

• Workspace 各服务后渗透操作（Gmail/Drive/Calendar/Admin Directory/Chat）与持久化技术 → 读 references/workspace-post-exploit.md

核心概念：Domain-Wide Delegation（DWD）

DWD 是什么

Domain-Wide Delegation 是 Google Workspace 的一项功能，允许 GCP Service Account 代表 Workspace 域内的任意用户访问 Google API。其工作流程：

1. Service Account 使用私钥签署 JWT（声明要冒充的用户和请求的 OAuth scope）
2. JWT 发送到 Google OAuth 2.0 服务，请求 Access Token
3. Google 验证 DWD 配置后返回 Access Token（代表目标用户）
4. 使用该 Token 调用 Google API（Gmail/Drive/Calendar 等），以目标用户身份操作

为什么 DWD 危险

• 配置 DWD 时只需 Service Account 的 OAuth Client ID 和 OAuth Scope，不绑定特定用户
• 一旦配置，该 SA 可冒充域内任意用户，包括 Super Admin
• DWD 配置只能在 Admin Console 手动管理，无法通过 API 审计其历史变更
• 许多组织为了自动化工作流而配置 DWD，但未做最小权限限制

DWD 滥用的前提条件

条件	说明
拥有 SA 私钥或可创建新密钥	iam.serviceAccountKeys.create 权限
SA 已配置 DWD	Admin Console 中已授权该 SA 的 Client ID
知道至少一个有效 Workspace 用户邮箱	用于冒充，Super Admin 效果最佳
SA 被授权了有用的 OAuth Scope	如 Gmail、Drive、Admin Directory 等

攻击链：发现并利用 DWD

Step 1：枚举 GCP 项目中的 Service Account

# 列出当前项目的所有 Service Account
gcloud iam service-accounts list --project <project-id>

# 枚举所有可访问项目
for proj in $(gcloud projects list --format="value(projectId)"); do
  echo "=== Project: $proj ==="
  gcloud iam service-accounts list --project "$proj" \
    --format="table(email,displayName,disabled)" 2>/dev/null
done