Cloud Ransomware Response Playbook: Responding When Attackers Encrypt or Delete Cloud Data

Cloud ransomware rarely involves malware: attackers log in with stolen cloud credentials and use the provider's own features to encrypt objects with a key only they hold, delete snapshots and backups, or wipe SaaS data, and the on-premises ransomware playbook has no steps for any of it. This template gives [Organisation] a response playbook for three cloud scenarios: Amazon S3 objects re-encrypted with customer-provided keys (SSE-C), deletion of snapshots, backups and storage accounts, and mass deletion of SaaS data such as Microsoft 365 or Google Workspace content. How these attacks work and how to prevent them is covered in the Cloud Ransomware Guide; general cloud response is in the Cloud Incident Response Guide. This page is the response runbook for cloud security, identity and backup teams. Replace every [bracketed] placeholder.

How to use this template

• Pick the scenario early: sections 3 to 6 have steps marked [S3], [Snapshot] and [SaaS]. Most real incidents combine at least two: Microsoft's account of Storm-0501 describes exfiltration, deletion of snapshots and backup containers, then encryption with an attacker-controlled key.
• Treat it as an identity incident: every scenario here starts with a valid cloud credential (ATT&CK T1078.004 Cloud Accounts). Containment is mostly about cutting that access, not isolating hosts.
• Act fast on deletion timers: lifecycle rules, soft-delete windows and SaaS retention periods set hard deadlines. Section 3 step 4 records them.
• Run it under the main plan: the ransom decision, law enforcement contact and executive communication follow the Ransomware Playbook Template.
• Owner and review: [Head of Cloud Security], reviewed every [12] months and after any change in cloud provider, backup product or SaaS tenant.

1. Scope and triggers

1.1 Covers [AWS accounts, Azure subscriptions, Google Cloud projects, Microsoft 365 and Google Workspace tenants, other SaaS] owned by [Organisation]. Encryption of virtual machines or hypervisors uses the ESXi Ransomware Playbook or host playbooks.

2. Roles and contacts

2.1 Use [out-of-band channel] if the collaboration suite may be compromised; Storm-0501 contacted a victim through Microsoft Teams using a compromised account.

3. Detection and triage

1. Identify the principal: from CloudTrail, Azure activity logs or SaaS audit logs, find which user, role, access key, service principal or app performed the destructive actions, and from which IP addresses.
2. [S3] Confirm SSE-C: object reads fail without a customer key and the data events show the SSE-C algorithm parameter. AWS does not store the customer-provided key, and CloudTrail records only an HMAC of it, so the data cannot be decrypted by AWS or from logs. Recovery depends on earlier object versions or independent copies.
3. Find surviving copies: is versioning on, and do prior versions exist? Is there Object Lock, replication to another account or Region, AWS Backup or Azure Backup in a separate account, or third-party SaaS backup?
4. Record every deadline:

• 5. Scope exfiltration: check for large GetObject volumes, storage key listing and copy tools, and new external sharing. Assume data theft until disproved; the Ransomware Data Leak Site Listing Playbook covers publication.
• 6. Do not follow ransom note instructions about not changing permissions; the notes in the Codefinger S3 Ransomware 2025 attack warned that changes would end negotiations. Containment takes priority.

4. Containment

Order by priority. Record every change with time and operator.

