Ransomware on a web server: a recovery playbook

Web server ransomware recovery comes down to six steps: contain the server without destroying evidence, identify what was hit, find how the attacker got in, rebuild on a clean server, restore from off-server backups taken before the intrusion, and rotate every password and key. Do not pay the ransom: No More Ransom, the project backed by Europol and the Dutch police, advises against it because payment funds criminals and does not guarantee a working key. And do not simply delete the encrypted files and restore on the same machine, because the attacker may still be inside.

This playbook is written for a Linux VPS or dedicated server that hosts websites, with or without a control panel. If you are not sure yet whether the server was compromised at all, start with how to check if your Linux server was hacked.

What ransomware on a web server looks like

On Linux web servers, ransomware is usually a script or binary dropped after the attacker gained root, not an email attachment. Typical signs:

• website files renamed with a new extension (.psaux, .locked and similar) and pages returning errors;
• a text or HTML ransom note in every folder or in the web root;
• databases dumped and dropped, sometimes replaced with a single table holding the ransom note;
• local backup folders encrypted or deleted;
• high CPU and disk activity, then silence.

A real example: in October 2024, attackers exploited two critical command injection flaws in CyberPanel 2.3.6 and unpatched 2.3.7 (CVE-2024-51378 and CVE-2024-51567). Help Net Security reported that around 22,000 exposed instances were hit and files encrypted with PSAUX and other ransomware, and that LeakIX released a decryptor for the .psaux variant. Our timeline of hosting panel security incidents has more cases like it.

The recovery timeline at a glance

When	Goal	Key actions
First hour	Contain	Provider snapshot, cut network access, keep the server running
Hours 1 to 4	Understand	Identify the variant, check for a decryptor, list what is encrypted
Day 1	Find the way in	Logs, panel version, known CVEs, new users, SSH keys, cron jobs
Day 1 to 2	Rebuild	New server, patched software, restore from clean backups
Day 2 to 3	Rotate and reopen	New passwords and keys everywhere, DNS switch, monitoring
Week after	Learn	Write down what happened, fix the backup and access gaps

Step 1: contain the server, but keep the evidence

Resist the urge to reinstall for an hour.

1. Take a snapshot at your VPS provider (disk snapshot or image). It preserves the encrypted files, the attacker's tools and the logs, which you need to find the entry point and possibly to decrypt.
2. Cut the server off the network except for your own IP. At the provider's cloud firewall, allow only SSH from your address, or use the provider's rescue console. CISA's ransomware response checklist puts isolating affected systems first, and suggests powering devices down only if you cannot take them off the network.
3. Keep the server running if you can. A running machine still holds processes, network connections and possibly keys in memory. Rebooting loses them.
4. Stop the bleeding elsewhere. If the attacker had root, assume they had every credential on the server: S3 keys, database passwords, SMTP relay passwords, API tokens. From a clean computer, change the most dangerous ones now, starting with your storage provider and your VPS provider account.

Step 2: identify what you are dealing with

• Read the ransom note but do not contact the attacker yet. Note the extension, the note's file name and any contact address.
• Check for a free decryptor. Upload a ransom note or an encrypted sample to No More Ransom's Crypto Sheriff. Some Linux variants have been decrypted, as the PSAUX case shows.
• List what is affected: website files, databases, mail, local backups, panel configuration. Check whether anything is still intact, for example databases the script did not reach.
• Report it. In the US, the FBI takes reports at IC3; elsewhere, contact your national CERT or police cybercrime unit. If personal data of EU residents was exposed, the GDPR expects the supervisory authority to be notified within 72 hours of becoming aware of a breach (Article 33). Check the rules that apply to you.

Step 3: find how they got in

Restoring before you know the entry point usually means restoring into the same hole. Look at, in order:

1. The control panel and its version. Compare it against advisories and the CISA Known Exploited Vulnerabilities catalog. An internet-facing panel with a known remote code execution bug is a frequent explanation for mass attacks.
2. SSH logins: last -F, lastb and journalctl -u ssh (or /var/log/auth.log). Look for logins from unknown IPs and at unusual hours.
3. Web logs around the first encrypted file's timestamp: POST requests to unexpected PHP files, panel endpoints or upload handlers.
4. Persistence: new users, ~/.ssh/authorized_keys, cron jobs, systemd units and timers. The commands are in how to check if your Linux server was hacked.

Write down what you find and when. It will decide which backup is safe and what to fix before going live again.

Step 4: rebuild, do not clean

Once an attacker had root, you cannot prove the system is clean: binaries, libraries and the kernel itself may have been modified. The safe answer is a new server:

