BlogueCybersecurity
Cybersecurity

Google Cloud (GCP) Account Compromised: Complete Incident Response and Recovery Guide

Found unauthorized GCP projects, unexpected billing charges, or suspicious IAM activity in Google Cloud? This step-by-step guide covers immediate containment, investigating compromised service accounts and OAuth tokens, forensic analysis with Cloud Audit Logs, full remediation, and hardening your GCP environment against future attacks.

S

Sarah Chen

Senior Cybersecurity Engineer with 12+ years of experience in penetration testing and security architecture.

March 16, 2026
20 min de leitura

You notice a GCP project you did not create. Or your billing dashboard shows thousands of dollars of Compute Engine instances running in asia-east1. Or a security alert fires about a service account key being used from a location your team has never accessed. These are the telltale signs of a Google Cloud Platform account compromise — and every second you wait costs money and potentially exposes customer data.

GCP compromises are often more complex than AWS breaches because GCP's IAM model spans multiple layers: Google accounts, service accounts, Workspace users, OAuth applications, and organization-level policies all interact in ways that create many potential attack surfaces. This guide walks you through every layer of response, from the first five minutes to full recovery and hardening.

Understanding GCP's Unique Attack Surface

Before diving into response steps, it helps to understand how GCP compromises typically occur and what makes them distinct from other clouds:

  • Service account key leakage: GCP service account JSON key files are the most common compromise vector. These keys never expire unless explicitly rotated and grant whatever permissions the service account holds. A key file committed to GitHub can be exploited instantly by automated scrapers.
  • Metadata server SSRF: Like AWS, GCP instances have a metadata server at 169.254.169.254 and metadata.google.internal. A vulnerable application can be exploited to steal instance service account tokens.
  • OAuth token theft: Applications using Google OAuth can have tokens stolen, giving attackers access to Google Cloud APIs with the permissions of the authorized user.
  • Workload Identity Federation abuse: Misconfigured workload identity bindings can allow external identities to impersonate GCP service accounts.
  • Compromised Google account: If a team member's personal or organizational Google account is phished, the attacker inherits all their GCP project permissions.

Phase 1: First 15 Minutes — Stop the Attack

Step 1: Assess Your Account Structure

First, determine what you are dealing with. Navigate to the GCP Console → IAM & Admin → Resource Manager and review your organization and all projects. Navigate to Billing and look at current costs. If you see projects you did not create or costs spiking, you have an active incident.

Step 2: Disable or Delete Suspicious Service Account Keys

Service account key compromise is the most common GCP attack vector. Navigate to IAM & Admin → Service Accounts in every affected project. For each service account, click through to "Keys" and look for keys created recently or keys you do not recognize. Disable the key first (to preserve it for forensics), then delete it after logging the key ID.

Using the gcloud CLI to audit all service account keys across a project:

# List all service accounts in a project
gcloud iam service-accounts list --project=YOUR_PROJECT_ID

# List all keys for a specific service account
gcloud iam service-accounts keys list   --iam-account=SERVICE_ACCOUNT_EMAIL   --project=YOUR_PROJECT_ID

# Disable a specific key (preserves for forensics)
gcloud iam service-accounts keys disable KEY_ID   --iam-account=SERVICE_ACCOUNT_EMAIL   --project=YOUR_PROJECT_ID

# Delete a key after capturing its ID
gcloud iam service-accounts keys delete KEY_ID   --iam-account=SERVICE_ACCOUNT_EMAIL   --project=YOUR_PROJECT_ID

Step 3: Remove Unauthorized IAM Bindings

Navigate to IAM & Admin → IAM and look for principals you do not recognize — especially roles/owner or roles/editor assigned to external accounts (gmail.com accounts that are not team members, unknown service accounts, or allUsers / allAuthenticatedUsers).

# Get all IAM policy bindings for a project
gcloud projects get-iam-policy YOUR_PROJECT_ID   --format=json | python3 -c "
import json, sys
policy = json.load(sys.stdin)
for binding in policy.get('bindings', []):
    print(f"Role: {binding['role']}")
    for member in binding.get('members', []):
        print(f"  Member: {member}")
"

