Skip to main content

GCP Compute Engine instance created with elevated privileges

ID:gcp_compute_engine_elevated_privileges
Data type:GCP Audit Logs
Severity:
Low
MITRE ATT&CK:TA0004:T1078.004

Description​

AlphaSOC detected the creation of a GCP Compute Engine instance by a principal holding a dangerous combination of permissions that enables privilege escalation via the compute.instances.insert action. The principal has all of the following permissions: compute.disks.create, compute.instances.create, compute.instances.setMetadata, compute.instances.setServiceAccount, compute.subnetworks.use, and compute.subnetworks.useExternalIp.

This permission set enables a privilege-escalation path similar to AWS iam:PassRole combined with ec2:RunInstances. Specifically, compute.instances.setServiceAccount allows the principal to attach arbitrary service accounts to newly created instances, including service accounts with higher privileges than the principal itself.

After instance creation, an attacker can execute code via startup scripts, SSH access, or workload execution and retrieve OAuth tokens from the instance metadata server, thereby inheriting the full permissions of the attached service account.

Impact​

If exploited, this privilege escalation path allows threat actors to inherit the full permissions of any service account they can attach to a compute instance. Attackers can leverage this elevated access to perform unauthorized actions across GCP services, access sensitive data in Cloud Storage buckets, modify infrastructure configurations, create additional resources, or exfiltrate credentials and secrets.

The escalated privileges enable lateral movement within the GCP environment, allowing adversaries to compromise additional projects, enumerate cloud resources, and establish persistent access through new service accounts or SSH keys. Because the escalation occurs through legitimate compute instance creation, the malicious activity blends seamlessly with normal operational patterns, making detection more difficult.

Severity​

SeverityCondition
Low
GCP Compute Engine instance created with elevated privileges

Investigation and Remediation​

Review GCP audit logs to identify the compute.instances.insert event and examine the authorization information to confirm which permissions were granted to the principal. Identify the specific Compute Engine instance that was created, including its name, zone, and project. Determine which service account was attached to the instance by examining the instance configuration and assess the permissions and roles assigned to that service account. Verify the principal (user account or service account) that performed the instance creation and check the source IP address and user agent to confirm whether the activity originated from authorized infrastructure or expected personnel. Examine the instance metadata, particularly startup scripts, to identify any malicious code that may have been injected to exfiltrate credentials, establish backdoors, or execute unauthorized commands.

If the activity appears malicious, immediately delete the compute instance to prevent further privilege escalation and stop any running processes that may be leveraging the escalated permissions. Review the attached service account's recent activity logs to identify what actions were performed with the escalated privileges and assess the scope of potential compromise. Disable or delete the compromised principal's credentials and rotate any service account keys that may have been exposed. Audit IAM policies to identify how the principal obtained this dangerous combination of permissions and implement least-privilege principles by restricting compute.instances.setServiceAccount and compute.instances.setMetadata permissions to only essential administrative roles. Configure Organization Policy constraints to restrict service account attachment capabilities and implement IAM Conditions to limit instance creation to specific service accounts or zones. Set up Cloud Monitoring alerts for future instance creation events that include service account attachments, particularly when performed by non-administrative users or from unexpected locations.

Known False Positives​

  • Authorized administrators creating compute instances as part of legitimate infrastructure deployment
  • Infrastructure-as-code tools (Terraform, Deployment Manager) creating instances with attached service accounts
  • CI/CD pipelines deploying application environments with specific service account permissions
  • Managed instance groups creating instances with predefined service accounts

Further Reading​