Your on-prem incident response runbook assumes you can pull a disk, image RAM, and unplug a cable. In AWS, Azure and GCP, none of those moves exist the way you remember them. This guide puts the three providers side by side so your team knows which evidence to grab, in what order, before the attacker's activity ages out of your logs.
Why do on-prem incident response playbooks break in the cloud?
On-prem playbooks assume physical access, static hosts, and a network perimeter you control. In the cloud the control plane is the perimeter, hosts are ephemeral, and most evidence lives in provider logs that expire. A step that says to image the machine fails when the instance auto-scaled away an hour ago.
- ▸The control plane is the new attack surface. A stolen access key or OAuth token lets an attacker act through the provider API without ever touching an operating system, so your EDR sees nothing.
- ▸Compute is ephemeral. Auto Scaling groups, spot instances, and serverless functions disappear, taking local artifacts with them.
- ▸Evidence is retention-bound. If audit logging was never enabled, the timeline may already be gone.
- ▸Blast radius is identity-shaped. One over-permissioned role can pivot across every service in the account.
For the AWS-specific version of this problem, see Cloud Incident Response: Why On-Prem Playbooks Fail in AWS, and Incident Response Playbooks That Teams Actually Use for runbook structure.
What cloud-native evidence sources should you collect first?
Collect control-plane audit logs, identity sign-in logs, and network flow logs first, because they expire and cannot be recreated. Then snapshot affected disks and preserve any function or container logs. Grab the volatile, retention-bound records before you touch anything an attacker might be watching.
- ▸Control-plane and management logs record every API call: who, what, when, and from which IP.
- ▸Identity logs capture sign-ins, MFA challenges, token issuance, and consent grants.
- ▸Network flow logs give source, destination, ports, and bytes for lateral-movement mapping.
- ▸Storage and disk snapshots provide point-in-time copies for offline forensics.
- ▸Resource configuration history shows what changed, and when.
Anchor every observation to a framework your team already knows, such as NIST SP 800-61 and the SANS PICERL phases, and map attacker actions to the MITRE ATT&CK cloud matrix.
How does AWS incident response differ from a data center?
In AWS your primary evidence is CloudTrail for API calls, GuardDuty for detections, VPC Flow Logs for network, and AWS Config for resource history. You contain by isolating with security groups and revoking IAM sessions, then capture EBS snapshots for forensics. Exposed keys and IMDSv1 are recurring root causes.
- ▸CloudTrail is the system of record for control-plane activity; confirm it is multi-region and shipping to a locked, versioned S3 bucket.
- ▸GuardDuty flags credential exfiltration, crypto-mining, and anomalous API use.
- ▸VPC Flow Logs and Route 53 DNS query logs reconstruct network behavior.
- ▸Contain with EBS volume snapshots, AWS Systems Manager for live triage, and IAM session revocation by attaching a deny-all policy and rotating keys.
- ▸A frequent root cause is exposed long-lived access keys or an IMDSv1 SSRF leaking instance-role credentials; enforce IMDSv2.
- ▸For after-action config review, run Prowler and ScoutSuite.
What are the Azure-specific evidence sources and gotchas?
In Azure, evidence spans two planes: the Azure Activity Log for resource operations and Microsoft Entra ID logs for sign-ins and audit. Microsoft Sentinel and Defender for Cloud centralize detections. The classic gotcha is that Entra sign-in retention is short unless you export it, and consent-grant abuse hides in the audit log.
- ▸Azure Activity Log captures subscription-level control-plane operations.
- ▸Microsoft Entra ID (formerly Azure AD) sign-in and audit logs are the identity crime scene; watch for illicit OAuth consent grants and token theft.
- ▸Microsoft Sentinel (SIEM) and Microsoft Defender for Cloud drive detection and hunting.
- ▸Snapshot managed disks, and rely on Azure Monitor diagnostic settings that must be enabled in advance.
- ▸Gotcha: default retention. Export sign-in logs to a Log Analytics workspace or they age out before you investigate.
How do you run incident response in Google Cloud?
In Google Cloud, Cloud Audit Logs split into Admin Activity, which is always on, and Data Access, which is off by default and should be enabled now. Cloud Logging, VPC Flow Logs, and Security Command Center supply detection and network context. Contain by disabling service-account keys and quarantining with firewall rules, then snapshot persistent disks.
- ▸Cloud Audit Logs: Admin Activity is on by default, but Data Access logs are off by default and are often exactly the ones you wish you had.
- ▸Security Command Center surfaces findings, misconfigurations, and threat detections.
- ▸VPC Flow Logs and Cloud Logging carry network and application evidence.
- ▸Contain by disabling or rotating service-account keys, revoking OAuth tokens, and applying restrictive firewall rules; capture persistent disk snapshots.
How do you contain a compromised cloud identity without breaking production?
Contain identity compromise at the token and policy layer, not the network. Revoke active sessions, rotate the exposed credential, and attach an explicit deny to the principal, then verify no automation depended on it. Killing an over-used service account blindly can cause a worse outage than the attacker would.
- ▸Revoke sessions and tokens, then rotate keys and secrets.
- ▸Attach an explicit deny: an AWS SCP or IAM deny, an Entra conditional-access block, or a GCP deny policy.
- ▸Check dependencies before disabling shared service accounts.
- ▸Preserve the credential's usage log before rotation, so you keep the evidence of what it did.
Which DFIR tools work across AWS, Azure and GCP?
Cross-cloud DFIR leans on open-source collectors like Velociraptor, GRR, and KAPE for host artifacts, plus Cado and native snapshot APIs for automated disk capture. Treat your tooling as part of the threat model: security vendors have reported ransomware actors repurposing Velociraptor itself for remote access.
- ▸Velociraptor and GRR handle endpoint hunting and collection; KAPE does targeted artifact triage.
- ▸Cado and provider snapshot APIs enable automated, scalable acquisition.
- ▸Caution: public reporting, for example from Huntress, has documented threat actors abusing legitimate DFIR tooling such as Velociraptor for persistence and remote access; verify binary provenance and restrict who can deploy it.
- ▸Go deeper in Forensic Triage at Scale with Velociraptor and KAPE and Memory Forensics in Practice: From Acquisition to Answers.
How do you prepare before the incident?
Preparation decides most cloud IR outcomes. Enable and centralize audit logging with long retention, pre-stage break-glass roles and snapshot permissions, and rehearse a cloud-specific tabletop. If Data Access logs are off or CloudTrail is single-region on the day of the incident, you have already lost the timeline.
- ▸Turn on and centralize CloudTrail (multi-region), Entra and Activity log export, and GCP Data Access logs.
- ▸Set retention to 365 days or more in immutable or locked storage.
- ▸Pre-authorize break-glass IR roles and snapshot permissions so responders are not blocked.
- ▸Pressure-test the control plane before an attacker does, as covered in Red Teaming the Cloud Control Plane.
How TuniCyberLabs helps
We build cloud-specific incident response playbooks for AWS, Azure and GCP, wire up the logging and detections that make evidence survive, and run the tabletop that proves your team can execute under pressure. Our engineers handle incidents across all three major providers for clients in the EU and North Africa.
Start with a cloud IR readiness review: talk to our team.