114,000 files were encrypted but the database survived.

The Problem

The server hosted two .cn websites for an agency client in mainland China when Alibaba Cloud flagged suspicious activity. What I found was much bigger than a normal malware infection. A reverse shell was active, a Monero miner was running in the background, three webshells had been planted, and a new cPanel account with server access had been created. At the same time, .sorry ransomware had encrypted around 114,000 files across both websites. Replacing the server was not straightforward because the public IP had to be kept for China's ICP filing, customer email was on the same server, and there was no recent off-site backup. I handled the incident response, server investigation, data recovery, infrastructure rebuild, and security hardening.

What I Found

The first challenge was getting reliable access since the attackers had changed the SSH setup. Inspecting the system revealed an attacker-controlled SSH key, a new cPanel account with shell access, and a Monero miner hiding as /root/.rsyslogd. The attackers appeared to have started preparing the server in February 2025 before launching the ransomware on May 1, 2026. However, the most important discovery was that three MySQL databases, totaling around 1.8 GB, had not been encrypted. Because MySQL was actively using those files when the ransomware ran, it skipped them. The media files were badly affected, but the site's actual content (posts, comments, users, and plugin settings) was completely recoverable.

The Fix

Instead of trying to clean a deeply compromised operating system, I opted for a clean rebuild. After securing the environment with new SSH keys and strict security groups, I transferred the 1.8 GB of surviving databases to a clean Ubuntu 24.04 rescue server.

Once verified, the old CentOS 7 system was replaced with AlmaLinux 10.1 while keeping the public IP. I rebuilt the production stack with cPanel, Apache, MariaDB, PHP, and a fresh WordPress installation. I then imported the recovered databases, resolved network routing conflicts across the server's three public IPs, and implemented a 404 rule for missing ransomware-encrypted images to reduce server load.

Finally, I optimized performance by diagnosing a third-party plugin delay (cutting load times from 2.4s to 0.55s) and fixed a recurring cPanel permission issue that was taking the site offline daily.

The Result

The compromised server was retired and replaced with a clean, hardened production environment while retaining the client's existing IP addresses. The ransomware destroyed the website files, but because it did not destroy the database, the client's most valuable content was fully recovered. The agency's editor could log back in and continue working immediately.

The client not only avoided a catastrophic data loss but also moved to a documented, secure system with improved network routing, optimized plugin performance, and stable automated tasks.