Incident response & forensics
Contain, snapshot, revoke, hunt persistence.
Cloud incident response is a race between the attacker and your ability to contain, understand, and evict them — run on infrastructure that is all API calls and short-lived credentials. The winning move is a rehearsed runbook that contains the threat without destroying the evidence you need to understand it.
Contain and preserve, in order
For a compromised GCE instance, quarantine it — apply a deny-all firewall rule via an isolation tag and remove it from load balancing — then snapshot its disk before any destructive action, rather than deleting and losing the evidence. For a compromised service account, disable or delete its keys and, because access tokens already minted remain valid until they expire, revoke active sessions and remove the SA’s bindings. Contain first, preserve second; a deleted instance answers no questions.
# 1. Quarantine the instance with an isolation tag bound to a deny-all rule.gcloud compute instances add-tags web-01 --tags=quarantine --zone=europe-west1-b# 2. Preserve evidence BEFORE anything destructive.gcloud compute disks snapshot web-01 --snapshot-names=ir-8891-evidence --zone=europe-west1-b# 3. Compromised SA: disable its keys and strip its access.gcloud iam service-accounts keys disable KEY_ID [email protected]gcloud projects remove-iam-policy-binding proj \--member="serviceAccount:[email protected]" --role="roles/editor"
Investigate, hunt persistence, recover
With the threat contained, reconstruct everything the identity did from Cloud Audit Logs (an aggregated sink means the evidence is intact even if the source project was owned), then hunt for persistence — a competent attacker plants a second way in. Look for new service-account keys, added IAM bindings, altered organization policies, new service accounts, resources created in unusual regions, and disabled logging or sinks. Rotate what was exposed, remove the footholds, rebuild clean, and only then reconnect. Rehearse the whole sequence as a drill.