What should we do when a Linux server or BT Panel is hit by ransomware?

"Ransomware" on a Linux web server comes in two forms that call for entirely different responses, so tell them apart first.

Wipe-and-ransom needs no malware at all - a database logon is enough. The PLEASE_READ_ME operation disclosed by Guardicore (now part of Akamai) started in January 2020: it brute-forced internet-facing MySQL, archived and exfiltrated the data, deleted it from the server and left a ransom table named WARNING. Its dashboard listed 250,000 databases from 83,000 servers and used a leak site for pressure. The MongoDB wiping wave of early 2017 showed the other side: BleepingComputer reported rival gangs overwriting each other's ransom notes, some groups deleting data without downloading it at all, and victims who paid getting no reply.

So the question with a wiped database is not only whether to pay, but that nobody can confirm beforehand whether the attacker holds the data, or which crew holds it. Even if they did keep it, the exposure has already happened and paying does not undo the compliance consequences. Our position matches should you pay the ransom: no payment, no negotiation - spend the time finding the data. The two techniques can also appear together: in its published incidents, JadePuffer encrypted configuration fields in place and also dropped application databases, leaving a README_RANSOM table.

Work down this list, most reliable first.

1. Backups and snapshots. mysqldump exports from the panel or scripts, physical backups, cloud disk snapshots, replicas. Check where each backup lives: backups on the same machine and the same disk as the database are often deleted with it, so copies on another host, in object storage or on offline media matter most.

2. Binlog replay. MySQL's documentation describes the binary log as the data source for point-in-time recovery: restore a full backup, then use mysqlbinlog to re-execute the changes made after it, stopping just before the DROP statements. Binary logging is on by default in MySQL 8.0; older versions and manually initialised instances need checking one by one. Know the limits, too. A binlog records changes, so without a full backup as a starting point it can rebuild a table on its own only if the retained binlogs cover the table's entire history since creation. An attacker with high privileges may also purge binlogs, so copy the existing files out as soon as possible.

3. Recovering deleted data files at disk level. This depends on tablespace layout. MySQL's documentation states that InnoDB creates a separate tablespace file (.ibd) per table by default, and that dropping such a table returns the disk space to the operating system. In other words the .ibd was deleted at filesystem level, but its blocks may remain on disk until something overwrites them, so the file can be recovered from the image or rows can be extracted by scanning for InnoDB page structures. A table in a shared tablespace leaves its space marked reusable inside InnoDB, and pages not yet reused can be scanned in the same way. Either way, stop all writes to the partition immediately and work only on the image. How much comes back depends on how much was written after the wipe, and we do not promise a ratio in advance.

4. Rebuilding from the business side. Payment platform statements, third-party marketplace orders, caches, logs and notification records can fill in orders, members and other critical data.

If ibdata1 or .ibd files were genuinely encrypted and renamed, page-level repair and encryption-coverage analysis are covered in MySQL encrypted by ransomware. When MongoDB, Elasticsearch or Redis is wiped the logic is the same: secure the persistence files on disk, snapshots and replica nodes first, analyse copies, and do not rush to restart the service or rebuild the instance.

Entry to Linux web servers is almost always on the internet-facing side. Check these categories one at a time:

• Web application and component flaws. Critical vulnerabilities in frameworks, middleware, CMS plugins and business applications are scanned for and exploited in bulk; the attacker writes a web shell, then encrypts the web root and the database directory. TellYouThePass is the best-known family on this route: in December 2021 it was deployed through Log4j, and its Linux build harvests SSH keys to move across the internal network.
• Hosting control panels. In August 2020 BT Panel disclosed an unauthorised database-management access flaw affecting Linux 7.4.2, test build 7.5.14 and Windows 6.8, where requesting a specific URL opened the database management page directly; the fixes were 7.4.3, 7.5.15 and 6.9.0. In December 2022 a number of BT Panel users reported the Nginx binary being replaced, malicious JavaScript injected into pages and logs wiped. BT's official notice said no vulnerability had been found in the panel or Nginx so far and advised upgrading the panel, changing the security entrance and passwords, enabling two-factor authentication and tamper protection; no public conclusion on the entry point has emerged since. In February 2026 Datadog Security Labs documented attackers who, after exploiting React2Shell, used a script written specifically for BT Panel to rewrite the Nginx configurations it manages and hijack traffic. cPanel/WHM is a target as well - the Sorry ransomware spread in bulk through its authentication bypass.
• Database and cache ports. 3306, 27017, 6379 and 9200 exposed to the internet with weak passwords or no authentication are the entry for wipe-and-ransom. Redis's own documentation advises against exposing it directly to the internet and notes that clients can use the CONFIG command to write files to arbitrary paths, which can lead to compromise of the whole host.
• Weak and reused SSH passwords. Once one host falls, the attacker uses the same password or harvested keys to log in to other Linux hosts on the network.

The evidence for the entry point sits mainly in web access logs, panel logs and SSH authentication logs - which is exactly why reinstalling first is a mistake.

Most back doors on a Linux host survive a password change, which is exactly why so many servers are encrypted or wiped again after recovery. A compromised host should be rebuilt; where it genuinely has to be examined in place, check at least the following:

• Accounts and keys: new accounts or accounts with UID 0 in /etc/passwd, unfamiliar public keys in every user's authorized_keys including root's, and changes to sudoers.
• Scheduled jobs: every user's crontab, /etc/crontab, /etc/cron.d and the cron.hourly-style directories, plus unfamiliar entries in the panel's scheduled tasks.
• Services and start-up hooks: new or modified systemd services and timers, /etc/rc.local, and start-up commands in /etc/profile.d and users' shell profiles.
• Web directories: new php or jsp files in upload directories and the web root, files with odd timestamps, and anything that differs from the code repository.
• Binary integrity: whether long-running programs such as Nginx and sshd have been replaced - in the December 2022 BT Panel episode it was precisely the Nginx binary - plus executables under /tmp and /dev/shm and unexplained processes.
• The panel itself: whether panel accounts, the security entrance or the allowed IP list were changed, and whether the panel is on the latest version.

After the sweep, change every password and key: system accounts, SSH keys, panel accounts, database accounts, and the database connection strings and cloud AccessKeys in application configuration. For the wider root-cause picture see why ransomware keeps coming back.

Not entirely. These cases have their own pages:

• VMware ESXi hosts encrypted. These encryptors are often described as Linux builds, but they target virtual disks on the datastore; the shutdown, snapshot deletion and vmdk encryption behaviour and the recovery paths differ from a web server's. See virtualization platforms encrypted.
• Synology, QNAP and other NAS devices encrypted. NAS operating systems are Linux-based too, but the work centres on storage volumes and snapshots. See servers and NAS encrypted.
• Windows and cloud servers on the same network. Remote desktop and SQL Server entry points and shadow copies are covered in what to do when a server is hit by ransomware.

Mixed environments are common: after a web server falls, the attacker may go on to the database server, the backup server or even the hypervisor management interface on the same segment. Scope the investigation by actual network reachability and credential reuse, not by operating system.