Cloud Incident Response

Cloud Incident Response Cheatsheet

A cloud-agnostic guide and reference for cloud incidents across AWS, Azure, GCP, Docker/containers. Know which logs exist, whether they were on by default, how long they are kept, and how to obtain them.

AWS - Azure - GCP - ContainersdomainsMapped to MITRE ATT&CKCC BY 4.0

Choose a section

Start with the guide below, or jump to the cheat sheet, threat intel, or training & resources.

Cheat sheet
Filter the log catalog by provider, and open the per-provider cheat sheets (logs, threat matrix, IR plan, incidents).
Threat intelligence
Diamond Model, ATT&CK mapping, and how threat actors abuse the cloud.
Training & Resources
Courses and free/open-source references, grouped by cloud forensics, detection & threat hunting, and architecture & infra security.

Why cloud IR is different

You do not own the infrastructure

Under the shared responsibility model you investigate through provider APIs and logs, not by touching hardware.

Evidence is logs, not disk

A cloud intrusion is a sequence of API calls. Control-plane logs are the backbone.

Logs are never retroactive

Many sources are off by default. If it was not enabled before the incident, that data does not exist.

Identity is the perimeter

Most intrusions are valid-account abuse, not host exploits. Attacker activity looks like normal API calls.

Resources are ephemeral

VMs and containers vanish on redeploy; incidents span regions and multiple accounts.

API-driven, so it scales

One set of credentials can enumerate or destroy across a tenancy in minutes - and so can your response.
The one rule
Logs are never retroactive. If a source was not enabled before the incident, that data does not exist.
Before an incident: have a retainer
Cloud incidents move fast and access is everything. Engaging a retained incident-response provider (for example, IBM X-Force) before an incident means responders, contracts, and access are ready on day zero rather than negotiated mid-crisis - and it pairs with turning on the logs this cheat sheet says are off by default.

Do / Don't

Do

  • Establish the logging posture first - know what exists before assuming it does.
  • Get authorised, read-only access and record your own activity (it lands in the logs).
  • Preserve short-retention and data-plane logs early, before they age out.
  • Scope the identity: what it could do, and who can assume or reach it.
  • Enable off-by-default sources now to capture ongoing activity.
  • Correlate control-plane, sign-in, data-plane, and network logs into one timeline.

Don't

  • Do not assume a log exists - many are off by default and none are retroactive.
  • Do not treat cloud like on-prem: there is rarely a disk to image; evidence is API logs.
  • Do not ignore identity - most intrusions are valid-account abuse, not host exploits.
  • Do not run enumeration from an unlogged or over-privileged principal.
  • Do not promise a timeline the retained data cannot support.
  • Do not overlook OAuth grants, federation trust, and service-account keys.

Key steps of a cloud investigation

  1. Get authorised, read-only access. An IR principal scoped to the affected accounts; record your own activity.
  2. Establish the logging posture first. What is being collected, where it is routed, how long it is kept.
  3. Preserve evidence before it ages out. Short-retention and data-plane logs go first.
  4. Scope the identity and blast radius. What the identity could do, and who can reach it.
  5. Reconstruct the timeline. Correlate control-plane, sign-in, data-plane, and network logs.
  6. Contain. Revoke sessions and keys, rotate secrets, remove OAuth grants and inbox rules, tighten trust.
  7. Eradicate and recover. Remove footholds; restore from clean/immutable backups.
  8. Improve visibility. Enable off sources now to capture ongoing activity; feed findings into detections.

The domains

The same domains apply across every provider, so the investigative questions stay the same even when service names change.

Identity & Access

Human + non-human identities, sign-in / authentication, MFA, federation & SSO trust, role/permission grants, OAuth app consent, token & session activity. Covers credential/session revocation and non-human identity (NHI) inventory.

Control Plane & Management Activity

All management-plane API activity (Console/GUI, CLI, SDK). Audit-log architecture, log-tampering & immutability, resource/config changes, org-policy and tenant hierarchy changes, service enumeration.

Workloads & Runtime

Compute & runtime: VMs, serverless, containers/Kubernetes. Instance metadata (IMDS) access, runtime threat detection, image trust, cryptojacking / resource hijacking, lateral movement to hosts.

Network & Connectivity

Ingress/egress & lateral traffic: VPC flows, DNS, load balancers, WAF, firewall rules. Edge exploitation, C2/tunnelling, DDoS, exfil-over-network detection.

Data Services & Storage

Object/blob storage, databases, data warehouses, key-management. Data-plane (object-level) logging, cross-account shares, snapshots, immutable backups, mass-read / ransomware / destruction.

DevSecOps & Pipelines

CI/CD pipelines, source repos, artifact registries, secrets in build. OIDC/federated build identities, supply-chain & dependency tampering, malicious workflow, pipeline secret theft.

SaaS & Collaboration Platforms

SaaS & collaboration: M365 / Google Workspace / Okta / GitHub org. Mailbox & file audit, OAuth-app abuse, inbox/forwarding rules, refresh-token replay, helpdesk-reset abuse.

AI/ML Services

Managed AI/ML: model invocation, training-data buckets, inference endpoints, guardrails. Model/data exfil, prompt injection, abuse of stolen API keys (detect via cost anomalies), poisoning.

Why IAM is the centre of it

Nearly every cloud incident starts with a valid identity and every containment action is an identity action. Two questions recur: what could this identity do (effective permissions and escalation paths - the blast radius) and who can assume or reach it (trust relationships - how attackers move and persist). The identity types are searchable in the catalog.

Contributors

Erblind Morina
Principal Incident Response Consultant / Cloud IR Lead
IBM X-Force
Main contributor
Giacomo Casoni
Senior Incident Response Consultant
IBM X-Force
Andi Ahmeti
Security Researcher
Permiso
Abian Morina
Security Researcher
Permiso
Want to be part of it?
Anyone can join. Open a pull request that fixes a fact, adds a log source or tool, contributes a talk or resource, or improves a page - and add yourself to the contributors. New maintainers are welcome; if you want to help curate a section (a provider, detection content, or training), say so in your PR or open an issue on GitHub.