Ransomware-Encrypted SQL Server Database Recovery: MDF and BAK Files

When ransomware hits a SQL Server, the instinct is to assume the database is gone unless you pay for a key or restore a backup. Often neither is true. Large database files are frequently only partially encrypted, and where that is the case, a significant amount of data can be recovered directly from the file — without the attacker's key, and without a usable backup. Whether that is possible in a given case depends on how the specific ransomware behaved and which parts of the file it touched.

Encrypting a multi-terabyte file completely is slow, and speed is what ransomware operators optimise for — the faster they finish, the less chance of being interrupted. To get around this, many modern families use intermittent or partial encryption: they encrypt the start of a file and then only periodic chunks, or just the header region, leaving large stretches of the original data untouched. For a small document this still destroys the file. For a 1.4 TB SQL Server MDF, it can leave the majority of the data pages intact and readable.

A SQL Server database is organised into 8 KB pages. Each page carries a header describing what it holds, and table rows live inside data pages that are indexed by the database's internal system structures. Because the data is spread across millions of these pages, encryption that hits only the start of the file or scattered regions leaves most pages structurally intact.

Recovery works by reading those surviving pages directly — identifying which table each page belongs to from its header, and reassembling rows from the raw page data — rather than relying on the database to open normally, which it will not.

Two things decide how much comes back: which regions the ransomware encrypted, and how completely. If the encrypted area lands on critical structures — the boot page, the system catalog that maps internal IDs to table names, or the allocation maps — those have to be rebuilt or inferred before the surviving data pages can be put back into named tables.

If the family used full encryption rather than partial, or the file is small enough that 'partial' still covers all of it, there may be little or nothing to recover without the key. This is why the same ransomware can produce very different outcomes on a 2 GB database and a 2 TB one.

It is worth being clear about what this is. Recovering data from the unencrypted remainder of a file is not the same as decrypting it — the encrypted pages stay encrypted and unreadable. What is being recovered is the data the ransomware never reached, reconstructed into usable tables. For large production databases that is often most of the data; for heavily or fully encrypted files it can be very little. No honest assessment can promise a figure before examining the actual file.

Preserve the encrypted files exactly as they are — do not delete them, and do not let anyone 'clean up' the server, because those encrypted MDF and LDF files are the raw material for recovery. Take the affected system offline to stop further spread, but keep copies of the database files, the ransom note and any logs.

Before paying anything, have the files assessed. The encrypted file itself shows how the ransomware behaved and how much of the database survived, which is the only reliable way to know whether recovery without the key is realistic.

A company's SQL Server 2019 ERP database backups (.bak, 10.5 GB) were encrypted by LockBit and renamed with a random extension. The backup header was destroyed, so SQL Server could not restore them, and the backup from the next day did not help: LockBit had encrypted the same places in both files.

AS SQL Recovery & Repair Studio opened the encrypted backup directly, found every surviving 8 KB page image by its checksum, and rebuilt the tables. The system catalog was partly lost, so a sister company's database with the same structure was used as the reference for table and column definitions (never for data). Result: 354 tables and 4,703,039 of 4,759,135 rows (98.8%), with no table mislabelled. The client also still had a healthy copy of the database, so every recovered row could be checked against it.

The Gentlemen ransomware has a fast mode for large files. On a 171 GB SQL Server backup we measured it encrypting three long stretches, at the start, in the middle and at the end, about 9% of the file in total; the other 91% was plain. Our 9.8 TB case was the same family: seven production databases of 1.4 TB each, all recovered from the encrypted files and repaired to a working state.

Some ransomware encrypts only the beginning of each file. On a 188 GB SQL Server MDF we measured exactly the first 256 KB encrypted, plus a 204-byte block added at the end. SQL Server refused the database because the boot page and the start of the system catalog were gone, yet more than 99.9% of the pages were untouched. In cases like this the tables are read directly from the surviving pages, and the header can be rebuilt so that SQL Server attaches the database again.

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

A 27.3 GB SQL Server 2008 R2 database had been encrypted and renamed with the .M142HIMARS extension. The ransomware had encrypted every other 8 KB page in the first and last 2.5 MB of the file and appended a 1,544-byte block — a small part of the file, but the part holding the boot page, the allocation maps and the start of the system catalog, so SQL Server refused to attach it.

Working from the file directly, 96.0 million rows were recovered from 222 tables, with no row failing its checks. 179 tables were complete, their row counts exactly matching the database's own catalog; partial tables missed only the rows on encrypted pages. A 2018 copy of the same database supplied the structure (never the data) for 10 tables whose definitions had been lost. About 20 small tables could not be linked automatically.