CoursesGCP securityWorkload identity & IR

Incident response & forensics

Contain, snapshot, revoke, hunt persistence.

Expert35 min · lesson 15 of 15

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.

isolate, snapshot, revoke — in order
# 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 --iam-account=app@proj.iam.gserviceaccount.com
gcloud projects remove-iam-policy-binding proj \
--member="serviceAccount:app@proj.iam.gserviceaccount.com" --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.

GCP incident response phases
stop the bleeding
contain
quarantine tag, remove from LB, disable keys
preserve
disk snapshot before deleting
understand
investigate
reconstruct from Cloud Audit Logs
hunt persistence
new keys, bindings, org-policy edits
restore
eradicate + rotate
remove footholds, rotate secrets
recover
rebuild clean, then reconnect
Contain first, preserve second, understand third. Skipping persistence-hunting is how attackers walk back in an hour later.
Disabling the key is not revoking the token
Disabling a service-account key does not invalidate access tokens already issued from it — those remain valid until expiry. Remove the SA’s IAM bindings to cut what a live token can still do, and snapshot evidence before deleting any resource.