1. Stop the deletion clocks first: [S3] remove attacker lifecycle rules (save a copy as evidence); [Snapshot] cancel pending KMS key deletion and recover soft-deleted Key Vault keys; [SaaS] place retention holds on affected mailboxes, sites and drives.
2. Disable the credential: deactivate the access key, disable the user or service principal, revoke sessions and refresh tokens, and remove any credentials the attacker added (T1098.001 Additional Cloud Credentials). See the AWS Access Keys Security Guide.
3. Block the technique account-wide: [S3] block SSE-C on affected buckets through the bucket encryption setting (BlockedEncryptionTypes with SSE-C) or deny PutObject requests carrying the SSE-C header in bucket policies or resource control policies; [Snapshot] apply deny policies on delete actions for backup vaults and snapshots to all but the break-glass role; [SaaS] restrict admin roles to the incident team.
4. Check the identity plane: look for new admin role assignments, federation or custom domain changes, elevated Azure access, and compromised directory sync servers. The Storm-0501 Hybrid Cloud Attacks 2024 page shows how stolen Entra Connect Sync credentials carried operators from on-premises into the cloud.
5. Preserve evidence: export CloudTrail (management and data events), Azure activity and Key Vault logs, and SaaS audit logs to a separate, locked account before retention runs out. See the AWS CloudTrail Guide.

5. Eradication

• Rotate widely: rotate every long-term key, client secret and storage account key that the compromised principal could read, not only the one used. Replace long-term access keys with roles or federated short-lived credentials where possible.
• Remove persistence: unknown IAM users, roles with external trust, cross-account replication rules, new app registrations and OAuth consents, mail forwarding rules, and resources created in unused Regions.
• Re-enable protections the attacker removed: versioning, Object Lock default retention, resource locks, immutability policies, Key Vault purge protection, Defender or GuardDuty protection plans, and logging.
• Confirm the entry point is closed: leaked key in a repository, phished admin, exposed sync server or vulnerable application. Do not restore data into an environment the attacker can still reach.

6. Recovery

1. Restore in business priority order from [critical data list], verifying backup integrity before use (NIST CSF 2.0 RC.RP-03).
2. Restore into clean targets: where the account itself is in doubt, restore into a new account or subscription with fresh credentials. See the Cloud Recovery and Clean Room Guide.
3. Watch for return: keep heightened alerting on destructive APIs for [30] days.

7. Communication and notification

• Law enforcement and CISA or NCSC: CISA's #StopRansomware guidance asks victims to report incidents; record the reference.
• Regulators: the Privacy Lead assesses personal data impact, for example the GDPR Article 33 72-hour deadline, and sector rules in [list].
• Provider: open a support case early; providers can confirm activity and sometimes help with recovery options.
• Customers and partners: through the main incident process, especially where shared buckets or SaaS data belonged to them.

8. Post-incident review

• How the credential was obtained and why it had destructive permissions.
• Which copies survived and why; which protections had been disabled before impact and how quickly that was detected.
• Time from first destructive API call to detection, containment and full restore.
• Actions: SSE-C blocked where unused, backups in a separate account with immutability, alerts on lifecycle and delete APIs, and this playbook updated within [30] days.

Implementation guidance

Prepare before an incident. Pre-build the alert queries for the trigger table, a break-glass role per provider that can apply deny policies, and a separate log archive account. AWS notes that since April 2026 SSE-C is disabled by default on new general purpose buckets and on existing buckets in accounts without SSE-C objects; check your older buckets.

Rehearse each scenario in a sandbox account: encrypt test objects with SSE-C and restore prior versions; delete a test snapshot and restore from the vault copy; delete a test site and restore it.

Framework mapping. NIST SP 800-53 IR-4 Incident Handling, CP-9 System Backup and CP-10 System Recovery and Reconstitution; NIST CSF 2.0 RS.MI-01, RC.RP-03 and PR.DS-11; ISO/IEC 27001:2022 Annex A 8.13 Information backup.

References. AWS: Using server-side encryption with customer-provided keys (SSE-C) · AWS Security Blog: Preventing unintended encryption of Amazon S3 objects · AWS: S3 Object Lock · Microsoft Security Blog: Storm-0501's evolving techniques lead to cloud-based ransomware · Microsoft: Restore deleted sites · Google Workspace: Recover deleted files for Drive users · CISA: #StopRansomware Guide

Related NHI Mgmt Group resources: Cloud Ransomware Guide · Cloud Incident Response Guide · Codefinger S3 Ransomware 2025 · Cloud Native Backup and Ransomware Resilience Guide · Ransomware Playbook Template