# GCP Workspace Pivot

GCP 到 Google Workspace 的穿越攻击方法论。当已获取 GCP Service Account 或 Project 权限并发现目标组织使用 Google...

- Repository: https://github.com/wgpsec/AboutSecurity (1833 stars)
- Category: DevOps
- License: see repository
- Last updated: 2026-10-24
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add wgpsec/AboutSecurity --skill gcp-workspace-pivot -g -a claude-code -y`
Codex: `npx skills add wgpsec/AboutSecurity --skill gcp-workspace-pivot -g -a codex -y`
Cursor: `npx skills add wgpsec/AboutSecurity --skill gcp-workspace-pivot -g -a cursor -y`
Gemini CLI: `npx skills add wgpsec/AboutSecurity --skill gcp-workspace-pivot -g -a gemini-cli -y`

## Description

GCP 到 Google Workspace 的穿越攻击方法论。当已获取 GCP Service Account 或 Project 权限并发现目标组织使用 Google Workspace、需要从云平台穿越到企业邮件/文档/管理控制台、或发现 Domain-Wide Delegation 配置时使用。覆盖 Domain-Wide Delegation 滥用、OAuth 范围利用、Workspace API 数据窃取（Gmail/Drive/Calendar/Admin Directory）、以及 Workspace 持久化技术

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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](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

```bash
# 列出当前项目的所有 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
```

The rest: https://github.com/wgpsec/AboutSecurity/blob/HEAD/skills/cloud/gcp-workspace-pivot/SKILL.md