GCP audit logs analysis: step by step in your browser

TL;DR. Export the audit logs as JSON (not CSV), drop every file on the GCP Forensics page, check the "period covered" and the warnings, then read the verdict, the findings with their evidence, the timeline and the checklist, in that order. Pivot on the attacker's IP and service account key in the Entities tab. Everything runs locally in a Web Worker: the logs are not uploaded.

This is the hands-on companion to the incident response guide. If you just want to see the output first, press Try a sample on the tool page: it loads a fictional incident, walked through in the fictional case study.

Step 1: export the logs as JSON

The analyzer reads what Google Cloud produces, as long as it is JSON:

Include all four audit log types and VPC Flow Logs if they exist. The details, including the 10,000-entry cap of the console download, are in Cloud Audit Logs explained. Logs Explorer CSV downloads and BigQuery Avro or Parquet exports are rejected with an explanation; re-export as JSON.

A useful minimum for a single project over 30 days:

gcloud logging read 'logName:"cloudaudit.googleapis.com" OR logName:"vpc_flows"' \
  --project=PROJECT_ID --freshness=30d --format=json | gzip > project-logs.json.gz

Step 2: drop the files

Open the analyzer and drop the files, choose them with Choose files, or pick a whole folder with Choose a folder. ZIP archives are read entry by entry without being extracted to disk, .gz files are decompressed by the browser, and large exports are streamed in chunks so memory stays bounded.

The parser is Rust compiled to WebAssembly, running in a Web Worker. Your logs contain e-mail addresses, IP addresses and resource names; they stay on your machine. You can disconnect from the network after the page has loaded.

Step 3: check what was actually read

Before trusting any verdict, read the summary line: period covered, log entries, files, principals and flow records. Then the notices:

• Files not analyzed, each with a reason (empty file, CSV download, not JSON, corrupt gzip, unreadable ZIP).
• No Data Access audit logs in this export: reads of data are invisible, so "no exfiltration finding" means nothing. See Data Access logs limitations.
• Hand-offs: GKE / Kubernetes API audit entries are set aside for Kubernetes Forensics and Google Workspace audit entries for Google Workspace Forensics.

If the period does not cover the suspected intrusion, stop and export more.

Step 4: read the verdict and its reasons

The verdict policy is in the published rules file:

"Clean" is not proof of absence; it only covers the logs you dropped. The reasons listed under the verdict are links to the findings that drove it.

Step 5: review the findings and their evidence

Each finding shows its severity, its kind (rule, threshold, analytic or correlation), the tactic, the MITRE ATT&CK technique IDs, the targets (a key ID, an IAM change such as ADD roles/owner user:x@gmail.com, a bucket) and the evidence entries with the original JSON.

The detections cover, among others:

• Credentials: CreateServiceAccountKey, uploaded keys, a key used from a public IP, a key used from an IP it had never used before, token minting through the IAM Credentials API, bursts of permission-denied calls. See leaked service account key and impersonation.
• IAM: Owner / Editor / IAM admin grants, Gmail accounts, unknown domains, allUsers. See SetIamPolicy abuse.
• Compute: startup scripts, SSH keys, OS Login removed, GPU VMs, bursts of VM creation, VMs in never-used regions, firewalls opened to 0.0.0.0/0. See Compute Engine abuse.
• Data: bulk storage.objects.get, public resources, BigQuery copies to other projects, shared images and snapshots, large egress in flow logs. See GCS and BigQuery exfiltration.
• Anti-forensics: sinks, exclusions, log buckets, logs, Data Access logging, Security Command Center notifications. See defense evasion.

The full list, with severities and ATT&CK IDs, is in the rules table.

Step 6: rebuild the timeline and pivot

The Timeline tab orders flagged activity and findings by time. The Entities tab lists principals (with type: service account, user, personal Gmail, Google service agent; and impersonation chains), service account keys (with creator and IPs), caller IPs (with the bytes exchanged in VPC Flow Logs), projects and resources. One click on any of them filters the Events table to that entity.

The two pivots that solve most cases:

1. The attacker IP. Everything it did, across every identity it used.
2. The key ID. Where the key was created, by whom, and every IP that used it.

Switch between UTC and local time as needed; keep UTC in your report.

Step 7: work through the checklist and export

The Checklist tab turns the findings into ordered actions: declare an incident and preserve logs, block IPs, remove IAM bindings, disable keys, rebuild VMs, restore logging. Tick items as you go (the ticks are not saved).

Export the events as CSV (cells that could be read as spreadsheet formulas are neutralised) or the whole result as a JSON report for your case file.

Limits to keep in mind

• Heuristics point; they do not prove. A CI provider using a key from its own IPs will trigger "key used from a public IP".
• Thresholds are fixed in the rules file (for example 100 object reads in 10 minutes, 20 denied calls in 10 minutes, 1 GiB to one external IP).
• Routine events are listed up to 100,000 in the table; flagged ones are always kept, and detections cover every entry.

Further reading

• Cloud Audit Logs overview — Google Cloud documentation.
• Respond to compromised Google Cloud credentials — what to do with the findings.
• A GCP compromise walkthrough (fictional case study) — the sample, explained.