How to Recover an MSSQL Database After a Ransomware Attack

When ransomware hits a Windows server, Microsoft SQL Server (MSSQL) is usually its main target: the .mdf, .ndf and .ldf files and every .bak backup the attacker can reach get encrypted and renamed. The ransom note says the data is lost unless you pay. Very often it is not. Large database files are almost always only partly encrypted, because encrypting 50 or 500 GB end to end takes too long for the attacker.

We have recovered many MSSQL databases after ransomware this way, without the attacker's key. In one case, a 27 GB SQL Server 2008 R2 database encrypted by the .M142HIMARS ransomware gave back 96 million rows from 222 tables. In others, 98.8% of the rows were recovered from LockBit-encrypted SQL Server backups. This guide explains the steps in the order that keeps the most data recoverable.

Stop the SQL Server service on the affected server so nothing else writes to the files, and disconnect the server from the network. Do not delete or rename the encrypted .mdf, .ndf, .ldf or .bak files, even if they look useless: they are the raw material for recovery.

Do not run DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, do not try to attach the encrypted files again and again, do not reinstall Windows or SQL Server, and do not run decryptors downloaded from unknown sites against the only copy. Each of these can destroy data that is still recoverable today.

Copy every encrypted database and backup file to a separate disk before anything else is tried: the MDF and NDF data files, the LDF transaction log, and all .bak, .trn and .dif backups, together with the ransom note and one or two other encrypted files. Work only on the copies from now on. If the server is a virtual machine, a copy of the whole VMDK or VHDX disk is even better.

Check everywhere a copy of the database might exist: SQL Server backups on another disk, a NAS or USB drive, Veeam or other backup software, cloud storage, an Always On or log-shipping secondary, a reporting copy, or an old copy a developer or the software vendor kept. Shadow copies are usually deleted by the ransomware, but check anyway.

If you find a .bak file that is not encrypted, test it before relying on it: RESTORE VERIFYONLY and then a restore to a different server or a new database name, never over the original. A backup that restores cleanly is the fastest way back.

If no clean backup exists, the next question is not which ransomware it was but how much of each file was encrypted. Many families encrypt only the start of a file, or blocks at intervals: in one measured LockBit 3.0 case, only 3.76% of a 1.1 GB file was encrypted. In the .M142HIMARS case, every other 8 KB page was encrypted only in the first and last 2.5 MB of the MDF; everything in between was intact.

An SQL Server data file is made of 8 KB pages, each with its own header. That structure is what makes recovery possible: every page that the ransomware did not touch can be read and checked on its own, even when SQL Server refuses to attach the file. You can measure this yourself with the free edition of AS Ransomware Analysis Studio, or send us a sample and we do it for you.

When the files are partly encrypted, the database is rebuilt from the pages that survived: the system tables are reconstructed so the table definitions are known again, then the rows of each table are read from its intact data pages and written into a new, clean database. The same works for an encrypted .bak file, which contains the same pages inside.

AS SQL Recovery & Repair Studio does this on your own PC: the free edition shows the damage map and previews the recoverable tables and rows, so you know what can come back before you buy anything. For large or difficult cases, we do the recovery in our lab.

Attach the recovered database to a clean SQL Server instance, run DBCC CHECKDB, compare row counts with what the application expects, and let the users who know the data check recent records, invoices or transactions. Only then point the application at it. Rebuild the server itself from clean media, because the attacker's way in is usually still open on the old one.

In India, CERT-In's directions require ransomware incidents to be reported within six hours of noticing them, and the Digital Personal Data Protection Act applies if personal data is affected. Other countries have their own rules. This is general information, not legal advice.

That is your decision, but find out what can be recovered without paying first. Paying does not guarantee a working decryptor, and decryptors supplied by attackers often fail on large database files. In many MSSQL cases, most of the data can be recovered from the encrypted files themselves.