Google Cloud (gcloud) CLI in Cybersecurity: Power and Peril

The Google Cloud Command Line Interface (gcloud CLI) is a unified, primary tool used to create and manage Google Cloud Platform (GCP) resources directly from the terminal. While indispensable for developers, data engineers, and DevOps professionals, the gcloud CLI is equally critical for cybersecurity professionals. Whether conducting a cloud security assessment, performing incident response, or simulating an adversary during a red team engagement, gcloud is the definitive gateway to interacting with the GCP ecosystem.

Why is the gcloud CLI Important for Cybersecurity?

In modern cloud infrastructure, the physical perimeter is largely replaced by Identity and Access Management (IAM) and APIs. The gcloud CLI allows security teams—and threat actors—to rapidly interact with these APIs.

  1. Automation and Scalability: Security audits demand checking hundreds of projects, folders, and resources across an entire GCP Organization. The gcloud CLI easily integrates with Bash or Python scripts to automate compliance checks, drastically reducing the time required compared to navigating the Google Cloud Console.
  2. Granular Data Retrieval: The CLI provides deep, unabstracted control over services. It can output responses in JSON format (--format=json), which is ideal for piping into tools like jq to extract specific security configurations or identify anomalies.
  3. Living off the Land (LOLBins): For penetration testers and real-world attackers, the gcloud CLI is often already installed on developer workstations, CI/CD runners, or compromised Compute Engine instances. Attackers use it as a "living off the land" binary to enumerate permissions, escalate privileges, and exfiltrate data without bringing custom malware into the environment.
  4. Rapid Incident Response: During a security incident, responders can use gcloud to rapidly revoke compromised Service Account keys, isolate Compute Engine instances from the network, or query Cloud Logging to reconstruct an attack timeline.

Essential gcloud CLI Commands for Cybersecurity

Below are some of the most critical gcloud CLI commands used in cybersecurity contexts, categorized by their typical phase in an assessment or attack loop.

1. Initial Reconnaissance & Enumeration

When gaining access to a GCP environment (whether legitimately through an audit role or maliciously via compromised credentials), the first step is to establish identity, current project scope, and available permissions.

# Determine the currently authenticated active account
gcloud auth list
 
# View the current configuration, including default project and compute region
gcloud config list
 
# List all projects the active account has access to
gcloud projects list
 
# Get IAM policy for the current project to understand who has what access
gcloud projects get-iam-policy <project-id>
 
# List all Service Accounts in the current project
gcloud iam service-accounts list

2. Cloud Storage Enumeration and Exfiltration

Google Cloud Storage (GCS) buckets frequently suffer from misconfigurations leading to data leaks. Attackers use the CLI (or the bundled gsutil / gcloud storage commands) to find and exfiltrate sensitive data.

# List all Cloud Storage buckets in the current project
gcloud storage ls
 
# Recursively list all files and objects inside a specific bucket
gcloud storage ls gs://<bucket-name>/**
 
# Download/Exfiltrate an entire bucket to your local machine
gcloud storage cp gs://<bucket-name> /local/path/ --recursive

3. Compute and Infrastructure Reconnaissance

Understanding the compute layout helps identify accessible targets, open firewall rules, and potential lateral movement paths.

# List all Compute Engine instances, their zones, internal, and external IP addresses
gcloud compute instances list
 
# Describe all firewall rules to find overly permissive ingress (e.g., 0.0.0.0/0 allowing SSH/22)
gcloud compute firewall-rules list
 
# List all GKE (Kubernetes Engine) clusters
gcloud container clusters list

4. Privilege Escalation and Impersonation

Attackers rarely land with roles/owner or roles/editor. They look for specific permissions (like iam.serviceAccounts.actAs or iam.serviceAccountTokenCreator) to impersonate highly privileged Service Accounts.

# Generate a short-lived access token by impersonating another service account
gcloud auth print-access-token --impersonate-service-account=<sa-email>
 
# Run a specific command as an impersonated service account
gcloud compute instances list --impersonate-service-account=<sa-email>

The Danger of Cloud Misconfiguration

The flexibility of GCP comes with severe risks if not managed properly. A single misconfigured IAM binding can compromise an entire organization.

Here are the most dangerous GCP misconfigurations:

1. Overly Permissive Basic Roles (Editor and Owner)

Unlike predefined roles which offer granular permissions, GCP's "Basic roles" (roles/viewer, roles/editor, roles/owner) contain thousands of permissions across all GCP services. Assigning the Editor role to a Service Account or human user violates the principle of least privilege. If compromised, an attacker can deploy infrastructure, delete resources, and modify IAM policies (if Owner), leading to total environment takeover.

2. Publicly Accessible Cloud Storage Buckets

Data breaches caused by misconfigured Cloud Storage buckets are a constant threat. If a bucket's IAM policy grants roles/storage.objectViewer to allUsers or allAuthenticatedUsers, anyone on the internet can read its contents. Note that allAuthenticatedUsers means any Google account in the world, not just users authenticated within your organization.

