Ransomware Response and Recovery Guide

Most ransomware recoveries take longer than they should because organisations restore systems before they have evicted the attacker, rebuilt trusted identity and proved their backups are clean. This guide covers the response and recovery lifecycle once encryption or extortion has started: containment, scoping, identity recovery, the clean room or isolated recovery environment, restore priorities, validation before reconnecting, notification and the ransom decision. It is written for incident leads, infrastructure and identity teams, and the executives who make recovery and payment decisions under pressure. Prevention is covered in the Ransomware Prevention Guide and general incident handling in the Incident Response Guide.

Key takeaways

• Contain in a coordinated way, out of band. Isolate at the switch level, snapshot cloud volumes and keep the attacker from watching your response on compromised email and chat.
• Scope before you restore. Precursor malware, rogue accounts and stolen credentials survive a restore; CISA warns to find dropper malware "before rebuilding from backups to prevent continuing compromises".
• Identity is the first system you recover. Domain controllers, krbtgt, federation keys, cloud admin roles and every non-human credential the attacker could read must be rebuilt or rotated first.
• Restore into a clean environment, in priority order. Work to minimum viable operations, verify backups before use (NIST CSF 2.0 RC.RP-03) and never reconnect a clean system to a dirty network.
• The ransom decision is a business, legal and sanctions decision. US and UK authorities discourage payment, OFAC applies strict liability, and the ICO does not treat payment as mitigation. Record every decision and its reasons.

The first hours: contain without losing evidence

The CISA #StopRansomware Guide checklist works through detection and analysis, reporting and containment in sequence. The tension is between stopping encryption and preserving evidence needed for scoping.

• Communicate out of band: CISA notes attackers may monitor your communications and recommends phone calls and other out-of-band methods. For identity compromise, Microsoft's responders use "completely isolated identities and communication resources", which can mean a separate clean tenant.
• Start the decision log now: the NCSC asks victims to record "the incident response, decisions made, actions taken and data captured", ideally on offline or unaffected systems. It later serves insurers, regulators and the lessons-learned review.

Scoping: what the attacker touched and how they got in

Encryption is usually the last step of an intrusion that started days or weeks earlier; restoring before you know the entry point, persistence and data taken invites a second encryption. CISA's checklist lists what to hunt for:

• Precursor malware: droppers such as Bumblebee, Dridex, Emotet, QakBot or Anchor, often sold on as network access.
• Identity abuse: newly created Active Directory accounts, escalated privileges, unusual Domain Admins activity, anomalous VPN logins, and signs of AD enumeration or credential dumping (Mimikatz, NTDSutil.exe).
• Recovery sabotage: use of bcdedit.exe, fsutil.exe, vssadmin.exe, wbadmin.exe and wmic.exe, which CISA calls "a common ransomware technique to inhibit system recovery" (ATT&CK T1490 Inhibit System Recovery).
• Tooling: Cobalt Strike processes named like Windows processes, unexpected remote monitoring and management (RMM) software, PsTools and unexpected PowerShell.
• Exfiltration: abnormal outbound volume, tunnelling tools (Chisel, Cloudflared) and transfer tools (Rclone, Rsync, FTP/SFTP). Data theft changes notification duties even when backups restore everything.
• Cloud control plane: changes to IAM, security groups, keys and storage encryption. ATT&CK T1486 Data Encrypted for Impact describes attackers using AWS SSE-C (customer-provided keys) to encrypt objects; the Codefinger S3 ransomware campaign used stolen AWS keys this way.

Scoping should produce the earliest known compromise date, a last known good date per system (which decides the safe restore point), a list of compromised identities and a list of persistence mechanisms. See the Digital Forensics (DFIR) Guide.

Rebuilding identity first

The NCSC's 2026 recovery guidance calls trusted identity "a critical dependency for recovery" and tells organisations to re-establish a trusted identity source before restoring services. Every system restored onto a compromised directory is compromised too. Plan identity recovery as one coordinated eviction window after scoping; CISA places password resets after the environment is "cleaned and rebuilt".

Active Directory and hybrid identity (tier 0)

• krbtgt: Microsoft's forest recovery guidance says to reset it twice, waiting 10 hours between resets, because the account's password history holds the two most recent passwords. Ten hours is the default maximum ticket lifetime; wait longer if yours is higher. Include read-only domain controllers.
• Federation: if AD FS is in use, rotate the token-signing certificate twice, because a single rotation "would still allow the previous Token Signing certificate to work", then revoke refresh tokens. Where trust in federation is lost, Microsoft recommends switching to cloud-mastered authentication while on-premises is remediated.
• Synchronisation accounts: treat Entra Connect (formerly AD Connect) and AD FS servers as tier 0. In the Storm-0501 hybrid cloud attacks, stolen Entra Connect Sync credentials carried ransomware operators from on-premises into the cloud.
• Privileged groups: remove unnecessary members from Domain Admins, Enterprise Admins and Backup Operators, reset every privileged and delegated admin password, and set a unique Directory Services Restore Mode (DSRM) password on each domain controller.
• Rebuild: where domain controllers were taken over, restore one DC per domain from a pre-compromise backup into the isolated environment, clean it and rebuild the rest from it. See the Active Directory and Entra ID Hardening Guide.

Cloud administration

• Reset and minimise break-glass accounts; Microsoft recommends cloud-only privileged accounts with MFA, Privileged Identity Management and Conditional Access. See the Break-Glass Account Guide.
• Review enterprise applications and service principals for new credentials, app role assignments and high-risk consent grants, which Microsoft associates with attacker persistence, and check the Unified Audit Log for "Set domain authentication" events.

Non-human identities and secrets

An attacker with domain admin could read service account passwords, scripts, CI/CD variables and cloud keys; resetting only human passwords leaves those paths open, and the Cloudflare Thanksgiving breach showed what unrotated credentials from an earlier incident can do.

See the Service Account Security Guide and the Secrets Management Guide.

Clean room recovery and the isolated recovery environment

A clean room, or isolated recovery environment (IRE), is a separate network segment or cloud account where systems are restored, scanned and rebuilt before rejoining production. CISA expresses the principle as restoring "on a clean network" and adding only clean systems to a new recovery VLAN. An effective IRE has:

• Its own identity: admin accounts and MFA that do not depend on the compromised directory or IdP, and responder devices built from a clean source (Microsoft recommends privileged access workstations).
• Its own network and tooling: no routing to production, tools installed from trusted media, logging to a separate SIEM workspace.
• Trusted build sources: golden images, infrastructure-as-code templates (CISA: "Use infrastructure as code templates to rebuild cloud resources") and software from verified repositories, not from file shares the attacker could have modified.
• Access to protected backups: restore-only access, through a separate account, to immutable, offline or logically air-gapped copies, which are the ones most likely to have survived. See the Ransomware Prevention Guide.

Small vs large organisations: a small organisation can use a separate cloud subscription or tenant with a pre-written runbook, tested twice a year. A large organisation needs a standing environment sized for tier 0 and tier 1 services with documented capacity limits, because pushing everything through a clean room at once is rarely feasible.

Restore priorities and minimum viable operations

The NCSC defines minimum viable operations (MVO), which some plans call the minimum viable company, as "the lowest level of operational capability at which the organisation can continue to operate safely". Restore order should come from a critical asset list agreed before the incident; CISA asks for restoration "based on a predefined critical asset list", and NIST CSF 2.0 RC.RP-02 for recovery actions that are "selected, scoped, prioritized, and performed".

Restore vs rebuild: restore from backup when the restore point predates the earliest compromise and the data cannot be recreated. Rebuild from images or code when the system is stateless, the compromise date is uncertain, or the attacker controlled it in tier 0. Prefer restoring data over whole server images, which can bring back the attacker's persistence. The NCSC warns that backups may not cover "applications, identity systems and sources of trust", so check that gap during planning, not during the incident.

A ransomware decryptor is another restore path. Check No More Ransom, the initiative of the Dutch police, Europol's EC3 and security vendors, and ask law enforcement; CISA says to consult federal law enforcement "regarding possible decryptors available". Test any decryptor on copies first.

Validation before reconnecting

NIST CSF 2.0 RC.RP-03 requires that "the integrity of backups and other restoration assets is verified before using them for restoration", and RC.RP-05 that restored assets are verified before normal operation is confirmed. Before a system leaves the IRE, confirm:

1. Eviction is confirmed by the investigation team. The NCSC is blunt: if you are unsure the attacker is gone, "proceeding with recovery carries a risk of the incident restarting."
2. The restored data and binaries have been scanned with current signatures and swept for the incident's indicators of compromise.
3. The system is patched for the entry vulnerability and hardened (local admin passwords, remote access, RMM tools removed).
4. EDR and logging are active and reporting to the clean monitoring stack.
5. Every credential the system uses has been reissued in the eviction window.
6. The business owner has tested it and signed off.

The NCSC notes partners "may require independent assurance or evidence of compromise remediation before restoring connectivity", so prepare a short assurance pack (scope, eviction actions, credentials rotated, monitoring) early. CISA's checklist ends with a designated authority declaring the incident over "based on established criteria"; write those criteria into the plan.

Notification and reporting

Notification duties depend on sector, jurisdiction and whether personal data was taken. The Incident Response Guide has a deadlines table (GDPR Art. 33, NIS2 Art. 23, SEC Form 8-K Item 1.05). Points specific to ransomware:

• Law enforcement: CISA lists CISA, the local FBI field office, IC3 and the US Secret Service; in the UK the NCSC points victims to the government's incident signposting service. Reporting early also opens the question of available decryptors.
• Data protection regulators: encryption without exfiltration can still be a personal data breach, because availability is lost. The ICO says paying "does not reduce the risk to individuals" and will not count as mitigation, but it will consider early engagement with the NCSC positively.
• Insurers: notify early. Many policies require use of panel responders and prior consent for significant spend, so check the policy before engaging firms.
• Proposed UK rules: in July 2025 the UK government responded to its consultation on a targeted payment ban for public sector bodies and regulated critical national infrastructure, a payment prevention regime requiring notice of intent to pay, and mandatory incident reporting. These were proposals for future legislation; check their status before relying on them.

The ransom decision

NIST IR 8374 Rev. 1 describes the dilemma without recommending either answer: pay and "hope the attackers keep their word", or restore without them. The decision belongs to the victim, as the NCSC's 2024 guidance with the insurance bodies ABI, BIBA and IUA states. This section covers the considerations, not how to pay.

Ransomware negotiators are usually engaged through counsel or the insurer; negotiation can buy time but does not change the sanctions analysis. Record who decided, on what evidence and when.

Preparing the recovery capability: a phased approach

1. Agree the critical asset list and MVO: business owners rank services, set RTO and RPO, and record dependencies such as identity, DNS and PKI.
2. Write the ransomware playbook: containment authority, out-of-band communications, decision log template, contacts (law enforcement, insurer, counsel, IR retainer) and end-of-incident criteria.
3. Build the IRE: separate identity, network, tooling and restore-only access to protected backups. Pilot it with one tier 1 application.
4. Rehearse tier 0 recovery: restore a domain controller and the IdP configuration into the IRE, run the double krbtgt reset and rotate a sample of service account and cloud credentials. Measure elapsed time.
5. Inventory non-human credentials: know which service accounts, keys and secrets each tier 0 and tier 1 system holds, so rotation can be scripted.
6. Exercise the decisions: run an executive tabletop on payment, notification and partner reconnection.
7. Plan rollback: snapshot rebuilt tier 0 systems inside the IRE so a failed step can be reversed without returning to compromised backups.

Afterwards, document lessons learned, update the plan and, as CISA recommends, share indicators of compromise with CISA or your sector ISAC.

Detection and measurement

During recovery the attacker knows your environment, so monitoring must be tighter than before. Watch for use of rotated credentials, new admin accounts or group changes, service principal credential additions, returning RMM or tunnelling tools, and attempts to delete snapshots or change backup retention. Keep heightened detection running at least as long as the attacker's known dwell time.

• Time to MVO and tier 0 recovery time: hours from declaration, measured in exercises and incidents against targets.
• Credential rotation coverage: percentage of in-scope human and non-human credentials rotated within the eviction window.
• Restore success rate: percentage of tested restores that met RTO and passed validation.
• Re-infection events: count of systems found compromised after reconnection (target zero).

Common failure patterns

• Restoring before eviction: systems restored onto a network the attacker still controls are encrypted again.
• Human passwords reset, machine credentials left: service accounts, sync accounts and cloud keys stay valid. Storm-0501 shows how a single sync credential bridges on-premises and cloud.
• Single krbtgt reset: the old password stays in history and forged tickets keep working.
• Restore points from inside the dwell time: the backup is intact but already contains the attacker's tools.
• No plan for long shutdowns: the Jaguar Land Rover cyberattack halted global production, a reminder that MVO, supplier communication and staff welfare planning matter as much as technical restores. The NCSC notes recovery is likely to take several weeks.

Framework mapping

Practitioner checklist

• Pre-agree who can take the network offline and keep an out-of-band communication channel ready.
• Maintain a critical asset list with MVO, RTO and RPO per service, signed off by business owners.
• Build and test an isolated recovery environment with its own identity, network and trusted build sources.
• Rehearse tier 0 recovery, including two krbtgt resets 10 hours apart and AD FS certificate rotation where used.
• Keep an inventory of service accounts, keys and secrets per critical system so rotation can be scripted.
• Scope the intrusion and fix the last known good date before choosing restore points.
• Scan and validate every backup and restored system before it leaves the clean room.
• Prepare a ransom decision framework covering sanctions, alternatives and data extortion.
• Keep a decision log from the first hour and run a lessons-learned review within weeks of closure.

Standards and references

• CISA: #StopRansomware Guide
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: IR 8374 Rev. 1, Ransomware Risk Management: A CSF 2.0 Community Profile
• NCSC: Recovering from a highly disruptive cyber attack
• NCSC: Guidance for organisations considering payment in ransomware incidents
• US Treasury OFAC: Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments
• Microsoft Learn: AD Forest Recovery, Reset the krbtgt password
• Microsoft Security: Advice for incident responders on recovery from systemic identity compromises

Related NHI Mgmt Group resources: Ransomware Prevention Guide · Incident Response Guide · Service Account Security Guide · Leaked Credential Response Playbook · ITDR Guide. This guide summarises notification and ransom payment considerations at a high level and is not legal advice.