What Is Cloud Incident Response?

Why Cloud Incident Response Is Different

Traditional incident response assumes you can grab an artifact. Capture a disk image, pull memory, tap the network, and reconstruct what happened. In the cloud almost none of that holds. There is nothing to image on a Lambda function, no agent on a managed database, and no tap you can drop in front of an S3 bucket, and by the time you go looking, the auto-scaled instance that ran the malicious code may already be gone. What you have instead is logs: the API calls that every action in a cloud environment leaves behind. That single shift, from artifacts to log correlation, changes how the whole discipline works, and teams that walk in with on-premises instincts tend to lose the first half hour hunting for evidence that was never going to exist.

The other difference is identity. On a network you chase hosts. In the cloud you chase a principal, because the first question in almost every cloud incident is which identity is compromised and what can it reach. Get that wrong and you contain the wrong thing.

Critical Log Sources by Cloud Provider

Your investigation is only as good as the logging that was turned on before the incident, which is why pre-incident logging configuration is the single highest-leverage thing an IR team can influence.

AWS

CloudTrail is the backbone: management events by default, and data events for S3 and Lambda if someone enabled them. Pair it with VPC Flow Logs for network context and GuardDuty for managed detections. The gap that bites teams is CloudTrail data events, which are off by default, so the read of the exfiltrated object often is not there.

Azure

Entra ID sign-in and audit logs tell you who authenticated and what changed in the directory, while Azure Activity Logs cover control-plane operations. Microsoft Defender for Cloud adds detections on top. Watch especially for consent grants and service principal changes, since those are how attackers persist.

GCP

Cloud Audit Logs split into Admin Activity, which is always on, and Data Access, which mostly is not, so the same visibility gap applies. VPC Flow Logs and Security Command Center round out the picture.

Containment in the Cloud

Cloud containment demands a precision that physical response does not. Revoking every session for a compromised user sounds decisive, but it also kills every legitimate process running under that identity, and a production outage can cost more than the breach you are responding to. The goal is to stop the adversary without amplifying the incident. In AWS, an inline deny policy attached to the compromised principal is the scalpel: it blocks the attacker immediately, leaves everything else alone, and rolls back cleanly once the investigation is done. Azure uses Conditional Access scoped to the identity to the same effect. GCP relies on disabling keys and adjusting IAM bindings. Machine identities, which make up most cloud compromises, need extra thought, because rotating a service account key or disabling a managed identity can break a pipeline or take down an application tier, so document the blast radius before you pull the trigger.

Common Cloud IR Scenarios

A handful of incident types recur. Leaked long-term keys, usually from a public repository, followed by rapid enumeration and resource creation. Cryptomining, where an attacker spins up expensive compute in regions you do not normally use. Ransomware that abuses IAM and KMS to encrypt or delete data and backups. And straightforward data theft from a misconfigured bucket. Each has a signature in the logs, and knowing the signature is what turns a pile of CloudTrail events into a timeline.

Notable Cloud Incidents

Code Spaces, 2014

An attacker gained access to a company's AWS console, and when the team tried to wrest back control, deleted most of the infrastructure, backups included. Code Spaces did not survive it. A decade on, it remains the clearest lesson in why cloud console access and unprotected backups are an existential risk, and why containment has to be fast and deliberate.

Capital One, 2019

Server-side request forgery reached an over-permissioned EC2 role, which read more than 100 million records from S3. For responders it is a case study in identity-first triage, because the whole event is legible in CloudTrail if you follow the compromised role.

Uber, 2022

MFA fatigue and a hardcoded admin credential in a script gave an attacker broad internal access. The response hinged on spotting anomalous authentication and privileged actions quickly, exactly the kind of signal a tuned identity detection surfaces.

Evidence: What Disappears and What Persists

Cloud evidence falls into two buckets. Durable evidence such as CloudTrail, VPC Flow Logs, and Azure Diagnostic Logs persists in storage and can be analyzed long after the fact. Ephemeral evidence does not: Lambda execution environments, container instances, in-memory credentials, and active connections vanish when the compute does. The mistake that ruins a cloud forensic effort is treating a compromised instance like an on-premises server, taking a leisurely snapshot while the volatile context you actually needed evaporates. If you need forensic-grade evidence from a live instance, collect the volatile data before you isolate or terminate it.

Cloud IR Tooling

Most cloud IR happens in whatever platform holds the logs. CloudTrail Lake, Microsoft Sentinel, and Google Chronicle let you query and correlate at scale, and each has its own language, from KQL in Sentinel to YARA-L in Chronicle. Cloud-native services like Amazon Detective and GuardDuty help stitch events into a narrative, and open-source tooling fills gaps in acquisition and analysis. The tool matters less than the log coverage feeding it.

Related Labs

The fastest way to build cloud IR instinct is to work a real incident end to end. Pwned Labs scenarios such as Investigate a Ransomware Attack in AWS using Splunk and Breach in the Cloud put you in CloudTrail and SIEM data, following an attacker's trail rather than reading about it. Browse the full set at pwnedlabs.io/explore.

Practice Cloud IR with Pwned Labs

Our bootcamps pair attack with response, so you learn to investigate an intrusion in a live cloud environment after you have run the attack yourself. That order matters. When you have watched what an exfiltration looks like from the attacker's side, you recognize it far faster in the defender's logs. Explore the bootcamps at pwnedlabs.io/bootcamps.

Frequently Asked Questions

What is cloud incident response?

The process of detecting, investigating, containing, and recovering from security incidents in cloud environments, working primarily from API and identity logs rather than the disk and network artifacts used on-premises.

Why is cloud IR harder than on-premises IR?

Because much of the evidence is ephemeral. Serverless functions, containers, and auto-scaled instances disappear, so responders rely on logs that must have been enabled before the incident, and they have to move quickly.

What is the first step in a cloud incident?

Identity-first triage. Establish which principal is compromised and map every API call it made, using CloudTrail in AWS or Entra ID and Activity logs in Azure, before isolating resources or revoking access.

How do you contain a cloud incident without causing an outage?

Use surgical controls scoped to the compromised identity, such as an inline deny policy in AWS or a Conditional Access policy in Azure, rather than revoking everything. For machine identities, document the blast radius first.

Which logs matter most?

CloudTrail, VPC Flow Logs, and provider audit logs are the durable backbone. The common gap is data-access logging, which is off by default in AWS and GCP, so enable it before you need it.