MySQL Ransomware/malware/virus encrypted idb frm datafiles

MySQL ransomware families (Devos, Phobos, Eking, Makop and similar variants) target a MySQL or MariaDB datadir and rewrite the head of every .ibd, .frm, .MYD, .MYI and db.opt file. A typical filename after encryption looks like users.ibd.id[C817875D-2700].[[email protected]].Devos.

How the encryption usually behaves

InnoDB .ibd files are large, so most ransomware does not encrypt the whole file. Instead it encrypts a fixed-size head (frequently the first 150 KB to 1 MB) and sometimes adds a small encrypted footer. Pages past the encrypted head are typically intact on disk, which is why partial recovery from .ibd is realistic when:

• Storage was not wiped or zero-filled after encryption.
• The system was not reinstalled on top of the original volume.
• The MySQL server has been stopped (no further writes that could overwrite freed pages).

Immediate steps before any recovery attempt

1. Stop the MySQL or MariaDB service so nothing else writes to the datadir.
2. Take a forensic copy of the entire data directory and any binary logs to read-only media. Work only on the copy.
3. Preserve ibdata1, ib_logfile*, every .ibd, every .frm or .sdi, plus auto.cnf and the server's my.cnf.
4. Record the exact MySQL or MariaDB version, the value of innodb_file_per_table, and whether the instance used encryption-at-rest, transparent compression or partitioned tables.
5. Do not pay the ransom to test the decryptor on the only copy. Test on a duplicate.

Recovering data from encrypted .ibd files

DBRECOVER for MySQL can scan an .ibd file as a stream of pages, skip the encrypted head, and reassemble rows from the surviving pages by walking the InnoDB B-tree. The general flow is:

1. Rename the encrypted file back to its original tablename.ibd name (strip the .id[...].Devos suffix on the working copy).
2. Open DBRECOVER for MySQL and load the .ibd in single-file mode, providing the table's schema (CREATE TABLE) when it is available; if the .frm or .sdi is destroyed, you can recover the structure from ibdata1 or from a backup of information_schema.
3. Allow DBRECOVER to scan all pages, including those past the encrypted head, and review the row preview.
4. Export rows to SQL or CSV and re-import them into a clean MySQL instance.

For MyISAM (.MYD/.MYI) tables, the same idea applies: skip the encrypted head, walk the data file, and reconstruct rows using the original column definitions.

What to send when asking for help

• A small encrypted .ibd sample plus its original schema, if you have it.
• The MySQL or MariaDB version and the innodb_page_size value.
• A short note describing whether ibdata1 and ib_logfile* are also encrypted.
• The naming pattern of the ransom suffix (it helps identify the variant).

If you encounter this scenario, contact DBRECOVER MySQL support at [email protected]. We routinely extract rows from encrypted MySQL .ibd, .frm, and .MYD files and can advise on whether a particular variant is recoverable before any paid engagement.

DBRECOVER Recovery Options

For Oracle incidents, start with the DBRECOVER for Oracle trial to verify table visibility, row previews, and export readiness on copied datafiles. For MySQL and InnoDB incidents, DBRECOVER for MySQL is free software and can inspect.ibd files, ibdata1, and database directories locally.

When the case is urgent, preserve the original files first, work from copies, and contact paid emergency support with the database version, platform, error messages, file list, and recovery objective.