# Remove a specific binding (e.g., unauthorized owner)
gcloud projects remove-iam-policy-binding YOUR_PROJECT_ID   --member="user:attacker@gmail.com"   --role="roles/owner"

Step 4: Revoke OAuth Tokens and Application Access

Navigate to myaccount.google.com → Security → Third-party apps with account access for every affected Google account. Revoke access for any application you do not recognize. Also review Google Cloud Console → APIs & Services → OAuth consent screen to check for unauthorized OAuth applications that may have been registered.

Step 5: Disable Compromised Compute Engine Instances

If you have identified unauthorized Compute Engine instances, stop them immediately:

# List all instances across all zones in a project
gcloud compute instances list --project=YOUR_PROJECT_ID

# Stop a suspicious instance (preserves disk for forensics)
gcloud compute instances stop INSTANCE_NAME   --zone=ZONE   --project=YOUR_PROJECT_ID

# List all running instances across ALL projects in the organization
gcloud projects list --format="value(projectId)" | while read project; do
  echo "--- Project: $project ---"
  gcloud compute instances list --project=$project 2>/dev/null
done

Phase 2: First Hour — Full Scope Assessment

Step 6: Analyze Cloud Audit Logs

Cloud Audit Logs are GCP's equivalent of AWS CloudTrail. Navigate to Cloud Logging → Logs Explorer and query for suspicious activity. The most important logs are Admin Activity logs (always on, cannot be disabled) and Data Access logs (must be enabled).

# Using gcloud to query Admin Activity logs for recent IAM changes
gcloud logging read   'logName="projects/YOUR_PROJECT/logs/cloudaudit.googleapis.com%2Factivity" AND
   protoPayload.serviceName="iam.googleapis.com"'   --freshness=24h   --format=json   --project=YOUR_PROJECT_ID | python3 -c "
import json, sys
logs = json.load(sys.stdin)
for entry in logs:
    payload = entry.get('protoPayload', {})
    print(f"{entry.get('timestamp', 'unknown')} | {payload.get('methodName', 'unknown')} | {payload.get('authenticationInfo', {}).get('principalEmail', 'unknown')}")
"

# Query for compute instance creation events
gcloud logging read   'protoPayload.methodName="v1.compute.instances.insert"'   --freshness=72h   --format=json   --project=YOUR_PROJECT_ID

# Query for all project creation events (org level)
gcloud logging read   'protoPayload.methodName="CreateProject"'   --freshness=72h   --format=json   --organization=YOUR_ORG_ID

Step 7: Inventory All Resources and Projects

Attackers frequently create new GCP projects to hide their activity and avoid budget alerts on existing projects. At the organization level, list all projects:

# List all projects in your organization
gcloud projects list --filter="parent.id=YOUR_ORG_ID" --format="table(projectId,name,createTime,lifecycleState)"

# Look for recently created projects
gcloud projects list   --filter="createTime>2026-03-01"   --format="table(projectId,name,createTime)"

# Check all Cloud Run services (common for deploying malicious containers)
for project in $(gcloud projects list --format="value(projectId)"); do
  gcloud run services list --project=$project 2>/dev/null | grep -v "^Listed"
done

# Check Cloud Functions
for project in $(gcloud projects list --format="value(projectId)"); do
  gcloud functions list --project=$project 2>/dev/null | grep -v "^Listed"
done

Step 8: Check for Data Exfiltration via Cloud Storage

Navigate to Cloud Storage → Buckets and check for any buckets with public access. GCP has a concept of allUsers and allAuthenticatedUsers as special principals — any bucket granting read access to these is publicly readable by anyone on the internet.

# Check for publicly accessible buckets in a project
for bucket in $(gsutil ls -p YOUR_PROJECT_ID 2>/dev/null); do
  echo "Checking $bucket"
  gsutil iam get $bucket | python3 -c "
import json, sys
policy = json.load(sys.stdin)
for binding in policy.get('bindings', []):
    if 'allUsers' in binding.get('members', []) or 'allAuthenticatedUsers' in binding.get('members', []):
        print(f'  WARNING: Public access via role {binding["role"]}')
  " 2>/dev/null
done

Step 9: Check GKE Clusters and Kubernetes RBAC

If you use Google Kubernetes Engine, attackers may have modified RBAC policies or created new workloads. Check all GKE clusters:

# List all GKE clusters
gcloud container clusters list --project=YOUR_PROJECT_ID

# Get cluster credentials and check for unauthorized RBAC bindings
gcloud container clusters get-credentials CLUSTER_NAME --zone=ZONE --project=YOUR_PROJECT_ID
kubectl get clusterrolebindings -o wide
kubectl get rolebindings --all-namespaces -o wide
kubectl get pods --all-namespaces | grep -v "Running|Completed"

Phase 3: Identifying the Compromise Vector

Step 10: Trace Leaked Service Account Keys

Cloud Audit Logs will show you the key ID used to authenticate each request. Cross-reference the key IDs in your audit logs with the service account key list. If a key was used from an unexpected IP or location, that is your compromised key. Use this query in Cloud Logging:

gcloud logging read   'protoPayload.authenticationInfo.serviceAccountKeyName!=""'   --freshness=48h   --format=json   --project=YOUR_PROJECT_ID | python3 -c "
import json, sys
logs = json.load(sys.stdin)
for entry in logs:
    auth = entry.get('protoPayload', {}).get('authenticationInfo', {})
    req = entry.get('httpRequest', {})
    print(f"{entry.get('timestamp', '')} | Key: {auth.get('serviceAccountKeyName', '?')} | IP: {entry.get('protoPayload', {}).get('requestMetadata', {}).get('callerIp', '?')}")
"

Step 11: Check the Metadata Server Exposure

If a Compute Engine instance with access to a powerful service account was running a web application, SSRF via the metadata server is a likely attack vector. Check your instances' metadata server access configuration:

# Check if instances have the default compute service account (overly privileged)
gcloud compute instances list   --format="table(name,zone,serviceAccounts[].email)"   --project=YOUR_PROJECT_ID

# The default compute service account is PROJECT_NUMBER-compute@developer.gserviceaccount.com
# It has Editor role by default — this is a critical misconfiguration
# Fix: use a custom service account with only required permissions

Phase 4: Remediation and Full Recovery

Step 12: Delete Unauthorized Projects and Resources

For any project the attacker created, delete it. Navigate to Cloud Console → Resource Manager and find the unauthorized projects. Before deleting, take a record of all resources inside for the incident report. Then click Delete. Note that GCP project deletion is not immediate — projects enter a 30-day pending deletion period, but all resources are immediately inaccessible.

Step 13: Rotate All Service Account Keys

Rotate every service account key in every affected project, even ones you believe were not compromised:

# For each service account, create a new key and delete the old ones
# Step 1: Create new key
gcloud iam service-accounts keys create new-key.json   --iam-account=SERVICE_ACCOUNT@PROJECT.iam.gserviceaccount.com

# Step 2: Update your applications to use the new key

# Step 3: Delete old key(s)
gcloud iam service-accounts keys delete OLD_KEY_ID   --iam-account=SERVICE_ACCOUNT@PROJECT.iam.gserviceaccount.com

Better yet, transition away from service account keys entirely. Use Workload Identity for GKE, attached service accounts for Compute Engine, and the metadata server for local authentication. Service account key files should not need to exist in most modern GCP architectures.

Step 14: Reset All Google Account Passwords and Sessions

For all human users who had GCP access, require immediate password resets and revoke all active sessions. Navigate to Google Admin Console (admin.google.com) → Users → [user] → Security → Sign out of all sessions. Enable 2-step verification enforcement via admin policy for all users in your Workspace organization.

Phase 5: Billing Recovery

Step 15: Dispute Unauthorized Charges

Navigate to GCP Console → Billing → Reports and identify all charges from the attack period. Contact Google Cloud Support through the Support Console. Select billing as the topic and describe the security incident. Provide:

  • The dates the compromise was active and when you discovered it
  • Evidence from Cloud Audit Logs showing unauthorized resource creation
  • Confirmation that you have revoked all compromised credentials and cleaned up unauthorized resources
  • What preventive measures you have now implemented

Google Cloud's policy on fraudulent billing is similar to AWS: they consider credits on a case-by-case basis, and customers who respond quickly, cooperate fully, and implement proper security controls typically receive partial or full credits for unauthorized charges. Persistence is key — if the first support agent declines, escalate to a billing specialist.

