Linux Ransomware Recovery: What To Do When Your Server Is Encrypted

By Arun Valecha, AV Services · Linux Infrastructure Expert since 1999

You open your terminal and see filenames ending in .locked. Or .encrypted. Or some random string of characters where your database files used to be. A text file on the desktop says your data has been encrypted and gives you a Bitcoin address. This is not a hypothetical. It happens to Linux servers in India every month — ERP servers, web servers, file servers, production databases.

This article is about what to do in the first 60 minutes, what your recovery options actually are, and what prevents it from happening in the first place.

How Linux servers get hit

The most common entry points in order of frequency: exposed SSH with weak or reused passwords, unpatched vulnerabilities in internet-facing services (Apache, Nginx, PHP, WordPress), compromised credentials from phishing, and RDP/VPN misconfigurations on hybrid environments.

The attacker does not always encrypt immediately. In many cases they sit inside for days or weeks — exfiltrating data, mapping the environment, disabling backup jobs, deleting snapshots. By the time the encryption notice appears, the last clean backup may be weeks old.

This is the detail most businesses miss. Ransomware on Linux is not just an encryption problem. It is a pre-attack persistence problem that often goes undetected until it is too late.

The first 60 minutes — what to do

Isolate immediately. Pull the server off the network. Not restart — network isolation. If it is a VM, suspend it. If it is physical, unplug the network cable. Every minute a compromised server stays connected, it can spread laterally, exfiltrate more data, or receive commands from the attacker’s infrastructure.

Do not wipe or reboot. The instinct is to restart or reinstall. Resist it. A running system preserves volatile evidence — active processes, network connections, in-memory encryption keys in some cases. A forensic image taken before a wipe can sometimes recover data or identify the attack vector.

Check your backups before anything else. The question is not “do we have backups” — the question is “when was the last backup that was actually verified to restore cleanly.” If your last verified backup is from 6 weeks ago, your recovery situation is different from someone whose backup was tested 3 days ago.

Call a specialist, not your hosting provider. Hosting support will offer to restore from their snapshot — which may be compromised, may be weeks old, and may reintroduce the same vulnerability that allowed the attack. You need someone who can forensically assess the environment before restoring anything into it.

Recovery options — realistic assessment

Clean backup available, attack vector identified. Best case. Restore to a clean environment, patch the entry point, verify integrity before bringing back online. Timeline: hours to a day depending on data volume.

Clean backup available, attack vector unknown. Dangerous case. Restoring without understanding how the attacker got in means restoring into the same vulnerable state. Forensic analysis of the attack vector is required before restoration. Timeline: 1-3 days.

No clean backup, data encrypted. Worst case. Options are: pay the ransom (no guarantee of recovery, funds criminal operations, legally questionable), attempt decryption (only works for specific ransomware families with known keys — rare), or accept data loss and rebuild from scratch. Timeline: days to weeks.

The pattern across every ransomware case I have been called to in 25 years is consistent: the businesses that recovered quickly had tested backups. The businesses that did not recover — or recovered with significant data loss — had backups they had never verified.

Prevention — what actually works

SSH hardening. Disable password authentication entirely. Key-based auth only. Change the default port. Use fail2ban to block brute force attempts. Audit active SSH keys every month — remove anything that should not be there.

Monthly patching. Most successful ransomware attacks exploit known vulnerabilities with published CVEs. A server that is patched within 30 days of a critical CVE is significantly harder to compromise than one running packages from 6 months ago.

Offline or immutable backups. A backup destination that is always mounted and writable can be encrypted along with the primary data. Borgbackup with append-only mode, or backups to a separate network segment, provide protection that a standard rsync job to a mounted drive does not.

Log monitoring. Unusual authentication patterns, new cron jobs, unexpected outbound connections — these are the signals of pre-ransomware activity. They appear in logs days or weeks before encryption. A managed server with active log review has a real chance of catching the intrusion before it completes.