sqlskills-logo-2015-white.png

The Curious Case of… recovering from a ransomware attack

(The Curious Case of… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can sometimes be more frequent. It covers something interesting one of us encountered when working with a client, doing some testing, or were asked in a random question from the community.)

Several times a year, and most recently a couple of weeks ago, we are contacted by an unfortunate company that’s been the victim of a ransomware attack. In each case, either they negotiated and were given some decrypted database files, or went through a third-party specialist that decrypted some databases. Invariably, the encryption/decryption process did not preserve the database files as  they were before the attack and SQL Server won’t recognize them.

There are a variety of errors I’ve seen, including:

Msg 824, Level 24, State 6, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum. It occurred during a read of page (1:0) in databases. This is a severe error condition that threatens database integrity and must be corrected immediately.

(which is a corrupt file header page)

Msg 5028, Level 16, State 5, Line 1
The system could not activate enough of the database to rebuild the log.

(when trying to use emergency mode repair to build a new log)

Msg 8998, Level 16, State 2, Line 1
Page errors on the GAM, SGAM, or PFS pages prevent allocation integrity checks in database ID XX pages from (1:YY) to (1:YY+8087). See other errors for cause.
Msg 8921, Level 16, State 1, Line 1
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
(PFS page corruption, which cannot be repaired)
Plus things like large portions of the database files overwritten with garbage or zeroes, or the files are truncated. And of course, backups are not available or damaged.
Although the title of the post is about recovering from a ransomware attack, in 100% of the cases I’ve seen, there is no recovery. SQL Server itself can’t get past such problems, and without a prior backup to base manual recovery efforts on, it’s just not worth trying in my experience. I should say that in a small handful of cases, I’ve heard of a data-scraping tool like Stellar (which I’m not endorsing) being able to salvage a small amount of data, but those cases are rare.
Bottom line: a ransomware attack is a complete nightmare, and without secure, offsite backups, is likely to be very expensive or disastrous.

One thought on “The Curious Case of… recovering from a ransomware attack”

  1. Paul, I completely agree. In my consulting days it was 100% loss of data when it came to SQL Server. Always make sure you have backups, and that you test them regularly. A wise man once taught me that…

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.

Collaborate With Us
Choose a Course