• create a fresh VPS, ideally with a new IP address;
• install a current, supported OS and a patched version of your panel;
• restrict SSH and the panel port to your IPs from the first minute;
• only then restore data, never system files, from the old server.

Keep the old server's snapshot for investigation, but do not copy binaries, cron jobs or configuration files from it unless you have read them line by line.

Step 5: restore from a backup taken before the intrusion

Pick the restore point carefully. The right backup is the last one taken before the attacker got in, not the last one before the encryption. Attackers can wait days between breaking in and running ransomware, and a backup from that window can contain their backdoor.

Check that the backup itself is clean and complete: open a few files, check that databases import, and run a malware scan on the restored files before you switch DNS.

Restoring a ZoPanel server

ZoPanel's disaster recovery procedure is built for this case. You need the S3 settings, the recovery key and a new server running the same OS family:

1. Install ZoPanel on the new server.
2. In Settings → Remote backups, connect the same bucket and prefix. Use new access keys if the old ones were on the compromised server.
3. In Backups → Disaster recovery → Browse S3, open the old server's folder, then _panel, and Restore configuration from a .zpb file dated before the intrusion. Enter the recovery key.
4. Restore each account from its backup in the same view. Missing accounts are recreated with their websites, databases, mailboxes and DNS.
5. Set the panel domain, switch DNS to the new server, and let certificates be issued again.

Two limits to know in advance. App Store app data and S3 storage buckets are not in account backups or remote backups: they are backed up to /var/backups/zopanel-apps on the server, so if you did not copy that folder elsewhere, it is gone with the server. And without the recovery key, the encrypted copies on S3 cannot be read by anyone, so it must be stored off the server. The backups documentation explains every backup type and its retention.

Step 6: rotate every secret and reopen

Assume everything that was readable on the old server is in the attacker's hands:

• SSH keys and passwords of every admin, new keys generated on clean machines;
• panel passwords and 2FA (re-enrol), API tokens and billing system tokens;
• database passwords, then update the applications' configuration;
• WordPress security keys and admin passwords, so every session ends;
• S3, SMTP relay, DNS provider and payment gateway credentials;
• DKIM keys if you want to be thorough.

Then switch DNS, watch logs closely for a week, and tell your customers what happened and what they need to do, such as changing their own passwords.

Make the next ransomware attack a non-event

Gap	Fix
Backups only on the same server	Copies off the server, see the 3-2-1 website backup strategy
Off-server backups deletable with keys stored on the server	Bucket versioning or S3 Object Lock on the storage side, so uploaded versions cannot be deleted for a retention period
Panel open to the internet	IP allowlist, VPN or SSH tunnel
Panel running as root	A panel with privilege separation, so a web bug is not root
Password SSH	Keys only, Fail2ban
No restore test	Restore one account to a spare server every quarter
Recovery key only on the server	Password manager or paper copy, off the server

The storage-side protection matters because the server that uploads backups also holds the keys to delete them. Object Lock in compliance mode means, per AWS, that a locked version "can't be overwritten or deleted by any user, including the root user" of the account until its retention period ends. ZoPanel's documentation does not cover Object Lock, so if you turn it on at your provider, test that uploads and retention cleanup still behave as you expect.

Conclusion

Web server ransomware recovery is mostly decided before the attack: whether you have a backup the attacker could not reach, whether you know the recovery key, and whether you have practised a restore. On the day itself, contain first, find the way in, rebuild on a clean server, restore from before the intrusion and rotate every secret.

If you want this recovery path built in, the ZoPanel Free plan lets you try the panel with 3 hosting accounts and 10 websites, no time limit; encrypted remote backups and the S3 restore flow come with Pro. See the backup features for what is covered.

Frequently asked questions

Should I pay the ransom to get my website back?

Law enforcement and No More Ransom advise against it: payment funds further attacks and there is no guarantee you will receive a working key. Check for a free decryptor first and restore from backups if you have them.

Can I just restore my backup on the same server?

Not safely. If the attacker had root, they may have left backdoors, modified binaries or new SSH keys, and they can encrypt your restored files again. Rebuild on a fresh server and restore only data.

How do attackers get ransomware onto a Linux web server?

Common routes are an unpatched internet-facing application, such as a control panel or CMS plugin with a remote code execution bug, or through stolen or guessed SSH and panel passwords. Once they have root, the encryption script itself takes minutes.

Will ransomware encrypt my S3 backups too?

It can delete or overwrite them if the server holds keys with permission to do so. Use a bucket key that is limited to that bucket, and turn on versioning or object lock at the storage provider so old versions survive.

How long does it take to recover a web server from ransomware?

With off-server backups and a practised procedure, a small server can be back in hours. Without them, it can take days, and some data may never come back. The investigation to find the entry point is often the longest part.