Oracle Database Ransomware Recovery: Datafiles and DMP Exports

When ransomware encrypts an Oracle database, the instinct — as with SQL Server — is to assume it is gone without the key or a clean backup. Often it is not. Oracle datafiles are usually large, and large files are exactly what ransomware tends to encrypt only partially. Whether recovery is possible comes down to which files and regions were hit, not simply to the fact that the database is encrypted.

An Oracle database is made of datafiles (commonly .dbf), organised into blocks — much like SQL Server's pages — grouped into extents and segments within tablespaces. Alongside them sit control files and redo logs, and many environments also keep Data Pump exports (.dmp) as a logical dump of the data. These files are typically large, and when ransomware uses intermittent or partial encryption for speed, big datafiles keep long stretches of their original blocks intact.

Where enough of a datafile survives, recovery reads the intact Oracle blocks directly — identifying the table and column structure from the block contents and reassembling rows — rather than trying to open the database, which will not mount with damaged files. A partially encrypted Data Pump .dmp can be worked the same way: it is a structured stream, so surviving portions can still yield tables and rows even when the start of the file is gone.

Two factors: which files were encrypted, and how completely. Oracle's data dictionary lives in the SYSTEM tablespace and maps internal object IDs to real table and column names; if the encrypted region covers the SYSTEM datafiles or the segment headers, surviving data blocks have to be reassembled without that map, which is harder and slower.

A large application datafile encrypted in a sparse pattern can come back almost whole; a small database, or one where full encryption was used, can yield little without the key. This is why the same attack produces very different results on a 50 GB database and a 2 TB one.

An ERP system's Oracle Data Pump export (.dmp, 354 GB) had been renamed by ransomware with a .ftagic007 extension, and impdp refused it. Measured directly, only the first 128 MB of the file and a 96-byte block at its end were damaged; the rest was plain.

In a Data Pump export every table is stored as its own stream with a self-describing header, and the export's own catalogue sits at the end. AS Oracle Recovery Studio searched the file for those headers and found 8,132 table streams, exactly the 8,132 tables listed in the catalogue. Only one table had lost its header in the destroyed region; its rows are offered with column types worked out from the data. Every other table came back with its name, columns and rows.

A healthcare technology company's SAP system on Oracle was hit by Akira, which encrypted the production database: its datafiles and its Data Pump export, about 2.5 TB in total. We worked directly from the encrypted Oracle files and recovered and repaired the database back to a consistent, working state.

Before relying on a method in a real case, we test it on an Oracle database whose contents we know exactly. On copies of our test datafiles with the start encrypted, all 30 test tables were read back identical to what Oracle itself returns; on copies with encrypted stripes through the file, every row on the encrypted blocks was reported as lost and not a single wrong row was produced. A Data Pump export with its head destroyed gave back 27 of 28 tables exactly and the surviving rows of the 28th.

What matters is how a family encrypts a datafile or an export, not its name, and that is measured on the file itself. Our guides to individual families:

The encrypted regions stay unreadable — this is not decryption. What is recovered is the data the ransomware did not reach, rebuilt into usable tables and exports. For a large production database that is often most of the data; for a small or heavily encrypted one it can be very little. Only examining the actual datafiles and exports can tell which.

Preserve everything exactly as it is — the datafiles, control files, redo logs and any .dmp exports are all raw material for recovery, and 'cleaning up' the server can destroy the only workable copy. Do not run RMAN recovery or try to force the database open on the damaged files.

Check for anything untouched: an RMAN backup, a Data Guard standby, or an older export on separate storage is always the fastest route back. If nothing clean survives, have the encrypted files assessed before paying or deciding anything.