Linux server hit by ransomware: what to do right now

Updated November 2026

If files on a Linux server suddenly have strange extensions and a ransom note has appeared, cut the server off from the network, leave it running, and save evidence before you change anything. Then identify the ransomware, check for a free decryptor, report the attack and rebuild from backups you know are clean.

Do this first. In the first five minutes:

Disconnect the server from the network (unplug the cable, disable the switch port, or block all traffic in your cloud console). Do not shut it down unless you cannot disconnect it.
Do not reboot, wipe, reinstall or run “cleanup” tools yet. You will lose evidence and possibly the only copy of data still in memory.
Disconnect backup drives and stop backup jobs so the encryption cannot spread to your backups.
Use a phone or a separate, clean device to coordinate. The attacker may be reading email or chat on your network.

How to recognise it

Many files have a new extension added (for example report.pdf.locked) and no longer open.
A text or HTML file with a name like README, RESTORE_FILES or HOW_TO_DECRYPT sits in many directories and asks you to contact an email address or a Tor site.
On VMware ESXi or other hypervisors, virtual machines stop and their configuration or disk files are renamed or unreadable.
Databases, web applications and backups fail at the same time, often at night or over a weekend.

Modern ransomware groups often copy data out before encrypting it and then threaten to publish it. Treat every ransomware attack as a possible data breach as well.

The first hour

1. Isolate without powering off

The US Cybersecurity and Infrastructure Security Agency (CISA) says to isolate affected systems immediately and, if several systems are hit, to take the network offline at the switch level. It advises powering devices down only if you cannot disconnect them, because shutting down destroys volatile evidence such as memory. For a cloud server, apply a security group or firewall rule that blocks all traffic, and take a snapshot of the volumes.

If you only have console access (IPMI, iDRAC, a VPS web console), you can bring the network interface down from there. This cuts off any SSH session, so never run it over SSH:

# From the local or out-of-band console only. Find the interface name first.
ip -brief link
sudo ip link set dev eth0 down

2. Record what is happening

Before you change anything, save the current state to a USB drive or another machine, not to the affected disk (writing to it can overwrite deleted evidence). These commands work on Debian, Ubuntu and RHEL-family systems:

# Mount a clean USB drive first, for example at /mnt/ir
date -u | sudo tee /mnt/ir/time.txt
sudo ps auxwwf             | sudo tee /mnt/ir/processes.txt >/dev/null
sudo ss -tupan             | sudo tee /mnt/ir/connections.txt >/dev/null
sudo who -a                | sudo tee /mnt/ir/who.txt >/dev/null
sudo journalctl --since "-7d" | sudo tee /mnt/ir/journal.txt >/dev/null
sudo cp -a /var/log /mnt/ir/var-log

Write down the time you noticed the attack, what you saw, and everything you do from now on. CISA recommends a system image and memory capture of affected machines; if you have no experience with memory capture, leave it to an incident responder and keep the server running for them.

3. Make a disk image if you can

A cloud snapshot is the easiest option. On physical hardware, a responder may image the disk with dd. Double-check the device names: swapping if= and of= overwrites the evidence disk.

# if= is the affected disk, of= is a file on a large external drive
sudo dd if=/dev/sda of=/mnt/evidence/sda.img bs=4M conv=noerror,sync status=progress
sha256sum /mnt/evidence/sda.img | tee /mnt/evidence/sda.img.sha256

Identify the ransomware

Knowing the family tells you whether a free decryptor exists and how the group usually gets in.

Read the ransom note. It often names the group or links to a leak site. Do not contact the attacker yet.
Use ID Ransomware. Upload the ransom note and one encrypted sample file to ID Ransomware. It identifies the family and says whether a known decryption method exists. It does not decrypt anything. Choose a sample that holds no personal data: the site says unmatched files may be shared with malware analysts and it does not guarantee full confidentiality.
Check No More Ransom. No More Ransom was launched by the Dutch police’s National High Tech Crime Unit, Europol’s European Cybercrime Centre and security companies. Its Crypto Sheriff tool and decryptor list cover many families, but not all.

Do not trust random “decryption services”. Use decryptors only from No More Ransom or a security vendor you can verify. Test any tool on copies of encrypted files, never on the only copy.

Report the attack