Phase 6: GCP Security Hardening After Recovery

Organization-Level Controls

  • Enable Organization Policy Service constraints to prevent dangerous configurations: disable service account key creation (iam.disableServiceAccountKeyCreation), restrict public Cloud Storage access (storage.publicAccessPrevention), restrict resource location to approved regions (gcp.resourceLocations)
  • Enable Security Command Center (Premium tier) for comprehensive threat detection, vulnerability scanning, and compliance monitoring across your entire organization
  • Enable Cloud Asset Inventory to track all resources and their configurations with full change history

Service Account Security

  • Never use the default compute service account — it has Editor role on the entire project. Create custom service accounts with only required permissions
  • Prefer Workload Identity over service account key files — no keys means no key leakage
  • Set the organization policy to disable service account key creation entirely if your architecture supports it
  • Implement service account key rotation policies (maximum 90-day key age) using Cloud Scheduler and Cloud Functions if you must use keys

Logging and Detection

  • Enable Data Access audit logs for all critical services (IAM, Cloud Storage, BigQuery, Cloud SQL) — these are off by default and critical for forensics
  • Enable Security Command Center Threat Detection for event threat detection, container threat detection, and virtual machine threat detection
  • Set up Log-based alerts for: service account key creation, IAM policy changes, project creation, public bucket creation, firewall rule changes
  • Configure Cloud Monitoring budget alerts at 50%, 90%, and 100% of your expected spend

Access and Network Security

  • Enable BeyondCorp Enterprise or at minimum enforce context-aware access policies for GCP Console access
  • Require MFA (2-Step Verification) for all Google accounts with GCP access — enforce this via Google Workspace admin policy
  • Use VPC Service Controls to create security perimeters around sensitive resources and prevent data exfiltration
  • Enable Private Google Access and Private Service Connect to keep traffic off the public internet
  • Block the legacy metadata server endpoint (v1beta) and ensure all code uses the v1 endpoint with metadata-flavor: Google headers

A GCP compromise can spiral out of control faster than any other cloud because of the hierarchical resource model — one compromised organization-level owner account can create unlimited projects and run up unlimited costs. The controls above are not optional extras — they are the baseline security posture every GCP organization should have before going to production.

ZeonEdge provides GCP security assessments, incident response support, and security architecture design. If you need help securing your Google Cloud environment, contact our cloud security team.

Etiquetas

#GCP Security#Google Cloud Security#Incident Response#Service Account#Cloud Breach#IAM#Cloud Audit Logs#Cloud Security
S

Sarah Chen

Senior Cybersecurity Engineer with 12+ years of experience in penetration testing and security architecture.

Artigos relacionados

Cybersecurity

AWS WAF Rule Tuning: Eliminating False Positives While Blocking Real Attacks

AWS WAF blocks attacks but also breaks legitimate traffic. This guide covers tuning managed rule groups, writing custom rules, reducing false positives with Count mode, log analysis with Athena, and production hardening strategies that protect without breaking your application.

Sarah Chen•21 min de leitura
Cybersecurity

SSL/TLS Certificate Automation: Let's Encrypt, ACME, and Zero-Touch Certificate Lifecycle Management

Manual SSL certificate management causes outages. Automate the entire certificate lifecycle with Let's Encrypt, cert-manager, Caddy, and Vault PKI. Covers ACME protocol internals, wildcard certificates via DNS-01 challenge, internal PKI for private services, and monitoring expiry.

Sarah Chen•21 min de leitura
Cybersecurity

Oracle Cloud Infrastructure (OCI) Account Compromised: Complete Recovery Guide

Oracle Cloud Infrastructure accounts are increasingly targeted by attackers exploiting API keys, OCI CLI configuration files, and the Always Free tier. This detailed guide covers immediate containment using OCI IAM and policies, forensic investigation with Audit logs, recovery across Compute, Object Storage, and Database services, billing dispute steps, and full security hardening.

Sarah Chen•19 min de leitura

Pronto para transformar sua infraestrutura?

Vamos discutir como podemos ajudá-lo a alcançar resultados semelhantes.

Agendar consultoriaVer mais artigos