Investigating GCP Incidents

Investigating GCP Incidents

The completeness of a GCP investigation is decided before the incident, by which audit logs were enabled. The single most damaging mistake is reading an empty query result as "nothing happened" when the real answer is "that log category was never turned on." Establish visibility first; conclude second.

GCP's audit model is not AWS's and not Azure's. Two categories are always on and two are mostly off, and knowing which is which is the difference between a scoped investigation and a false all-clear.

When to Use

• Responding to a suspected compromise in a GCP project or organization
• Investigating a leaked or abused service-account key
• Working a Security Command Center, Event Threat Detection, or Chronicle alert
• Reconstructing a principal's activity across projects
• Scoping IAM policy or resource changes after a suspected privilege escalation

When NOT to Use

• The incident is in AWS — use investigating-aws-incidents; in Azure or Microsoft 365 / Entra — use investigating-azure-incidents or investigating-m365-entra
• Attacking GCP rather than investigating it — use exploiting-cloud-platforms
• A GKE cluster compromise specifically — start here for the cloud-plane view, then use defending-kubernetes for the cluster-plane
• Deciding whether an alert is even an incident — use triaging-security-alerts first

Establish Visibility Before You Conclude

GCP Cloud Audit Logs come in four streams, and their defaults are the whole game:

The consequence you must internalize: Data Access logging is off by default everywhere except BigQuery. So "did the attacker read the secret / download the bucket / exfiltrate the dataset?" is usually unanswerable from logs unless Data Access logging was enabled in advance. Do not report "no exfiltration occurred" — report "Data Access logging was not enabled, so read activity cannot be confirmed or ruled out." Those are different findings, and only one is honest.

Retention also differs by stream. Admin Activity and System Event land in the _Required bucket — 400 days, not configurable. Data Access and Policy Denied land in _Default — 30 days unless someone extended it or routed a sink to longer storage. Check the retention before assuming history exists.

# What audit config is actually in effect at the org / project level
gcloud organizations get-iam-policy ORG_ID --format=json | jq '.auditConfigs'
gcloud projects get-iam-policy PROJECT_ID --format=json | jq '.auditConfigs'

Reconstructing Activity

# Everything a principal did (Admin Activity is always present)
gcloud logging read \
  'protoPayload.authenticationInfo.principalEmail="attacker@example.com"' \
  --project=PROJECT_ID --freshness=30d --format=json

# IAM policy changes — the escalation signal
gcloud logging read \
  'protoPayload.methodName:"SetIamPolicy"' --freshness=30d --format=json

# Service-account key creation — persistence
gcloud logging read \
  'protoPayload.methodName="google.iam.admin.v1.CreateServiceAccountKey"' \
  --freshness=30d --format=json

Read the request fields, not just the method name. authenticationInfo carries the principal and, critically, whether a call was made as a service account via impersonation. requestMetadata.callerIp and callerSuppliedUserAgent locate the source; a gcloud user agent from an unexpected ASN on a service account is a strong signal.

Service-Account and OAuth Abuse

Service accounts are the center of most GCP incidents, because they hold durable credentials and are routinely over-privileged.

• Impersonation chains. iam.serviceAccounts.getAccessToken and ...signJwt/...signBlob let one principal act as another. Trace the chain: who impersonated what, and does the terminal identity hold more than the origin? This is GCP's primary lateral-movement and escalation primitive.
• Key creation is persistence — a user-managed key survives a password reset and an MFA change. Every CreateServiceAccountKey on a privileged SA during the incident window is a finding.
• OAuth grants and the Workspace boundary. A domain-wide-delegation grant lets a GCP service account act across Google Workspace; that crosses into investigating-m365-entra-style identity territory and is easy to miss from a pure-GCP view.

Follow Security Command Center, Don't Restart From Zero

If Security Command Center is enabled, Event Threat Detection has likely already correlated some of this — anomalous IAM grants, service-account key abuse, and exfiltration patterns surface as findings. Start from SCC findings to seed the timeline, then corroborate each against the raw audit logs rather than trusting the finding alone. SCC in the Standard tier is far thinner than Premium/Enterprise; confirm which tier is licensed before assuming a detection would have fired.