Sponsored

GCP - local privilege escalation ssh pivoting

In this scenario, suppose that you have compromised a non-privileged account inside a VM in a Compute Engine project.

GCP permissions available through the attached Compute Engine service account may provide paths to local privilege escalation or SSH access. The practical result depends on the service account's IAM roles and, for OAuth requests from the VM, its access scopes; both can constrain the API call. [1][4]

Read the scripts

Compute Engine instances commonly execute scripts that perform actions with their attached service accounts. [1][4]

IAM is granular, so an account may have read/write privileges over a named resource but no permission to enumerate resources. [1][5]

A useful hypothetical example is a Compute Engine instance that has permission to read/write backups to a storage bucket called instance82736-long-term-xyz-archive-0332893. [1]

Running gsutil ls without a bucket name requires storage.buckets.list, so it can fail even when the service account can access a known bucket. If you run gsutil ls gs://instance82736-long-term-xyz-archive-0332893, the request instead targets that bucket and may list its objects when the account has the relevant object permissions, potentially exposing a filesystem backup that the local Linux account cannot read. [1][6][7]

You may be able to find this bucket name inside a script (in Bash, Python, Ruby, or another language). [1]

Custom Metadata

Administrators can add custom metadata at the instance and project level. Custom metadata passes arbitrary key/value pairs to VMs and is commonly used to parameterize startup and shutdown scripts. [2]

Compute Engine calls boot-time scripts startup scripts, rather than userdata. A startup script stored in metadata is read by the guest environment and executed when the VM boots; metadata values can also be queried from the VM's metadata server. [2][3]

For more info check:

https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html

Abusing IAM permissions

The following permissions can enable local escalation or SSH access when granted to the attached service account. IAM roles determine which API permissions the account has, while access scopes can further limit OAuth requests; the cloud-platform scope does not grant IAM permissions by itself. Google recommends using that scope and enforcing least-privilege access through IAM roles. [1][4][5]

Do not assume that a default Compute Engine service account has these permissions: its roles depend on the project's organization-policy and IAM configuration. [4]

Check the following permissions and the linked exploitation notes: [5]

Search for Keys in the filesystem

Check whether other users have logged in to gcloud inside the VM and left sensitive credential artifacts in the filesystem. Current ADC files and gcloud's credential store differ from legacy paths, so inspect both where applicable. [1][8][9]

Search for gcloud credentials in filesystem 
sudo find / -name "gcloud"

These are the most interesting files:

  • ~/.config/gcloud/credentials.db
  • ~/.config/gcloud/application_default_credentials.json
  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/adc.json (legacy ADC)
  • ~/.config/gcloud/legacy_credentials/[ACCOUNT]/.boto (legacy gsutil)
  • ~/.credentials.json (legacy gcloud installations)

More API key regexes

The following patterns are heuristics; review matches securely before using any recovered material.

Grep patterns for GCP credentials and keys 
TARGET_DIR="/path/to/whatever"

# Service account keys
grep -Pzr "(?s){[^{}]*?service_account[^{}]*?private_key.*?}" \
    "$TARGET_DIR"

# Legacy GCP creds
grep -Pzr "(?s){[^{}]*?client_id[^{}]*?client_secret.*?}" \
    "$TARGET_DIR"

# Google API keys
grep -Pr "AIza[a-zA-Z0-9\\-_]{35}" \
    "$TARGET_DIR"

# Google OAuth tokens
grep -Pr "ya29\.[a-zA-Z0-9_-]{100,200}" \
    "$TARGET_DIR"

# Generic SSH keys
grep -Pzr "(?s)-----BEGIN[ A-Z]*?PRIVATE KEY[a-zA-Z0-9/\+=\n-]*?END[ A-Z]*?PRIVATE KEY-----" \
    "$TARGET_DIR"

# Signed storage URLs
grep -Pir "storage.googleapis.com.*?Goog-Signature=[a-f0-9]+" \
    "$TARGET_DIR"

# Signed policy documents in HTML
grep -Pzr '(?s)<form action.*?googleapis.com.*?name="signature" value=".*?">' \
    "$TARGET_DIR"

References

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored