Cloud Incident Response Guide

Cloud incidents move faster than most incident response plans, and the evidence that explains them often does not exist unless someone enabled it months earlier. An attacker with a leaked access key can start crypto miners, copy a storage bucket or delete backups through the provider's API in minutes, without touching a server you could image. This guide covers what changes when the incident is in AWS, Microsoft Azure and Entra ID, or Google Cloud: preparation, the log sources that matter, containment of identities and workloads, forensic acquisition, recovery and working with the provider. It is for security operations, incident responders and cloud platform teams, and assumes the general process in the Incident Response Guide.

Key takeaways

• Most cloud incidents are identity incidents. The control plane is reachable from the internet with valid credentials, so containment usually means revoking sessions and keys before isolating any machine.
• Logging is a preparation task, not a response task. Data-level logs such as S3 data events, Google Cloud Data Access logs and Azure resource logs are off by default, and Entra sign-in logs last 30 days at most without export.
• Build the response access before you need it. Pre-provisioned IR roles, a separate forensics account or project, and tested emergency access are what let a team act in the first hour.
• Preserve before you destroy. Protect from termination, snapshot disks and capture memory before isolating or deleting a compromised instance, because cloud resources can vanish with a single API call.
• Know the provider's role. Under shared responsibility the provider will not investigate your account for you, but AWS CIRT, Google Cloud Customer Care and Microsoft Incident Response can help when engaged through the right channel.

How cloud incidents differ

The AWS Security Incident Response Guide sorts cloud incidents into three domains: the service domain (the account, IAM permissions, resource metadata and billing), the infrastructure domain (data and processes on instances, VPC traffic, containers) and the application domain (code and software you deploy). Response in the service domain "is typically done by reviewing and issuing API calls", and you never touch an operating system. The same split applies to Azure and Google Cloud.

Preparation: logging

NIST SP 800-61 Rev. 3 places preparation under the Govern, Identify and Protect functions of CSF 2.0, and in cloud this is where most investigations are won or lost. AWS calls CloudTrail, VPC Flow Logs and Route 53 Resolver query logs "the basic logging trifecta" for investigations. The joint ASD, CISA, NCSC-UK and partner guidance on event logging adds the operating principles: an approved logging policy, centralised collection and correlation, secure storage with integrity protection, and detection aimed at relevant threats.

• Centralise outside the blast radius: ship logs to a dedicated log archive account, subscription or project that workload administrators cannot modify. Attackers who reach the control plane often stop trails or delete diagnostic settings (ATT&CK T1685 Disable or Modify Tools, Defense Impairment).
• Retention matches detection time: AWS notes customers generally keep 3 to 12 months of logs queryable and up to seven years in archive. Entra states that expired data "can't be recovered unless it was previously archived". See the Log Management and Retention Guide.
• Make logs queryable: Athena, CloudWatch Logs Insights, Log Analytics (KQL) or BigQuery, with saved queries for the scenarios below. Time to first query is a real metric.

Preparation: access, accounts and playbooks

• Dedicated IR roles: pre-create read-only investigation roles and a separate containment role in every account, subscription and project, reachable through federation with phishing-resistant MFA. AWS advises that incident response users be "restricted, monitored, and not used for daily activities", with approval flows or credentials retrieved from a vault.
• Emergency access: if the identity provider itself is compromised, responders need a path in that does not depend on it: cloud-only emergency accounts in Entra ID, protected AWS root credentials for the management account, and dedicated Google Cloud super administrator accounts that are not used day to day. See the Break-Glass Account Guide.
• Forensics account or project: AWS recommends a forensics organisational unit with one account, or one per Region, created "well ahead of an incident", plus a security tooling account. The same pattern works as an isolated Azure subscription or Google Cloud project with no internet egress, pre-approved to receive snapshots and holding the analysis tooling.
• Isolation playbooks: write and test the exact steps for each provider: an isolation security group or network security group, a deny-all policy, snapshot commands and encryption key sharing. AWS describes tag-driven automation where applying a quarantine tag triggers acquisition and isolation.
• Scenario playbooks: at minimum leaked access key, compromised human admin, compromised workload or OAuth app, crypto mining, storage data theft, and ransomware or mass deletion. Microsoft publishes playbooks for phishing, password spray, app consent grant and compromised applications that are good templates for the Entra side.

The identity dimension is central here: the service accounts, access keys, service principals and managed identities your workloads use are the credentials most often leaked and the hardest to rotate under pressure. Inventory them, know their owners, and know which can be revoked without an outage. See the Cloud Workload Identity Guide and the Cloud PAM and CIEM Guide.

Detection sources and triage

Native detection services (GuardDuty, Microsoft Defender for Cloud and Entra ID Protection, Security Command Center) and billing anomalies raise most alerts, but the investigation runs on the audit logs. Triage answers four questions quickly: which principal, which credential type (long-term key, role session, user token, service principal secret), from where, and what it did across every Region and account.

Speed matters: the Amazon AWS crypto-mining campaign had miners running within about ten minutes of access, and the Codefinger S3 ransomware used stolen keys to encrypt buckets with AWS's own server-side encryption. For keys found in public code, follow the Leaked Credential Response Playbook.

Containment

AWS describes three containment categories: source (filter and route to block a source), technique and access (remove the access being abused) and destination (filter and route to protect the target). In the service domain, technique and access containment is almost always first. Weigh the factors NIST lists: potential damage, need to preserve evidence, service availability, time and resources, effectiveness and duration. Avoid visible actions before you have scoped the attacker's footholds, or you will contain one key while they still hold three others.

• Role session revocation is time-based: the AWS revoke action denies sessions issued before roughly 30 seconds after you click, affects every user of the role, cannot be used on service-linked roles, and does not touch IAM user long-term keys, which need deactivating separately. IAM Identity Center sessions are revoked in Identity Center.
• Tokens outlive passwords: Entra access tokens last about an hour by default, and Entra cannot revoke session tokens issued by downstream applications. Pair session revocation with a password reset, MFA re-registration review and removal of attacker-added methods.
• Security groups and existing connections: changing an AWS security group may not cut connections it is already tracking, while network ACLs are stateless and apply immediately. Use both for a reliable cut.
• Disable before delete: Microsoft's compromised application playbook disables the service principal first so the team can evaluate it; deleted Entra apps can be restored for 30 days, and a deleted consented app can return if a user consents again.

Evidence collection and forensics

The AWS guide gives a sequence for an EC2 instance that translates to any provider:

1. Record instance metadata: ID, type, IP addresses, VPC and subnet, image, security groups, attached role or identity, launch time.
2. Protect it: enable termination protection and turn off Delete on Termination for attached volumes (Azure: resource locks; Google Cloud: deletion protection).
3. Snapshot every disk (EBS snapshots, Azure managed disk snapshots, Compute Engine persistent disk snapshots) and copy them into the forensics account or project, sharing the encryption key where disks use customer-managed keys.
4. Capture memory before isolation or shutdown: "It is essential to capture memory before live response activities or system isolation or shutdown." Snapshots only hold data written to disk.
5. Only then isolate, and decommission or relaunch the image in an isolated sandbox for observation.

• Logs are evidence too: export the relevant CloudTrail, Activity log, Entra and Cloud Audit Logs records to write-once storage in the forensics account, with hashes, before retention windows close.
• Chain of custody: record who acquired what, when and with which API call. SP 800-61 Rev. 3 notes formal chain of custody might not be performed for every incident; decide early whether litigation or law enforcement is likely.
• Automation has limits: AWS's own automated forensics pattern states it does not intend to produce artefacts "submissible in court". Treat automated collection as triage unless your legal team has reviewed the process.

Disk and memory analysis techniques are covered in the Digital Forensics (DFIR) Guide.

Eradication and recovery

• Remove every foothold: new users, roles, access keys, service principal credentials, OAuth consents, trust policy changes, Lambda functions or automation runbooks, and resources in Regions you do not use. Google's Security Command Center guidance is explicit: rotate and delete all service account keys in the affected project and remove unfamiliar instances, snapshots and service accounts.
• Rotate what the identity could read: Microsoft's playbook prioritises secrets the service principal actually retrieved, then the rest of any exposed Key Vault, then secrets across the exposed subscriptions. Apply the same logic to AWS Secrets Manager and Google Secret Manager.
• Rebuild rather than clean: redeploy workloads from infrastructure as code and known-good images, verifying the root cause is fixed. Check backups and snapshots for indicators of compromise before restoring (CSF 2.0 RC.RP-03).
• Watch for return: alert on re-enablement of disabled principals, recreation of deleted keys and new activity from the attacker's infrastructure for weeks afterwards.

The Cloudflare Thanksgiving breach came from credentials not rotated after an earlier incident, and the Sumo Logic breach shows the opposite discipline: a customer-wide key rotation after one compromised AWS credential. For destructive incidents see the Ransomware Response and Recovery Guide.

