Scenario solution
MySQL / MariaDB Database Encrypted by Ransomware
- MySQL
- MariaDB
- Percona Server
- 宝塔面板
- Nginx
- Apache Tomcat
- WordPress
- 电商与 OA Web 应用
When MySQL's ibdata1, .ibd and .frm files are encrypted, websites, online stores, OA and other web workloads all go down. Most cases start at a web application flaw or an exposed management panel. This page covers what InnoDB's file layout means for recovery, the value of binlogs, and the correct sequence.
Typical symptoms
- In the data directory (/var/lib/mysql, D:\MySQL\data) ibdata1, *.ibd, *.frm and *.MYD carry appended extensions
- mysqld will not start; the error log reports InnoDB page checksum failures, an invalid ibdata1 header, or a missing tablespace
- The site returns database connection errors (for example "Error establishing a database connection"); checkout and login fail entirely
- Ransom notes in HTML / TXT form appear in the web root, and some static assets and upload directories are encrypted too
- Binlogs, mysqldump .sql exports and backup directories are encrypted or wiped
- Unknown PHP / JSP files and unexpected scheduled tasks exist on the host, with suspicious upload and command-execution requests in the web access log
Business risk & common mistakes
MySQL cases differ from SQL Server cases in one obvious way: the entry point is usually on the web side, not the database side. Public reporting shows the TellYouThePass family, written in Go and cross-platform by design, has long been delivered at scale through high-severity flaws in web components and business systems — arbitrary file upload, command execution, deserialisation — encrypting web roots and database directories together once it lands. That explains why so many victims see "the website and the database hit at the same time".
The risk has three layers. Availability: corporate sites, storefronts, OA and mini-program back ends all stop, breaking order and payment flows. Data integrity: MySQL commonly carries members, orders and payment records, where a missing window of data is a material reconciliation problem. Exposure and compliance: member phone numbers and identity data are personal information, bringing notification and handling duties under China's Personal Information Protection Law that must be assessed with legal counsel.
The most dangerous actions in this scenario:
- Reinstalling the OS, or reinstalling MySQL into the original directory. A yum / apt reinstall overwrites residual files in the data directory — the most common irreversible mistake on Linux hosts.
- Repeatedly starting mysqld while stepping through innodb_force_recovery levels. With an encrypted tablespace, forced recovery triggers page discards and rewrites that destroy extractable pages.
- Using "repair table" in a control panel or phpMyAdmin, or deleting ibdata1 to get the service up.
- Restoring the website from backup over the original directory, flushing away both entry-point evidence and residual data.
- Running recovery tools on the original partition and writing results back to the same disk.
- Running the attacker's decryptor.
We do not recommend paying, and we do not negotiate on your behalf.
Our response plan
Isolate and preserve, starting with web entry-point evidence
Cut external access but keep the host live, and do not reinstall or overwrite the web directory. Image the whole disk, or at minimum the partitions holding the data and web directories, read-only. Evidence here centres on the web tier: preserve Nginx / Apache / Tomcat access and error logs in full, file timestamps for PHP / JSP files, upload directory contents, scheduled tasks and systemd units, /var/log/secure and SSH keys, plus the MySQL error log and binlog index.
Identify the family and encryption mode, and locate the exploited entry
Identify the family — watching for exploitation-driven lineages such as TellYouThePass — and the encryption mode, running segmented entropy analysis on ibdata1 and large .ibd files to distinguish full-file from header-only or intermittent encryption. In parallel, work backwards through the web logs to find the entry: suspicious upload requests, web shell paths, command-execution parameters, anomalous user agents and their timeline. The root-cause conclusion shapes hardening and reveals whether other hosts on the same segment are already affected.
Assess recoverability: tablespace repair, backup plus binlog, or rebuild
Assess three paths. Tablespace repair and extraction: InnoDB organises data in 16KB pages, so unencrypted pages still hold complete rows; even with damaged .frm or dictionary information, DDL can be inferred from the table layout or recovered from application code and ORM definitions before extraction. Backup plus binlog: where a usable mysqldump or physical backup exists and binlogs are intact, replay can reach close to the point of failure. Rebuild: backfill critical records from downstream systems — payment platform statements, logistics documents, third-party marketplace orders. Conclusions are given per database and per table.
Recover in a clean environment and validate the application
Build a clean host with the same MySQL major version as production and work only on the image. On the extraction path, load the schema first and then the data, verifying row counts and auto-increment values table by table; on the backup path, replay the full backup then the binlogs. Do not simply put the old website files back afterwards — application code needs web shell removal and an integrity comparison before it goes live, or the same entry point will be used again on day one.
Patch, reduce exposure, and sign off
Patch the specific flaw identified by forensics — upgrade components, forbid execution in upload directories, disable dangerous functions — then remove or harden management panels (keep control panels and phpMyAdmin off the public internet, change ports, whitelist sources, add a second factor), stop forwarding 3306, and reset all database and system credentials. Rebuild backups as logical backups plus binlog backups with one offline copy, not on the same host. Sign off against business metrics — order counts, member counts, continuity of the latest order numbers — with a report and remediation checklist.
Recovery paths
Recovery prospects for MySQL depend heavily on the storage engine and file layout, so several things must be established first.
Path 1: backup plus binlog replay. The best outcome. Where a logical backup (mysqldump / mydumper) or physical backup (XtraBackup, file-level cold copy) survived unencrypted and the binlogs are continuous, recovery can reach close to the moment of encryption. Check the binlogs specifically: many environments leave them inside the data directory, where they are encrypted alongside everything else; where they were written to a separate directory or shipped to another host, their value is considerable.
Path 2: InnoDB tablespace page repair and extraction. Applies where ibdata1 or .ibd files were header-only or intermittently encrypted. InnoDB pages default to 16KB and carry a page number and checksum, so untouched pages can be parsed directly into rows. The key constraint is schema information: with innodb_file_per_table each table has its own .ibd while structure lives in the data dictionary, so a damaged dictionary means recovering DDL from .frm files, application CREATE TABLE statements, ORM models or historical .sql dumps before parsing. The output is readable data; indexes and some rows may be missing.
Path 3: separate repair of MyISAM tables. Legacy systems still use MyISAM. Because .MYD data and .MYI index files are separate, a .MYD that was not fully encrypted plus a structure definition often yields fairly complete data.
Path 4: rebuilding from external and downstream data. Web and e-commerce workloads have an advantage: the data usually exists somewhere else too — payment platform statements, third-party marketplace orders, CDN logs, analytics warehouses, hot data still in cache, email and SMS notification records. These can rebuild order and member master data.
Path 5: snapshots and public decryptors. Inventory cloud instance snapshots, hypervisor snapshots and read-only NAS snapshots; a public decryptor applies only where family and version clearly match, and must be validated on a copy.
Stated plainly: full-file encryption, plus backups and binlogs encrypted in the same directory, plus a MySQL reinstall already performed, leaves very little room. We avoid "100%" and "guaranteed decryption", and we neither pay ransoms nor negotiate.
Common ransomware families
- No public decryptor
TellYouThePass
TellYouThePass is the archetypal vulnerability-driven ransomware family in China, mass-deployed against internet-facing ERP, OA, finance and middleware systems. It appends .locked and hits both Windows and Linux servers. No public decryptor exists.
- No public decryptor
Weaxor
Weaxor emerged in late 2024 as a same-lineage successor to Mallox, continuing its focus on MS SQL Server and exposed web services. It appends .rox, .weax or .wxx and drops a RECOVERY INFO.txt note. It has led infection volume in China through 2025 and 2026 (45.45% in July 2026, 65.74% in August 2026) and has no public decryptor.
- Some versions decryptable
Mallox
Mallox (also known as TargetCompany) breaks in mainly through brute-forced MS SQL Server credentials, targets database servers specifically, and has a Linux/ESXi variant. Files encrypted between 2023 and early 2024 may be decryptable with Avast's free tool; later builds have no public decryption method.
- Free decryptor available
Phobos
Phobos is a RaaS family that relies mainly on brute-forced RDP and has spawned a long list of variants (.eking, .faust, .elbie, .devos and more). It has been a persistent presence in Chinese server-ransomware cases, and in July 2025 Japan's National Police Agency released a free decryptor covering part of the lineage.
- Some versions decryptable
Crysis / Dharma
Crysis (CrySiS) and its successor Dharma have been active since 2016, breaking in through brute-forced RDP and spawning many variants including .cezar, .arena, .bip, .combo and .java. Early versions have free decryptors; the .cezar family from 2017 onward does not.
Hardening recommendations
- Keep 3306 off the public internet. Bind the database to the internal network or 127.0.0.1 and route remote administration through a VPN or jump host; never leave a 0.0.0.0/0 rule for 3306 in a cloud security group.
- Management panels are high-risk entry points. Do not expose control panels, phpMyAdmin or Adminer publicly; where they are necessary, change default ports, bind source IPs, add a second factor and keep the panel updated.
- Patch web applications and components monthly. Public reporting shows families such as TellYouThePass rely chiefly on high-severity flaws in web components and business systems, so frameworks, middleware, CMS plugins and upload components all belong in scope.
- Forbid execution in upload directories. Disable script handling for upload paths in Nginx / Apache, turn off dangerous PHP functions such as system and exec, and restrict open_basedir.
- Keep binlogs and backups outside the data directory. Enable binlogging to a separate location, ideally shipped to another host, and write at least one logical or physical backup to offline or immutable storage under a dedicated account.
- Least privilege for database accounts. Do not grant FILE, SUPER or PROCESS to application accounts, disable remote root logon, and remove anonymous accounts and the test database.
- Harden the Linux host. Disable SSH password authentication, audit authorized_keys and crontab changes, deploy host security with ransomware behaviour detection, and monitor for mass file rewriting.
- Run restore drills. Each quarter, fully restore a production database from backup plus binlogs in an isolated environment and time it, to prove the chain works.
Emergency response
Data already encrypted? Stop and let an engineer look first
We do not pay ransoms and we do not negotiate with attackers. Engineers run a free assessment first, then propose a recovery plan and a firm quote.
Related industries
Retail and E-commerce Ransomware Response
In retail and e-commerce, ransomware translates directly into an inability to sell: order systems, membership, POS and warehouse fulfilment stop together and losses accrue by the hour. This page covers the sector's attack patterns, a recovery order built around the order-to-fulfilment chain, and handling of member data exposure.
Education and Research Ransomware Response
Schools and research institutions run open networks with dispersed endpoints and systems built across many eras, often unattended at night and during holidays — a combination attackers exploit. This page covers the sector's threat profile, recovery priorities for academic and research data, and defences suited to campus networks.
Logistics and Supply Chain Ransomware Response
Logistics is acutely time-sensitive: when TMS, WMS, dispatch and sorting systems stop, goods pile up in warehouses and on routes immediately, and the effect propagates up and down the supply chain. This page covers the sector's threat profile, a recovery order built around goods movement, and hardening for EDI-interconnected environments.
Government and Public Sector Ransomware Response
Public sector ransomware incidents run on three lines at once: service interruption, data security and mandatory reporting. When document circulation, archives and integrated service platforms stop, both public services and internal operations are affected. This page covers the handling sequence, reporting duties and hardening priorities.
Related services
Data Recovery
Recovery beyond decryption: backup repair, database repair and remnant extraction.
Incident Response
Round-the-clock intake: contain first, preserve evidence second, recover third.
Ransomware Decryption
Identify the family first, then commit to a recoverable scope — without paying a ransom.
Security Hardening
Close the handful of paths attackers actually use: exposure, weak credentials, patches, privilege, backups.
FAQ
Frequently asked questions
ibdata1 is encrypted — can the data still be extracted?
It depends on encryption coverage. InnoDB organises data in 16KB pages, each carrying a page number and checksum, so if only the header of ibdata1 was encrypted — common with large files — the pages behind it can still be parsed row by row. The real difficulty is usually not the data but the schema: with the dictionary damaged, DDL must be recovered first, from .frm files, CREATE TABLE statements in the application, ORM model definitions or historical .sql dumps. With full-file encryption this path largely fails, and you move to backups, binlogs and downstream reconstruction.
Both our website files and the database were encrypted — how did they get in?
Simultaneous encryption of both strongly indicates a web-side entry. The typical chain is: an attacker exploits an arbitrary file upload or command execution flaw in a framework, middleware, CMS plugin or business application to write a web shell, escalates from the web user's privileges, and then encrypts the web root and the database directory on the same host. Public reporting shows TellYouThePass has delivered at scale exactly this way. The other common entry is a weak password on an internet-exposed management panel. During forensics we trace the request chain back through web access logs and report the specific flaw and timeline.
Can innodb_force_recovery save it?
Not against the original data directory. innodb_force_recovery is designed for logical corruption and crash recovery: at startup it discards problem pages, rebuilds some structures and writes new logs. Against an encrypted tablespace it cannot recover data and will overwrite pages that were still parseable. The correct approach is to image the partition holding the data directory read-only and run entropy analysis and page-level parsing on the copy; where engine-level recovery is genuinely worth trying, do it on the copy and keep the original image untouched.
Member and order data includes personal information — must we report it?
That is a decision to make with legal and compliance, but technically you first need to establish whether exfiltration occurred. Current families routinely steal data before encrypting, so our forensics focuses on outbound indicators: anomalous egress traffic, staged archive files, cloud storage and FTP upload records, and the transfer tools the attacker used. The conclusion goes into the report as the factual basis for your assessment under the Personal Information Protection Law, the Data Security Law and applicable cybersecurity incident reporting rules. We supply the technical facts; we do not substitute for legal judgement.
Can a managed cloud MySQL (RDS) instance be encrypted?
A managed RDS instance gives you no OS access, so ransomware cannot encrypt datafiles the way it does on-premises — but two risks remain. First, an attacker with privileged database credentials can drop databases, delete backups or extort over the data itself. Second, a self-managed MySQL running on a cloud VM is no different from an on-premises host and can be encrypted normally. So in the cloud the emphasis falls on account and access control, enabling automated backups retained in a separate account or region, and alerting on destructive operations. During assessment we first establish whether you run a managed instance or a self-built one.
Updated