Ransomware recovery: how to restore your systems without reinfecting them

Why most recoveries fail

Three failure modes account for most prolonged ransomware incidents.

The first is restoring before eradication. Your team recovers from backup, reconnects to the network, and re-infection occurs within hours. The attacker never left. Scheduled tasks, new administrator accounts, remote access tools, and implanted credentials survive the restore and give the attacker a fresh foothold to redeploy encryption.

The second is paying the ransom and treating that as a recovery plan. Sophos research across 5,000 organisations found that 40% of those who paid did not recover all their data. Decryptors fail on corrupted files, return partial keys, or do not work on newer encryption variants.

The third failure is quieter: rebuilding to the same state that made the attack possible. If your environment had gaps before the incident, restoring from an untouched backup re-creates them. The next group finds identical conditions.

Step 1: confirm the attacker is gone

Ransomware deployment typically occurs weeks after initial access. Mandiant M-Trends 2024 puts median dwell time at 11 days before encryption is deployed. In financial services, median dwell time exceeds 45 days. Some groups maintained persistent access for over 200 days before triggering their payload. The encryption event marks the end of the attack, not the beginning.

Before restoration begins, your incident response team needs a full picture: every affected system, every compromised credential, every new account created during the intrusion, and every persistence mechanism found and confirmed removed.

What persistence looks like

Ransomware investigations routinely turn up:

• Scheduled tasks that re-execute the loader or callback payload
• New local administrator accounts created during lateral movement
• Remote monitoring and management (RMM) tools left running after initial access
• Web shells implanted on internet-facing servers
• Domain group policy modifications that preserve attacker privileges
• Registry changes disabling endpoint security tools
• OAuth tokens and API keys provisioned for persistent cloud access

Some groups wait 30 to 60 days after initial discovery before re-entering, targeting organisations that restored without completing eradication.

Step 2: validate your backups

Modern ransomware families treat backups as their primary obstacle to payment. Conti, LockBit 3.0, and BlackCat/ALPHV all include modules that enumerate and attempt to encrypt or delete Volume Shadow Copies, backup software databases, and network-accessible backup repositories. If your backup system was reachable from the infected environment during the attack window, treat it as potentially compromised.

The validation process

1. Identify the last clean backup date. This is before the attacker's initial access, not before encryption was deployed. Check your logs for the earliest evidence of attacker activity.
2. Mount the backup on isolated hardware with no network connectivity to your production environment or domain.
3. Run your EDR and updated AV tools against the mounted backup. Look for known ransomware artefacts, backdoors, and loaders.
4. Perform a test restore of one critical system on that isolated hardware. Verify it boots, passes EDR scanning, and returns accurate data.
5. Only rely on backups that pass all four checks.

Step 3: eradicate before restoring

Do not attempt to clean infected systems. Rebuild them. Verifying that a system is fully clean takes more effort than rebuilding from a known-good image, and you still cannot be certain. Wipe compromised endpoints, servers, and domain controllers and rebuild from a validated baseline or fresh OS install.

Active Directory requires particular attention. If domain controllers were compromised, treat every account with domain admin-equivalent privileges as compromised. Reset all privileged credentials before connecting any restored system to the domain.

Step 4: sequence the restoration

Restore in business priority order, not technical convenience. Define your tiers before an incident so the sequencing decision is made from a plan rather than under pressure.

The three-tier approach

Tier 1 — Core business continuity: payroll, customer-facing services, core ERP, and communications. Target: live within 72 hours of completing eradication.

Tier 2 — Operational support: secondary line-of-business applications, reporting, analytics, and internal tools. Target: live within the first week.

Tier 3 — Non-critical: archives, development environments, test systems, and low-usage internal tools. These wait until Tier 2 is confirmed clean and stable.

Each tier requires sign-off from your incident response lead before connecting to the production network.

Step 5: meet your regulatory notification obligations

Notification obligations run concurrently with recovery work, not after it. Missing a notification deadline while focused on restoration is a separate regulatory violation from the attack itself.

GDPR: the 72-hour window

GDPR Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. In a ransomware attack, that clock starts when your security team establishes personal data was involved, not when encryption was first detected. Ransomware almost always touches personal data because it encrypts indiscriminately across file systems.

The notification needs the nature of the breach, approximate categories and numbers of individuals affected, likely consequences, and measures taken or planned. You do not need a complete investigation first. Notify within 72 hours and update the authority as your picture develops.

NIS2: 24 hours for significant incidents

Under NIS2 Article 23, essential and important entities must submit an early warning to their competent authority within 24 hours of becoming aware of a significant incident. A ransomware attack that disrupts your services qualifies. A full notification follows within 72 hours, and a final report is due within one month.

Step 6: harden as you rebuild

Your previous state had weaknesses the attacker found and exploited. Rebuilding to the same configuration gives the next group identical conditions to work from.

As each system comes back online:

• Enforce MFA on all privileged accounts before connecting them to the network
• Deploy or verify EDR coverage on every endpoint before it joins production
• Review and implement Active Directory tiering: most ransomware moves laterally via over-privileged domain accounts
• Enable centralised audit logging before any system handles live data
• Apply all outstanding patches to the OS and applications before production

How long does recovery take?

Sophos State of Ransomware 2024 puts average recovery time at 21 days for full restoration of business operations. Large enterprise incidents average 38 days. Organisations with tested, air-gapped backups recovered in 13 days on average.

Faster recoveries had three things in common: a rehearsed incident response plan, backups tested within the previous six months, and a segmented network that limited how far the attacker could move.

How Cyvra helps

Cyvra supports ransomware recovery from initial scoping and forensics through post-incident hardening. We work alongside your internal teams or take the lead where capacity is limited.

• Incident scope and forensics: identify every affected system, compromised credential, and persistence mechanism before restoration begins
• Backup validation: independent assessment of backup integrity on isolated infrastructure before your team relies on it
• Clean room rebuild: restore critical systems from validated images in an isolated environment before returning them to production
• Regulatory notification: draft and submit GDPR and NIS2 notifications within required timelines
• Post-incident hardening: AD tiering, MFA rollout, EDR deployment, logging architecture, and network segmentation
• Tabletop exercises: rehearse your response before you need it, so decisions are made from a plan rather than under pressure

Contact our cybersecurity practice or read about our compliance and incident response services.