Addressing the backup dilemma to ransomware recovery

Ransomware attacks are starting to present IT environments with two very unappealing options: perform a single full recovery that actually loses a lot of data, or perform hundreds to thousands of individual restores to return your environment to something resembling normalcy. The reason for these two unfortunate choices is that ransomware now changes how it behaves once it infects your environment. This presents a particular challenge when trying to restore your data.

A typical ransomware attack consists of four phases: infection, expansion, encryption and detection. The infection phase is easy enough to understand; it is the moment when the first computer in your environment becomes infected with ransomware. This typically happens because someone clicked on an email they shouldn’t have opened or went to a website they shouldn’t have used. The initial piece of malware is deployed on the computer in question and it reaches out to its command-and-control (C&C/C2) servers to be told what to do.

Historically, these servers would direct the malware to immediately begin the encryption phase. The malware would begin encrypting as many files as possible, especially recently modified files and important system files. The goal was to damage the system as quickly as possible and then send out a ransom message while the malware continued to encrypt other data.

However, many modern ransomware variants have switched tactics to prioritise expansion over encryption. Once one computer in your environment has been infected, it will most likely be told to prioritise infecting other systems before encrypting files that would cause the malware to be discovered. It will use a variety of techniques to try to infect other systems, such as using common tools such as the Remote Desktop Protocol (RDP), network file system (NFS) or server message block (SMB). It might even begin targeting specific systems, such as backup servers. If it can infect the backup server and cripple it, the chances of paying the ransom goes up exponentially.

While the ransomware continues to attempt infecting the rest of the datacentre, it may also begin encrypting files that no one will notice. It might encrypt older files, because the chances of someone accessing them are relatively low. Just like the expansion phase, the encryption phase now wants to prioritise encrypting as many files as possible before anyone realises they have been infected.

What’s important to understand about how ransomware behaves is that the two phases of expansion and encryption are occurring simultaneously and can take several weeks to happen. If the ransomware goes undetected, it could be doing these activities for months. A recent study from FireEye Mandiant showed that the median dwell time of a typical ransomware attack is now 24 days. During that entire time, the malware strain could be encrypting files on multiple computers over many days.

One common behaviour across almost all backup and recovery products is that restores are done from a single point in time. If you can only restore a directory to a single point in time, how do you restore hundreds of files that were modified in many directories over many weeks? In addition, remember that you need to restore the server to a point in time before it was infected to bid farewell to the ransomware.

After making sure you rid the computer of the malware itself, a typical restore from a ransomware attack would involve deleting all encrypted files – potentially all files in a given directory or file system. Then you restore everything back to before the attack. You don’t want to restore encrypted files (or the malware), so you need to restore the directory or file system to the point in time just before the ransomware attack began.

Here’s where you are presented with the dilemma. Do you leave the directory in question looking the way it did before the infection (throwing away any work since then), or do you try to identify all of the files that were encrypted after the infection, and restore each of them to the point in time just before they were encrypted? Think about how difficult it would be to do that across hundreds of directories and subdirectories and many days or weeks of time.

This is going to be a moment of reckoning for many data protection products as they figure out how to solve this challenge. Asking a customer to perform hundreds of restores to get their directory back to normal is only going to increase their incentive to pay the ransom. Everyone agrees that paying the ransom only validates criminal activity and feeds a continuous cycle, so this issue must get addressed.

During Cybersecurity Awareness Month, there is no better time to reach out to your favourite backup product supplier and ask them how they would address this issue. Even if their answer is, “we have no idea”, it’s better to know now then discover this problem in the middle of an attack.

W Curtis Preston is chief technical evangelist at Druva