DBRECOVER For Oracle Recovery Scenario: Ransomware malware encrypts and damages data files

Ransomware malware encrypts part or all of the content of ORACLE data files. As ORACLE data files are generally large, encrypting the entire file may take a long time, so some ransomware malware may choose to encrypt only continuous or random space in the header of the ORACLE data file.

For this kind of local encryption damage, we can try to use DBRECOVER to recover the data in it.

Since the data file header is damaged, we need to figure out the tablespace number (TS#) and relative file number (RFILE#) of each data file by observing the contents of SYSTEM01.DBF.

Below is a list of data files:

O1_MF_APP01_L782YY4Y_.DBF.eking

O1_MF_APP01_L782ZBM3_.DBF.eking

O1_MF_APP01_L782ZCP1_.DBF.eking

O1_MF_APP02_L782ZO7W_.DBF.eking

O1_MF_APP02_L7830DTG_.DBF.eking

O1_MF_APP02_L7830FJ6_.DBF.eking

O1_MF_DBRECOVE_L6G7B1Q3_.DBF.eking

O1_MF_SYSAUX_L5VP5QJ8_.DBF.eking

O1_MF_SYSTEM_L5VP4N7Y_.DBF.eking

O1_MF_TEMP_L5VPCQGO_.TMP.eking

O1_MF_UNDOTBS1_L5VP66PM_.DBF.eking

O1_MF_USERS_L5VP67TJ_.DBF.eking

The example above has the encrypted suffix eking.

Note that TEMP, UNDOTBS1, and SYSAUX are irrelevant to our recovery job, so you can ignore these files.

We first launch DBRECOVER, using dictionary mode DICT-MODE.

Choose the DB VERSION according to the actual situation. For instances higher than version 12c, such as 18c, 19c, etc., choose 12.

Only add SYSTEM01.DBF and specify its TS# = 0 rFILE# = 1 (note this is fixed).

Checking the "SCAN BASE TABLES" option above can more powerfully deal with damage situations.

After clicking the LOAD button, DBRECOVER will scan SYSTEM01.DBF as a whole and find the data dictionary base table data in it.

We open the SYS user node and look for the TS$ and FILE$ two basic tables:

The TS$ table stores tablespace information, the TS# column is the tablespace number, and we can get the following information:

That is, the TS# of the APP01 tablespace is 7, and the TS# of the APP02 tablespace is 8.

The FILE$ table stores data file information:

What we need are the TS# and RELFILE# columns.

By mapping and merging the data of the two tables, we can get:

After deleting the unnecessary SYSAUX, UNDOTBS1, and the known SYSTEM tablespace, only the following are left:

Corresponding data file name list:

O1_MF_APP01_L782YY4Y_.DBF.eking

O1_MF_APP01_L782ZBM3_.DBF.eking

O1_MF_APP01_L782ZCP1_.DBF.eking

O1_MF_APP02_L782ZO7W_.DBF.eking

O1_MF_APP02_L7830DTG_.DBF.eking

O1_MF_APP02_L7830FJ6_.DBF.eking

O1_MF_DBRECOVE_L6G7B1Q3_.DBF.eking

O1_MF_USERS_L5VP67TJ_.DBF.eking

By comparing the above two tables, it is not difficult to find the corresponding relationship. For data files managed by db_create_file_dest OMF file, multiple data files under a tablespace can be sorted by their file names, and the order is consistent with RELFILE#. For file names managed by users themselves (that is, without using OMF), they generally use the naming method of APP01{XX} (such as APP0101, APP0102) for easier management, and their corresponding relationship can also be obtained.

Above, we obtained a complete information table through guessing:

Reopen DBRECOVER and switch to dictionary mode:

You still need to select the database version (DB VERSION).

Add all necessary data files (all files that might store user data, UNDOTBS1, TEMP, SYSAUX don't need to be added), and make sure not to omit SYSTEM01.DBF (it must be added).

Fill in the TS# and RFILE# information according to the table you compiled earlier:

If the relevant information is correctly filled in and the degree of encryption damage isn't high, you can directly read the data:

Because the characteristics of encryption viruses vary, there may be more problems that need to be addressed in actual operation. Please feel free to communicate with us via email: service@parnassusdata.com.