Let’s be clear: there is no “easy” button when it comes to recovering from ransomware.
If you’ve already gone through the first two phases of your recovery plan, your company is lucky to have you on board, because you understand the effects (and the extent) of data loss in this situation. You’ve restored things, maybe not to the point where it’s as if the incident never even happened, but it’s as close as you could get. There is likely going to be some data loss, but maybe not. Again, it will depend on what happened. I get yelled at from the storage and backup folks when I say a rollback to snapshot is basically sanctioned data loss (because in most cases, you don’t know what you lost). A restore from backup could have the same effect and leave behind a bunch of “junk,” or perhaps toxic waste, that may, in fact, be harmful if consumed.
Here’s a recovery strategy that often works, but is not a cure-all:
- If you decide it’s best to pay the ransom and just want to move on, you aren’t done yet. I can’t say this isn’t a valid approach, but I also hate to reward the extortionists. You may still need to clean up the junk. You’ll need to identify any remnants of the attack that were left if the kidnappers released your data, and clean it up. Remember, the goal is to make the environment like the attack never even happened.
- If either paying the ransom didn’t release your data, or you have decided not pay, there are some options for getting the data back. By monitoring user activity and seeing what’s changed in live data and between snapshots, you can understand the extent of the changes and begin tackling them individually.
- If the damage was localized, say, to a single user and a small set of folders, the best approach might be to delete folks’ files and reduce any collateral damage. Then, restore those folks from the latest version you have. In many cases, the latest version is likely contained in a snapshot or backup, since most files were likely unchanged before the ransomware hit. Nominally, it’s important to know what you lost, otherwise every time something shows up “missing,” you’ll wonder if it was a side effect of the ransomware.
- If the damage is widespread, the amount of data that changed because of ransomware might be far greater than the data changed in the normal course of business during the affected period. In this case, your restore plan may be:
- Take a manual snapshot so you have a point of return if the restore didn’t work as expected.
- Pinpoint when the issue started happening.
- Get the list of files that were not affected by ransomware, and those that were modified after the ransomware incident was triggered. Export this to a CSV file; you’ll need it later. Export the list of affected files; you’ll need this later as well.
- Roll back or restore the last snapshot/backup that existed prior to the ransomware event.
- Create another manual snapshot. When this finishes processing, you’ll have the differences between what data is currently in your system and what was there after the ransomware attack. You’ll know exactly what you lost, and have the means to restore the lost files. Or you can also use the CSV with the file list of what needs to be restored, and use Robocopy or other tools to restore the files.
So to net things out for you, regardless of the approach or tools you use to recover from ransomware, it’s important to:
- Protect what’s left of your data by taking a read-only VMware or storage snapshot backup.
- Shut down culprits that were affected as soon as possible.
- Assess the damage.
- Engage your recovery plan, including how to clean up the collateral damage. If possible, capture what data has been lost/affected.
- Take another snapshot or backup before you attempt the recovery (especially if you are going to run a recovery script you bought from the kidnappers with bitcoin) in case something goes wrong during the recovery.
- Proceed with care and start the repair.
How would your team respond to a ransomware attack? Get a free data security assessment to find out.