Sponsored

GCP - Compute Persistence

Compute

For more information about Compute and VPC (Networking), check:

GCP - Compute Enum

Persistence abusing instances and backups

[!CAUTION] Run these steps only in an approved assessment project. Use a benign marker instead of a callback or credential dump, and remove test metadata and resources after validation.

Backdoor an existing VM

On Linux VMs, the guest environment reads the startup-script metadata key and runs the script as root during boot. Public Compute Engine images include the guest environment; a custom image needs it installed for metadata scripts to run. VM-level startup metadata overrides a project-level startup script, so an unauthorized instance metadata change can re-establish a local change after later boots.[1]

Adding or updating that key on an existing VM requires compute.instances.setMetadata; the documented gcloud flow is instances add-metadata with either inline metadata or --metadata-from-file.[1][2] For an authorized test, point the key at a local script that writes a marker under a designated assessment path:

gcloud compute instances add-metadata VM_NAME \
  --zone=ZONE \
  --metadata-from-file startup-script=STARTUP_SCRIPT

Because the script is triggered during boot, reboot the test VM and verify the marker or inspect google-startup-scripts.service output. Do not put secrets in startup metadata: the script runs with root privileges and, when the VM has a service account, can use that workload identity.[1][6][7]

Backdoor disk images and snapshots

A snapshot can be copied to a new persistent disk, and a custom image can be created from a persistent disk, snapshot, or another image. In an authorized assessment, use a copy of the source snapshot, boot that copy on a temporary VM, make a benign filesystem change that represents the persistence mechanism, and capture the modified disk as a new image. Future VMs created from that image inherit the modified filesystem.[3][4][5]

gcloud compute disks create MODIFIED_DISK \
  --source-snapshot=SOURCE_SNAPSHOT \
  --zone=ZONE

gcloud compute instances create TEMP_VM \
  --zone=ZONE \
  --machine-type=MACHINE_TYPE \
  --disk=name=MODIFIED_DISK,boot=yes,auto-delete=no

After applying the approved marker or service change inside TEMP_VM, stop it before creating the image. Compute Engine does not create an image from a running instance by default; the documented --force option should be used only when intentionally capturing a live disk.[3]

gcloud compute images create PERSISTENT_IMAGE \
  --source-disk=MODIFIED_DISK \
  --source-disk-zone=ZONE

gcloud compute instances create TEST_VM \
  --zone=ZONE \
  --machine-type=MACHINE_TYPE \
  --image=PERSISTENT_IMAGE

Create a new accessible instance with a privileged service account

Code running on a Compute Engine VM uses the service account attached to that VM for Google Cloud authentication. IAM roles granted to the service account determine its resource permissions, while the VM's OAuth access scopes can further restrict requests made through gcloud and client libraries; cloud-platform does not grant permissions that the service account does not already have.[6] A principal creating the VM must also have iam.serviceAccounts.actAs on the service account, commonly through roles/iam.serviceAccountUser.[8]

For an authorized test, create a disposable VM with the selected service account and the scope required by the test.[5][6]

gcloud compute instances create PERSISTENT_VM \
  --zone=ZONE \
  --machine-type=MACHINE_TYPE \
  --image-family=IMAGE_FAMILY \
  --image-project=IMAGE_PROJECT \
  --service-account=PRIVILEGED_SERVICE_ACCOUNT \
  --scopes=cloud-platform

Applications on the VM can use Application Default Credentials or request an access token from the metadata server. Validate the attached identity without exposing a token by querying the service-account directory from inside the test VM:[7][9]

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

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