Devos ransomware/malware encrypted Oracle database datafiles

An Oracle database has been encrypted by Devos ransomware. The datafiles in $ORACLE_BASE/oradata were renamed with a suffix similar to .id[XXXXXXXX-XXXX].[email].Devos, and Oracle can no longer open the database because the file headers are corrupted.

What is actually damaged

Devos and its siblings (Phobos, Eking, Makop, etc.) typically encrypt only the first few hundred kilobytes of each datafile. Because Oracle datafiles are usually multiple gigabytes, the bulk of the data blocks past the encrypted head are still intact on disk. That is what makes recovery possible: DBRECOVER for Oracle can read past the corrupted header, locate intact data blocks, and rebuild rows directly without needing the database to mount.

Recovery preconditions

• The Oracle service must be stopped before any recovery; otherwise the SGA may overwrite freed blocks on flush.
• The encrypted datafiles still need to be present and readable. Take a forensic copy first and work from the copy.
• If SYSTEM01.DBF is not encrypted, the data dictionary is intact and recovery can run in dictionary mode with object names preserved. If it is encrypted, you can still recover in non-dictionary (no-DICT) mode and reconstruct rows by table OBJ#, then map them back to logical schemas.

Recovery flow with DBRECOVER for Oracle

1. Make a working copy of every *.DBF.devos file. Strip the ransom suffix on the copies so each file is named with its original .DBF extension.
2. Launch DBRECOVER for Oracle in dictionary mode. Add SYSTEM01.DBF first with TS#=0, RFILE#=1.
3. If the SYSTEM tablespace itself is partially encrypted, enable SCAN BASE TABLES. DBRECOVER will scan the surviving blocks in SYSTEM01.DBF and recover rows from TS$ and FILE$, which give you the mapping of every datafile to its tablespace.
4. Use the recovered TS$ and FILE$ rows to fill in the correct TS# / RFILE# for each remaining datafile.
5. Load the user data tablespace files (skip TEMP, UNDOTBS, and SYSAUX — they have no recoverable user data).
6. Browse the recovered objects, preview rows to confirm the encoding and column types, and export to flat files or directly to a clean Oracle instance.

When the SYSTEM tablespace is unrecoverable

If SYSTEM01.DBF cannot be read at all, run DBRECOVER in non-dictionary mode. The tool scans every datafile, identifies row pieces by block format, and groups them by data object id. You will recover columns by ordinal (COL01, COL02, …) and need to relabel them using application metadata or a recent SQL CREATE TABLE backup.

For an end-to-end demonstration, see the reference video: https://youtu.be/jOT6k-KF8Hg. For paid emergency recovery, contact [email protected] with the database version, platform, the ransom suffix, and a short list of the affected files.

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.