United States: report to the FBI’s Internet Crime Complaint Center (IC3), your local FBI field office, or CISA. CISA’s guide lists all of these routes.
United Kingdom: use the government’s report a cyber incident service.
Elsewhere: No More Ransom keeps a list of national police reporting sites; where no online option exists, go to your local police.
Personal data: if personal data may have been taken, you may have legal notification deadlines. See what to do after a data breach.

Law enforcement may know of decryptors or keys that are not yet public, so report early.

Paying the ransom: the facts

Whether to pay is the victim’s decision, but you should know what the authorities say:

The FBI and CISA “do not encourage paying ransom as payment does not guarantee victim files will be recovered” (joint advisory on Akira ransomware).
The UK’s National Cyber Security Centre (NCSC) warns that payment does not guarantee access to your data, that stolen data may not be deleted, and that paying may be unlawful if the money goes to a sanctioned person or area. Paying also does not satisfy regulatory duties.
The US Treasury’s Office of Foreign Assets Control (OFAC) says the US government strongly discourages ransom payments. OFAC can impose civil penalties on a strict liability basis, meaning even if you did not know the recipient was sanctioned. It treats a prompt, complete report to law enforcement and full cooperation as significant mitigating factors.

Even with a working key, decrypting many terabytes can take days, and decryptors supplied by criminals are often buggy. A tested backup is usually faster.

Recover: rebuild, do not clean

Ransomware is the last stage of an intrusion. The attacker had access for some time and may have left backdoors, so do not decrypt or clean in place and put the same server back online.

Find the way in. Common entry points are VPNs without multi-factor authentication, unpatched internet-facing software, stolen or guessed SSH and admin passwords, and exposed management interfaces. Check for persistence and backdoors on the image or snapshot.
Check your backups. Use offline or immutable copies (copies that cannot be changed or deleted until a set date) taken before the intrusion. Scan them for malware before restoring, and connect backup media only to known-clean machines.
Rebuild from scratch. Install a fresh, supported operating system from official media, apply all security updates, then restore only data (not binaries, cron jobs or old configuration files you have not reviewed). See Restore from backup.
Rotate every credential. From a clean device, change all passwords, SSH keys, API tokens, database passwords and cloud access keys that the server or its admins used. CISA advises resetting passwords only once the environment is clean. See Leaked credentials.
Reconnect in stages and watch logs and outbound traffic closely for the first weeks.

# Debian/Ubuntu: after a fresh install, update everything
sudo apt update && sudo apt full-upgrade

# RHEL, AlmaLinux, Rocky Linux
sudo dnf upgrade --refresh

# Either: reboot if a new kernel was installed (this restarts the server)
sudo systemctl reboot

ESXi and Linux variants

Many ransomware groups now ship Linux encryptors aimed mainly at VMware ESXi, because encrypting one hypervisor takes down every virtual machine on it.

In February 2023, the ESXiArgs campaign hit unpatched and end-of-life ESXi hosts. It encrypted VM configuration files but left the large .vmdk flat disk files readable. CISA published a recovery script that rebuilds the configuration files, with a warning to review it before use. Its advice: update ESXi, disable the Service Location Protocol (SLP) service, and never expose ESXi hosts to the internet.
Akira added a Linux variant for ESXi in April 2023 and later a Rust-based encryptor that can stop running VMs; a November 2025 update also reports attacks on Nutanix AHV. Initial access often came through VPNs without multi-factor authentication and known vulnerabilities in VPN and backup products.

If your hypervisor was hit, check whether the flat disk files are intact before assuming data is lost.

Prevent the next one

Keep at least one backup copy offline or immutable, and test restores regularly.
Patch internet-facing systems first; see Emergency patching.
Require multi-factor authentication on VPN, SSO and admin panels; use SSH keys, not passwords. See SSH hardening.
Keep hypervisor management interfaces and backup servers off the internet.
Write a short incident plan with phone numbers, and practise it; see Incident response.

When to call a professional

Call an incident response firm, your cyber insurer or your hosting provider straight away if business-critical systems are down, personal or payment data may have been taken, you are considering payment, or you cannot find how the attacker got in. In the UK, the NCSC recommends using an NCSC-assured incident response provider. Keep the affected server running and untouched until they arrive.