Ransomware hits hard and fast. Files vanish behind encryption, services stop, and a ransom note appears demanding payment. In the tickets I've handled, the first question is always the same: do we pay or do we restore?
Paying guarantees nothing—decryptors can fail, and you mark yourself as a willing target. A tested recovery plan gets you back online faster and cheaper. The workflow below assumes you have backups and basic forensic discipline. If you don't have backups, your options shrink to negotiation or data loss.
Step 1: Isolate the infected systems immediately
Ransomware spreads through open SMB shares, admin credentials, and trust relationships. The moment you confirm encryption, cut network access.
Disconnect Ethernet cables or disable network adapters at the hypervisor level for VMs. Do not rely on OS-level firewall rules—the malware may have disabled them already. If the infected machine is a VM, snapshot it in its current encrypted state before taking it offline. That snapshot is evidence and a fallback if forensics reveal something unexpected.
For a physical server, pull the network cable and document the time. Check connected storage arrays and NAS devices for signs of encryption spreading there. In a multi-server environment, isolate the entire VLAN or subnet if you're uncertain which machines are compromised.
Leave the infected systems powered on but isolated. Shutting them down can destroy volatile memory that forensic tools need later. If you must power down, capture a memory dump first using a live USB tool.
Check your firewall logs and SIEM alerts for lateral movement. Ransomware often hops from an initial foothold to domain controllers and backup repositories. Block outbound traffic from the isolated segment to prevent command-and-control callbacks.
Step 2: Verify your backups before touching them
Backups are the recovery lifeline, but ransomware actors know that. Modern variants hunt for backup directories, mounted snapshots, and cloud sync folders to encrypt those too.
Before restoring anything, verify backup integrity on a separate isolated network or a test system with no route back to production. Mount the most recent backup read-only and check a sample of critical files. Open configuration files, databases, and application data to confirm they're not encrypted.
If the most recent backup shows encryption, walk backward through older snapshots until you find a clean set. Document the time delta between the last clean backup and the encryption event—that gap represents potential data loss.
Test the restore process on a throwaway VM. Don't assume your backup software will work under pressure. I've seen backup tools fail because their licenses expired, credentials rotated, or the restore target had insufficient disk space. Run a full restore of one critical service and validate that it starts correctly.
For database backups, run integrity checks:
# PostgreSQL
pg_restore --list backup_file.dump
# MySQL
mysqlcheck --all-databases --check
# MongoDB
mongorestore --dryRun --archive=backup.archive
If every backup generation is encrypted, your options narrow. Evaluate whether the encrypted data is recoverable through other means—log files on a separate logging server, database replicas in another region, or file versions in an S3 bucket with versioning enabled.
What if the backups are gone?
You're now in data-loss territory. Paying the ransom becomes a business decision weighed against the value of the data and the reputational cost of funding criminal operations. Even if you pay, decryption can take days and rarely restores everything.
Some organizations choose to rebuild from scratch and accept the data loss. Others engage ransomware negotiation firms. I won't recommend either path—that's above my pay grade—but I will say this: if you're in this position, get legal and insurance advisors involved immediately.
Step 3: Identify the infection vector and timeline
Before you restore, figure out how the ransomware got in. Restoring onto a system with the same vulnerability invites reinfection within hours.
Check authentication logs for unusual logins or privilege escalations. Ransomware often enters through compromised RDP credentials, unpatched VPN appliances, or phishing emails with malicious attachments. On Linux, review /var/log/auth.log and /var/log/secure. On Windows, examine Event IDs 4624 (successful logon) and 4672 (special privileges assigned).
Look for recently modified binaries, scheduled tasks, and cron jobs created in the days before encryption:
# Find binaries modified in the last 7 days
find /usr/bin /usr/sbin /bin /sbin -type f -mtime -7
# Check for new cron jobs
grep -r "" /var/spool/cron/ /etc/cron.*
# List recently added systemd services
find /etc/systemd/system /usr/lib/systemd/system -type f -mtime -7
On Windows, review Task Scheduler and startup folders. Malware drops persistence mechanisms before deploying the payload.
Correlate file modification timestamps with firewall logs and process accounting data. The goal is to map a timeline: initial compromise, lateral movement, privilege escalation, and finally encryption.
If you find the entry point—an exposed service, a stolen credential, a vulnerable application—patch or disable it before proceeding. If the vector remains unclear, assume the worst and treat the entire network as potentially compromised.
Step 4: Rebuild critical systems from clean base images
Restoring from backups is tempting but risky. Backups can contain the dropper binary or persistence mechanisms that survived the backup process. The safest recovery path is a clean OS install followed by selective data restoration.
Start with the most critical services: authentication servers, database systems, and anything revenue-generating. Rebuild from known-good installation media—official vendor ISOs or trusted container images.
For Linux servers:
# Reinstall OS from verified media
# Minimal package set only
# Harden immediately
apt install unattended-upgrades fail2ban
systemctl enable --now fail2ban
# Restore only data files, not binaries
rsync -av --exclude '*.exe' --exclude '*.sh' /backup/data/ /srv/app/
For Windows servers, use a clean Windows Server ISO and rejoin the domain only after confirming the domain controllers are clean. Do not restore the entire system state—rebuild role configurations by hand and restore user data separately.
Change all administrative passwords before bringing systems back online. Rotate API keys, database credentials, and SSH keys. Ransomware actors often exfiltrate credentials during the pre-encryption reconnaissance phase.
Install EDR or antivirus with updated definitions before connecting to the network. Run a full scan of restored data before services go live.
Step 5: Bring services online in controlled stages
Don't flip everything back at once. A phased restoration lets you catch reinfection early and limits blast radius if something goes wrong.
Start with isolated test instances. Restore one application server, connect it to a quarantine VLAN, and monitor for 24 hours. Watch for unexpected network connections, CPU spikes, or file modifications. Use tools like auditd on Linux or Sysmon on Windows to log process creation and network activity.
If the test instance stays clean, restore the next tier—databases, web servers, mail relays. Keep each tier isolated until validated. Monitor firewall logs for traffic patterns that match known ransomware behaviors: scanning internal IPs, connecting to Tor exit nodes, or bulk file transfers.
As services come online, verify data integrity with application-level checks. For WordPress sites, confirm that themes, plugins, and uploads directories contain expected files. For databases, run schema validation and check row counts against pre-incident baselines.
Document every restored system, the backup snapshot used, and any configuration changes made during rebuild. That documentation is your audit trail and your disaster recovery playbook for next time.
Step 6: Capture forensic evidence and file reports
Once systems are stable, circle back to forensics. Ransomware is a crime, and you may need evidence for insurance claims, law enforcement reports, or regulatory disclosures.
Preserve disk images of infected systems using dd or commercial forensic tools. Hash the images and store them on write-once media. Do not attempt forensic analysis on live production systems—work from copies in an isolated lab environment.
Document the incident timeline, affected systems, data loss estimates, and recovery costs. If you're subject to breach notification laws, consult legal counsel on disclosure requirements. Many jurisdictions mandate reporting within 72 hours.
File a report with law enforcement even if you don't expect prosecution. Agencies like the FBI's Internet Crime Complaint Center aggregate ransomware reports to track threat actors and occasionally recover decryption keys from seized infrastructure.
Check if your attackers are on public lists of known ransomware groups. Some strains have free decryption tools released by security researchers after law enforcement takedowns. The No More Ransom project maintains a repository of free decryptors.
Hardening to prevent the next attack
Recovery is step one. Prevention is the rest of your year.
Segment your network so ransomware can't hopscotch from workstations to servers. Put critical infrastructure behind VLANs with strict firewall rules. Disable SMBv1 and restrict file shares to read-only where possible.
Implement offline or immutable backups. Tape backups, air-gapped NAS devices, or S3 buckets with object lock prevent ransomware from encrypting your safety net. Test restores quarterly, not when you're under attack.
Enforce multi-factor authentication on all administrative access. Ransomware loves weak RDP passwords and VPN credentials. Use certificate-based authentication where possible and monitor for brute-force login attempts.
Patch aggressively. Ransomware exploits known vulnerabilities in VPN appliances, web applications, and unpatched Windows systems. Automate patching where you can and track CVE exposure on critical assets.
Train staff to recognize phishing. Most ransomware starts with a malicious email attachment or link. Regular tabletop exercises keep security top-of-mind.
How long does ransomware recovery take?
It depends on backup quality and system complexity. Restoring a single server from verified backups can take hours. Rebuilding a multi-tier application with database dependencies and integrations can take days. The longest delays come from backup corruption or discovering that backups don't exist.
Should I pay the ransom?
That's a business and legal decision, not a technical one. Payment doesn't guarantee decryption, funds criminal operations, and may violate sanctions laws if the attacker is in a sanctioned country. Consult legal counsel and cyber insurance providers before paying.
Can I decrypt ransomware without the key?
Rarely. Modern ransomware uses strong encryption algorithms that are mathematically secure. Some older strains or poorly implemented variants have been cracked by researchers, but don't count on it. Check the No More Ransom project for free decryptors before assuming decryption is impossible.
How do I know my restored systems are clean?
Monitor them closely for days after restoration. Watch for unexpected network connections, new processes, file modifications outside of normal activity, and authentication attempts from unusual IPs. Deploy endpoint detection and response tools that baseline normal behavior and alert on anomalies.
What if ransomware encrypted my backups too?
Walk backward through backup generations until you find a clean set. If every generation is encrypted, evaluate alternative data sources—offsite replicas, cloud sync folders with versioning, or log aggregation systems that captured data. If no clean data exists, you're in data-loss territory.
What to prioritize right now
If you're reading this after an attack, start with network isolation and backup verification. Those two steps prevent further damage and confirm whether recovery is possible.
If you're reading this as preparation, test your backups today. A backup you've never restored is a backup you don't have. Set up offline or immutable storage, segment your network, and document your recovery runbook while you're not under pressure.
Ransomware recovery is a race between restoration and business impact. Speed matters, but accuracy matters more—reinfection costs you twice the downtime and twice the reputation damage. Build your recovery plan around clean rebuilds, verified backups, and the discipline to map what went wrong before you flip the lights back on.