Cloud Recovery and Clean Room Guide

After a destructive attack, restoring backups into the same compromised cloud tenant often hands the attacker a second chance. Modern ransomware operators go after the control plane: they take over cloud admin roles, delete snapshots and recovery vaults, and encrypt storage with keys they control. Recovery therefore needs an isolated place to validate backups, rebuild identity and infrastructure, and only then reconnect production. This guide explains how to design that clean room, or isolated recovery environment, in AWS, Azure and Google Cloud, how to run a rebuild in the right order, and how to test it. It is for cloud, infrastructure, security and incident response teams. In this guide "clean room" means a trusted recovery environment, not the privacy-preserving data clean rooms covered in the Privacy-Enhancing Technologies Guide.

Key takeaways

Assume the control plane is lost. Plan for an attacker who held Owner, Global Administrator or account root, not just one who encrypted a few virtual machines.
Backups must outlive their administrators. Use locked immutability (S3 Object Lock compliance mode, AWS Backup logically air-gapped vaults, Azure immutable vaults in the locked state, Google Cloud enforced retention) so no single compromised identity can delete them.
Recover into a clean room, not into the crime scene. A separate account, subscription or project with its own identities is where you scan restore points, rebuild from code and golden images, and prove systems are clean.
Identity comes first. Rebuild or reclaim the identity plane and rotate every credential, including service principals, access keys and customer-managed keys, before you reconnect workloads.
Untested recovery is a hypothesis. Run a full "recover from zero" exercise at least once a year and measure the time it takes.

Why cloud recovery fails after a destructive attack

Traditional disaster recovery assumes the disaster is outside your control (a region outage, a fire) and that your administrators are trustworthy. A destructive attack breaks both assumptions. In August 2025 Microsoft reported that Storm-0501 had moved towards cloud-based ransomware: according to BleepingComputer's account of Microsoft's research, the group abused the Azure Microsoft.Authorization/elevateAccess/action operation to grant itself Owner roles, tried to delete storage snapshots, restore points, Recovery Services vaults and storage accounts, and where it could not delete Recovery Services data it created new Key Vaults and customer-managed keys to encrypt it. See the Storm-0501 Hybrid Cloud Attacks breach page for how the group first reached Entra ID.

The Codefinger S3 ransomware campaign showed the same pattern on AWS: with stolen access keys the attackers encrypted objects using server-side encryption with customer-provided keys (SSE-C), whose keys AWS does not store, and added a lifecycle rule to delete the data after seven days. Neither attack needed malware on a server. Both relied on cloud identities with too much power over data and its recovery copies.

Attacker action	ATT&CK technique	Recovery control that survives it
Uses stolen cloud admin or service credentials	T1078.004 Cloud Accounts	Recovery identities in a separate account or tenant; break-glass accounts not federated to production
Grants itself higher roles	T1098.003 Additional Cloud Roles	Alerts on role assignment at root or management group scope; Multi-user authorization for vault changes
Deletes snapshots, vaults and restore points	T1490 Inhibit System Recovery	Locked immutability, soft delete, vaults in a separate account or project
Deletes data or storage accounts	T1485 Data Destruction	Versioning plus Object Lock or immutable blob storage; cross-account copies
Encrypts data with attacker-controlled keys	T1486 Data Encrypted for Impact	Block SSE-C where unused; restrict key creation; backups encrypted with keys held in the recovery account

What a cloud clean room is

A clean room, or isolated recovery environment, is a pre-built landing zone that the attacker could not reach and that does not trust anything from production until it has been verified. CISA's ransomware guide describes the essentials in on-premises terms: restore systems on a clean network, add only clean systems to the new recovery segment and check for precursor "dropper" malware before rebuilding from backups. NCSC adds that backups should be connected only to known clean devices and scanned before files are restored. In the cloud the same ideas map to separate accounts and identity boundaries rather than VLANs.

Separate administrative boundary: a dedicated AWS account in its own organisational unit (or a separate AWS Organization), an Azure subscription governed from a separate tenant where possible, or a Google Cloud project outside production folders.
Independent identities: a small set of recovery operators with phishing-resistant MFA, not synchronised from the production directory, plus documented break-glass accounts.
Read access to protected copies: the clean room can restore from vaults but production cannot delete them.
Build tooling: version-controlled infrastructure as code, golden images and configuration baselines stored where production admins cannot alter them. CISA recommends keeping IaC templates offline and version-controlled for exactly this reason.
Analysis tooling: malware scanning, EDR, log storage and forensic workstations to validate restore points. See the Digital Forensics (DFIR) Guide.
Controlled egress: no route to production and tightly limited internet access until validation is complete.

Protecting recovery copies on AWS, Azure and Google Cloud

The clean room is only as good as the copies it restores. Each major cloud now offers a way to make backups undeletable for a set period, even by an administrator.

Platform	Feature	Key behaviour	Watch out for
AWS	AWS Backup logically air-gapped vault	Always locked with Vault Lock in compliance mode; minimum retention at least 7 days; can be shared through AWS RAM with individual recovery account IDs, which can restore but not copy; Multi-party approval allows restore even if the owning account is inaccessible	Encryption key choice is fixed at creation; AWS advises against a customer-managed key from the same account in production
AWS	S3 Object Lock	Requires versioning; compliance mode cannot be shortened or removed by any user, including root; governance mode can be bypassed with `s3:BypassGovernanceRetention`	Governance mode is only as strong as the control over the bypass permission
Azure	Immutable vault (Recovery Services and Backup vaults)	States are Disabled, Enabled and Enabled and locked; locking is irreversible; blocks deleting recovery points and reducing retention	Lock only after you have confirmed the retention impact
Azure	Multi-user authorization with Resource Guard	A Resource Guard owned by a security admin gates critical operations; disabling soft delete or security features and removing MUA are mandatory protections; can sit in a different subscription or tenant	If the backup admin also holds Contributor or Backup MUA roles on the Resource Guard, protection is overridden
Azure	Soft delete	Keeps deleted backup data for 14 additional days according to Microsoft's ransomware backup guidance	Protects against deletion, not against encryption with a new key
Google Cloud	Backup and DR backup vault with enforced retention	Minimum enforced retention from 1 day to 99 years; backups cannot be deleted by anyone, including Google, before it expires; the lock becomes permanent after an effective date; access restriction setting is permanent	Storage is charged for the full enforced period

For the deeper design of immutable storage, see the Backup Security and Immutable Backup Guide. NCSC's offline backup principles still apply in the cloud: backup clients should hold no valid credentials while storage is idle, and an identity that can only create or append backups cannot overwrite existing ones.

What to protect beyond data

Teams often back up databases and disks but cannot rebuild the platform those depend on. Microsoft's ransomware backup guidance puts identity systems first in its priority list, ahead of life-safety, financial and service delivery systems, and warns that attackers target recovery documentation.

Identity: directory and Entra ID configuration, Conditional Access policies, federation settings, role assignments and application registrations. See the Identity Recovery Guide.
Infrastructure as code: Terraform, CloudFormation, Bicep or Deployment Manager code and state, held in a repository whose history production admins cannot rewrite.
Golden images: hardened machine and container images with their hashes recorded so you can prove they are unmodified.
Keys and secrets: an escrowed path to the keys that decrypt backups. A backup encrypted with a key the attacker deleted or replaced is useless.
Configuration and policies: organisation policies, service control policies, network rules and logging configuration.
Runbooks and contacts: restore procedures, network diagrams, CMDB exports and supplier contacts, available out of band.

Rebuilding in the right order

NIST SP 800-184 frames recovery as a planned activity with playbooks, test scenarios and improvement, not an improvised response. A cloud rebuild after a destructive attack works best as a fixed sequence agreed in advance with incident response.

Declare and contain. Incident response confirms the scope, preserves evidence and cuts the attacker's access to the control plane where possible. Recovery does not start in production while the attacker is still present.
Stand up the clean room. Activate the recovery accounts or subscriptions using break-glass identities that were never federated to the compromised directory.
Re-establish identity. Reclaim or rebuild the identity provider, remove rogue federated domains and role assignments, and issue new credentials to recovery operators. See the Identity Incident Response Playbook.
Choose a clean restore point. Use the incident timeline to pick a point before the first malicious activity, as Microsoft advises, and remember that backups taken during encryption may already contain encrypted data.
Validate before use. Restore into the clean room, scan for malware and persistence, check integrity against known hashes and compare configuration with IaC. This is NIST CSF 2.0 RC.RP-03: verify the integrity of backups before using them.
Rebuild, do not just restore. Redeploy infrastructure from IaC and golden images and restore only data onto it, in the order of your critical asset list, as CISA recommends.
Rotate everything. After rebuild, reset passwords for affected accounts and rotate access keys, service principal secrets and certificates, API tokens and customer-managed encryption keys. CISA explicitly calls for updating customer-managed keys where needed.
Verify and promote. Confirm restored services work and are clean (RC.RP-05), then switch traffic and DNS to the rebuilt environment.
Declare the end and learn. Close the recovery against agreed criteria (RC.RP-06) and feed lessons into the plan.

The Ransomware Response and Recovery Guide covers the wider response, including decisions about extortion, which this guide does not repeat.

Choosing a clean room model

Model	How it works	Good for	Trade-offs
Cold, defined in code	Accounts and guardrails exist; everything else is deployed from IaC when needed	Smaller organisations, low cost	Slower RTO; depends on IaC being current and tested
Warm	Core network, identity, scanning and logging services run permanently; workloads are restored on demand	Most mid-sized and large organisations	Ongoing cost and patching of the standing environment
Separate organisation or tenant	Recovery lives in a different AWS Organization, Azure tenant or Google Cloud organisation with separate admins	Regulated sectors and high-value targets	Highest isolation; more complex identity and billing; harder to test
Other cloud or third-party service	Copies and rebuild capability held with another provider	Concentration risk concerns; CISA suggests considering multi-cloud backup to avoid lock-in	Different tooling and skills; translation of IaC and images

Small organisations: start with locked immutable backups in a separate account, break-glass identities and an IaC repository with a tested rebuild of one critical service. Large organisations: run a warm clean room per cloud, govern it from a separate tenant or organisation, and require multi-party approval for any change to recovery vaults.

Testing the clean room

Restore tests: use AWS Backup restore testing, or scheduled restores on Azure and Google Cloud, to prove backups are restorable every month for critical systems.
Recover from zero: Microsoft recommends exercising a scenario in which all systems are down. Rebuild a critical service end to end in the clean room, including identity, and time it.
Out-of-band operation: run the exercise assuming email and chat are unavailable.
Tamper tests: with a test admin, try to delete a recovery point, shorten retention or disable soft delete, and confirm the attempt is blocked and alerted.
Rollback: keep the compromised environment frozen, not deleted, until the rebuilt one has run cleanly for an agreed period; evidence may still be needed.

Detection and measurement

Monitor the actions that come before a destructive attack and the health of the recovery capability itself.

AWS CloudTrail: DeleteRecoveryPoint, DeleteBackupVault, PutBucketLifecycleConfiguration, changes to Object Lock or bucket policies, and PutObject calls using SSE-C where you do not use it.
Azure Activity Log: Microsoft.Authorization/elevateAccess/action, role assignments at root scope, deletion of Recovery Services vault items, Key Vault and key creation, and changes to immutability or soft delete.
Google Cloud Audit Logs: backup vault and backup plan changes, IAM policy changes and project deletion attempts.
Backup tool alerts: failed jobs, sudden change-rate spikes and unexpected encryption.

Metric	Target to aim for
Critical systems with locked immutable copies in a separate account or project	100%
Measured time to rebuild a tier 1 service in the clean room	Within its RTO, measured at least yearly
Restore tests passed in the last quarter	All critical systems
Identities able to delete or shorten retention on recovery copies	Zero without second-person approval
IaC coverage of production infrastructure	Rising quarter on quarter, all tier 1 services
Time to rotate all cloud non-human credentials in an exercise	Known and within the recovery plan

Framework mapping

Framework	Relevant items
NIST CSF 2.0	PR.DS-11 backups created, protected, maintained and tested; PR.IR-03 resilience mechanisms; RC.RP-01 to RC.RP-06 incident recovery plan execution
NIST SP 800-53 Rev. 5	CP-2 Contingency Plan; CP-4 Contingency Plan Testing; CP-6 Alternate Storage Site; CP-9 System Backup with CP-9(3) Separate Storage for Critical Information and CP-9(8) Cryptographic Protection; CP-10 System Recovery and Reconstitution; IR-4 Incident Handling
NIST SP 800-184	Recovery planning, playbooks, testing and metrics
ISO/IEC 27001:2022 Annex A	A.5.30 ICT readiness for business continuity; A.8.13 Information backup
CIS Controls v8.1	Control 11 Data Recovery, including protecting recovery data and keeping an isolated instance of it
MITRE ATT&CK	T1490, T1485, T1486, T1078.004, T1098.003

Common failure patterns

Backups in the same blast radius: vaults in the production account, managed by the same admins and encrypted with keys in the same Key Vault or KMS, as the Storm-0501 activity exploited.
Immutability left unlocked: Azure immutable vaults left in the Enabled state or S3 buckets in governance mode, so a stolen admin role can turn protection off first.
Restoring the attacker: restoring the most recent backup without checking the timeline, which brings back persistence, rogue app registrations or federated domains.
Forgotten non-human identities: rebuilding servers but leaving old access keys, service principal secrets and integration tokens valid. The LastPass breach showed how stolen secrets can unlock cloud backups themselves.
Infrastructure that only exists in production: no IaC or golden images, so the clean room cannot be built in a useful time.
Never tested end to end: single-file restores pass, but nobody has rebuilt identity, networking and a full application together.

Practitioner checklist

Create recovery accounts, subscriptions or projects outside the production administrative boundary, with independent break-glass identities.
Store critical backups in locked immutable vaults or compliance-mode Object Lock, with copies in a separate account and region.
Protect vault changes with multi-party approval or Resource Guard owned by a separate security admin.
Keep backup encryption keys in the recovery boundary and document how to reach them if production is lost.
Hold IaC, golden images, identity configuration and runbooks where production admins cannot change them.
Write the rebuild sequence: contain, identity, clean restore point, validate, rebuild, rotate, verify, declare.
Alert on elevate-access, root-scope role assignment, vault deletion, lifecycle rule changes and SSE-C use.
Run monthly restore tests and a yearly recover-from-zero exercise, and record the measured times.
Include rotation of all cloud non-human credentials and customer-managed keys in the exercise.

Cloud Recovery and Clean Room Guide: Rebuilding After a Destructive Attack