Working with the provider, legal and notification

• AWS: the AWS Customer Incident Response Team is a 24/7 team that supports customers "during active security events on the customer side" of the shared responsibility model, engaged through an AWS support case.
• Google Cloud: respond to Cloud Customer Care notifications about your projects, and use your support channel or an incident response service for deeper investigation.
• Microsoft: Microsoft Incident Response provides eviction and recovery services; Azure support handles platform questions.
• Contracts first: SP 800-61 Rev. 3 expects third-party responsibilities to be written into contracts, and providers may only share sanitised information about their side. Check your support tier and SaaS providers' notification commitments before an incident.
• Notification clocks: GDPR Article 33 gives 72 hours to notify the supervisory authority after becoming aware of a personal data breach, NIS2 expects an early warning within 24 hours for significant incidents, and US listed companies file Form 8-K Item 1.05 within four business days of determining materiality. Involve legal counsel at declaration, not at closure.

Building the capability

1. Logging baseline (weeks 1 to 4): organisation trail, Entra and Activity log export, Google Cloud log sinks, data-level logs for crown-jewel storage, all into a protected log archive.
2. Access (weeks 2 to 6): IR roles in every account, emergency access tested, forensics account or project with snapshot sharing and key policies pre-approved.
3. Playbooks and automation (weeks 4 to 10): write the leaked key and compromised workload playbooks first; automate acquisition and isolation behind a tag or ticket, tested in a sandbox account. Keep a manual fallback and a documented rollback (remove the isolation group, delete the deny policy).
4. Exercise (quarterly): tabletop first, then purple team exercises that run real containment in a test account. AWS lists tabletop, purple team and red team simulations, each ending with an after-action report.
5. Improve: feed lessons learned into guardrails, detections and the playbooks (CSF 2.0 ID.IM).

A small organisation with one cloud account can lean on native detection services and a retained IR firm with cloud skills. A large multi-cloud estate needs per-provider playbooks, automation and someone who owns the log archive.

Metrics that show readiness:

• Percentage of accounts, subscriptions and projects sending audit logs to the central archive (target 100).
• Time from alert to first credential revocation, measured in exercises and real incidents.
• Time to produce a forensic snapshot in the forensics account for a test instance.
• Percentage of workload credentials with a known owner and a tested rotation path.
• Log retention in days against mean time to detect.
• Exercise findings closed within the agreed period.

Framework mapping

Common failure patterns

• Logs not there: data events and Data Access logs never enabled, or Entra logs aged out after 30 days, so nobody can say what was read.
• Deleting first: terminating a mining instance or deleting a malicious app before snapshotting and scoping, which destroys evidence and tips off the attacker.
• Containing one credential: rotating the leaked key while attacker-created users, roles and service principal secrets remain. The Storm-2949 Azure attack shows how one identity becomes a subscription-wide foothold.
• Metadata credentials ignored: treating an exploited web server as a host problem when its instance role credentials were taken, as in the Capital One breach.
• Single-Region view: investigating the Region that alerted while resources run in Regions nobody monitors.
• Responders without access: IR team members who need a ticket to get read access to the affected account during the incident.

Practitioner checklist

• Enable organisation-wide audit logging in every provider, including data-level logs for sensitive storage, and ship it to a protected archive.
• Export Entra sign-in, audit and Graph activity logs; retain logs longer than your mean time to detect.
• Pre-create IR read-only and containment roles in every account, subscription and project.
• Stand up a forensics account or project with no internet egress and pre-approved snapshot and key sharing.
• Write and test leaked key, compromised identity, compromised workload, crypto mining and destruction playbooks for each provider.
• Script snapshot, memory capture, isolation and session revocation, with a documented rollback.
• Inventory workload credentials with owners and rotation procedures.
• Record provider support routes, contract notification terms and legal notification clocks in the plan.
• Run a cloud tabletop each quarter and a hands-on containment exercise at least yearly.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• AWS: Security Incident Response Guide
• AWS: Revoke IAM role temporary security credentials
• Microsoft Learn: Compromised and malicious applications investigation
• Microsoft Learn: Microsoft Entra data retention
• Google Cloud: Responding to Compute Engine threat findings
• Canadian Centre for Cyber Security: Best practices for event logging and threat detection
• MITRE ATT&CK: Cloud Matrix

Related NHI Mgmt Group resources: Incident Response Guide · Ransomware Response and Recovery Guide · Digital Forensics (DFIR) Guide · Leaked Credential Response Playbook · Cloud Workload Identity Guide