3. Leaked Service Account JSON Keys

Service Account keys (.json files) are long-term credentials used for programmatic access to GCP. Developers sometimes accidentally commit these keys to public GitHub repositories or embed them in Docker images. Automated bots constantly scan for these leaked keys, and a compromised key can be used from anywhere in the world to access the GCP environment.

4. Compute Engine Metadata Server SSRF

GCP Compute Engine instances have an internal metadata server accessible at http://169.254.169.254/computeMetadata/v1/. Unlike AWS's older IMDSv1, GCP requires a custom HTTP header (Metadata-Flavor: Google) to query this service, which protects against most basic Server-Side Request Forgery (SSRF) attacks.

However, if an application has a severe SSRF vulnerability that allows an attacker to inject HTTP headers, they can query the metadata server to steal the temporary OAuth 2.0 access token of the attached Service Account.

# Stealing the token from a compromised VM (requires header injection via SSRF)
curl -H "Metadata-Flavor: Google" "http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token"

Analyzing Cloud Audit Logs

What are GCP Cloud Audit Logs?

Google Cloud provides detailed Cloud Audit Logs out-of-the-box. These include Admin Activity logs (configuration or metadata changes), Data Access logs (reading/writing user-provided data), System Event logs, and Policy Denied logs. For cybersecurity teams, these logs provide a tamper-evident, comprehensive history of API calls, identifying exactly who did what, where, and when.

Using gcloud for Log Analysis

The gcloud CLI allows incident responders to query these logs directly from the terminal without needing to write complex BigQuery SQL or navigate the Logs Explorer UI.

# Read the last 10 logs where a Service Account key was created
gcloud logging read "resource.type=service_account AND protoPayload.methodName=google.iam.admin.v1.CreateServiceAccountKey" --limit=10 --format=json
 
# Find Admin Activity logs for a specific user within a time frame
gcloud logging read "logName=projects/<project-id>/logs/cloudaudit.googleapis.com%2Factivity AND protoPayload.authenticationInfo.principalEmail=<user-email> AND timestamp>=\"2026-03-20T00:00:00Z\""
 
# Track attempts to modify IAM policies
gcloud logging read "protoPayload.methodName=SetIamPolicy" --limit=20

By querying specific protoPayload.methodName values, defenders can quickly spot indicators of compromise, such as an attacker granting themselves new IAM roles or generating backdoor Service Account keys.

Real-World Examples & The True Cost of Breaches

Cloud misconfigurations in GCP have led to severe compromises, often resulting in massive financial losses, mostly driven by data exfiltration or massive resource hijacking for cryptocurrency mining.

1. The Tesla Kubernetes Cryptojacking Breach (2018)

Security researchers discovered that Tesla's cloud environment was compromised by attackers running cryptocurrency mining malware. The attackers found an unsecured Kubernetes console (dashboard) that wasn't password protected. Within this dashboard, they found credentials for a GCP Service Account.

  • Impact: The attackers used the Service Account credentials to access a GCP Cloud Storage bucket containing highly sensitive telemetry data and automated vehicle data. Furthermore, they deployed mining pods across the cluster.
  • Cost: While exact figures were not disclosed, incidents of this scale incur immense costs regarding computing resources stolen, incident response, and reputational damage.

2. Extortion via Unsecured Database Backups

A common threat pattern in GCP involves developers backing up on-premise or cloud databases to Cloud Storage buckets but accidentally setting the IAM permissions to public (allUsers). Threat actors routinely scan public IP spaces and bucket names for these SQL dumps.

  • Impact: Once found, the attackers download the PII, financial data, or healthcare records, and send extortion emails threatening to release the data publicly unless a cryptocurrency ransom is paid.
  • Cost: Beyond the ransom itself, regulatory fines under GDPR or HIPAA for exposing sensitive data can range from millions to tens of millions of dollars per incident.

3. Widespread Service Account Key Leaks

According to threat intelligence reports, one of the most common ingress vectors for GCP compromises remains leaked Service Account JSON keys in public GitHub repositories.

  • Impact: Automated threat actors immediately instantiate dozens of maximum-capacity GPU instances (like A100s) for cryptocurrency mining using the compromised project.
  • Cost: Because cloud computing is billed per second, an undetected compromise over a single weekend can easily rack up an unexpected GCP bill of $50,000 to $100,000+ before the organization notices the spike in their billing dashboard.

Conclusion

The gcloud CLI is an extraordinarily powerful tool that serves as the interface for practically all actions taken within Google Cloud. While it empowers fast, scalable infrastructure management and auditing, it also provides attackers with everything they need to perform reconnaissance, escalate privileges, and steal data.

To protect GCP environments, security teams must proactively scan for misconfigurations, heavily restrict the use of basic IAM roles, enforce the use of short-lived credentials via Workload Identity or Service Account impersonation, and continuously monitor Cloud Audit Logs for suspicious API activity.

Love it? Share this article: