![Ransomware Recovery Plan: 6 Steps [Solved] 2026](/images/blog/ransomware-recovery-plan-6-steps-solved-2026.jpg)
The moment you discover ransomware on a production server, the clock starts. Every minute of confusion or hesitation gives the malware more time to spread laterally, encrypt additional shares, or destroy shadow copies. I've walked hosting clients through dozens of these incidents, and the teams that recover fastest always follow a clear playbook.
This recovery plan assumes you're already hit. It won't prevent an attack, but it will give you a structured path from discovery to restoration. You'll need root or administrator access, recent backups that weren't compromised, and a separate machine to coordinate work from.
Step 1: Isolate infected systems immediately
Disconnect compromised machines from the network before you do anything else. Pull the Ethernet cable if you're on-site, disable the network adapter in the hypervisor console for VMs, or use firewall rules to block all traffic at the switch level. The goal is to stop the ransomware from reaching file shares, backup repositories, or other hosts.
Do not shut down infected servers yet. Many ransomware families encrypt data in memory before writing it to disk, and a forced shutdown can flush encryption keys or partial work that forensic tools might recover later. Disconnecting the network buys you time without destroying evidence.
Once isolation is complete, take inventory:
- Which servers show ransom notes or encrypted file extensions?
- What shared drives, NAS volumes, or cloud storage mounts were accessible from those hosts?
- Are any backup agents or replication jobs still running?
Document everything with screenshots and timestamps. You'll need this timeline for insurance claims, law enforcement reports, and post-incident reviews.
Step 2: Verify backup integrity and accessibility
Your backups are the only leverage you have against the attacker's ransom demand. But ransomware operators know this too, which is why modern strains specifically hunt for backup software processes, network shares with "backup" in the path, and cloud storage API keys.
Check three things:
Are the backup files themselves encrypted? Mount your most recent backup on a clean, isolated machine and inspect a sample of files. If everything has a .locked or .encrypted extension, the ransomware reached your backup storage.
Can you restore a test file? Don't assume the backup job log is accurate. Actually restore a single file or small directory from last week's backup and verify its contents. I've seen backup jobs report success for months while silently failing to write data.
How old is your last clean backup? If the ransomware was dormant for days or weeks before activating, your recent backups might all contain encrypted files. Look for the oldest snapshot that predates the infection window you identified in step 1.
If your backups are intact and restorable, you have options. Skip ahead to step 4. If backups are compromised or too old to be useful, continue to step 3.
Step 3: Evaluate decryption tools and ransom payment
Some ransomware families have known weaknesses or publicly released decryption keys. Before considering payment, search for your specific ransomware variant on sites that track decryptors and security researcher toolkits. The file extension or ransom note text usually identifies the strain.
Upload a sample encrypted file and the ransom note to online identification services. These tools compare your files against known signatures and tell you which ransomware you're dealing with. If a free decryptor exists, download it from the official source and test it on a small set of files on an isolated machine.
If no decryptor is available, you face a decision about payment. Most law enforcement agencies and security professionals recommend against paying because:
- Payment funds future attacks
- There's no guarantee the attacker will provide a working decryption key
- Paying marks you as a willing victim for follow-up extortion
But I've also worked with businesses where the cost of downtime exceeded the ransom by orders of magnitude, and backups didn't exist. If you choose to pay, involve legal counsel and document the decision thoroughly. Use a cryptocurrency exchange with transaction records, and understand that decryption—even with a key—can take days or weeks for large datasets.
Step 4: Restore from backup or rebuild systems
Assuming you have clean backups, the restoration process depends on what you're recovering. Full server images let you spin up replacement VMs quickly. File-level backups require you to rebuild the OS first, then restore data.
Start with critical infrastructure in this order:
- Domain controllers or identity providers
- Database servers
- Application servers
- File servers and collaboration tools
- Workstations
Build each replacement system on a separate VLAN or isolated network segment. Do not reconnect restored machines to your production network until you've completed step 5.
Before you restore data, scan the backup source for hidden malware. The ransomware might have been present but dormant in your environment for weeks. Restoring a backup that contains the initial compromise just resets the clock. Use multiple antivirus engines and scan for web shells, unauthorized SSH keys, and scheduled tasks you don't recognize.
For database restores, validate consistency after recovery:
mysqlcheck --all-databases --check --auto-repair
For PostgreSQL:
vacuumdb --all --analyze
Check application logs immediately after restore to confirm services are starting correctly and data integrity is intact.
Step 5: Patch vulnerabilities and reset credentials
Ransomware usually enters through one of these doors: unpatched software, stolen credentials, or phishing. Before you bring restored systems back online, close the entry point.
Apply all pending security updates to operating systems, control panels, CMS platforms, and third-party applications. If you're running end-of-life software, now is the time to migrate. An old version of cPanel, an unsupported PHP release, or an outdated WordPress installation will just give the attacker another opportunity.
Reset every password and credential in your environment:
- Root and administrator passwords on all servers
- Database user passwords and connection strings in application configs
- SSH keys, especially any authorized_keys files
- API tokens for cloud services, backup software, and monitoring tools
- Control panel credentials for cPanel, Plesk, or WHM
Disable or delete any accounts you don't recognize. Check for recently created users:
grep -E ':0:' /etc/passwd # Look for unauthorized root-equivalent accounts
lastlog | grep -v "Never" # Recent login activity
Review sudo privileges and remove any overly permissive rules.
Enable multi-factor authentication everywhere it's supported. Even a simple TOTP app on your phone eliminates most credential-stuffing and brute-force attacks.
Step 6: Communicate with stakeholders and document the incident
You'll need to notify several groups, depending on your jurisdiction and industry:
Customers and users expect transparency about downtime and data exposure. Draft a brief status update explaining that you're responding to a security incident, what services are affected, and when you expect restoration. Avoid technical jargon and ransom details.
Law enforcement should be contacted even if you don't plan to pursue prosecution. Many agencies maintain databases of ransomware attacks and payment wallets. Your report might help disrupt the operation or recover funds.
Insurance carriers require timely notification for cyber insurance claims. Read your policy carefully—some insurers have 24- or 48-hour reporting windows.
Regulatory bodies depend on your industry. Healthcare organizations must report breaches affecting protected health information. Financial services, government contractors, and companies handling EU citizen data face specific disclosure requirements.
Internally, write an incident timeline while details are fresh. Include:
- Date and time of discovery
- Affected systems and data
- Actions taken during isolation and recovery
- Root cause if identified
- Recovery time objective vs. actual recovery time
This document becomes the foundation for your post-mortem and the starting point for improving your incident response plan.
What happens if backups were encrypted too?
If your backups are gone and no decryptor exists, your options narrow to rebuilding from scratch or paying the ransom. Rebuilding means accepting data loss back to the last unaffected snapshot or to zero if you have no backups at all.
In that scenario, focus on restoring service first and reconstructing data second. Rebuild your infrastructure with clean OS images, redeploy applications from source control, and restore configuration from documentation or infrastructure-as-code repos. Then contact customers and partners to recover transactional data, uploaded files, or user content they might have copies of.
It's painful and slow. But I've seen hosting providers recover from total data loss by being transparent with customers, offering service credits, and rebuilding trust through improved security practices going forward.
How long does recovery typically take?
It depends entirely on the size of your environment and the quality of your backups. A single VPS with daily backups might be back online in hours. A multi-server hosting platform with petabytes of customer data can take weeks.
The decryption process itself—if you obtain a key—is often the slowest part. Decryption tools are rarely optimized, and processing encrypted files one by one across slow disks takes time. I've watched decryption jobs run for three to five days on moderately sized file servers.
Plan for at least 48 to 72 hours from isolation to production restoration for a typical small hosting environment. Larger infrastructures should expect a week or more.
First steps when the ransom note appears
Disconnect the network. Verify your backups. Don't assume anything about your environment's security until you've validated credentials, patched software, and confirmed the initial access vector is closed.
Ransomware recovery isn't about defeating cryptography—it's about isolating damage quickly, restoring from known-good state, and preventing reinfection. The teams that recover fastest have tested their backup restoration process before they needed it in a crisis.
If you're reading this after an attack, work through these six steps methodically. If you're reading it before one, test your backups today. Then test them again next month.