A Cautionary Tale
From a security perspective, there are two types of business owners; those that have experienced a ransomware outbreak in their business, and those that haven’t. Conversations with either group are drastically different. People who’ve had the misfortune of being at the mercy of a ransomware virus will tell you how surprisingly disruptive it is to their business continuity. Even with up-to-date backups and a highly responsive IT staff/company, some downtime is unavoidable. Under less favorable conditions that downtime can extend to days and even weeks.
Can’t my data just be decrypted? There has to be a workaround.
If you were given two very large prime numbers it would be relatively easy to find the product of those numbers. However, if you were given a massive number and asked to find the two numbers that when multiplied together, equal the original…well that is a far more difficult task. One that even modern computers cannot solve efficiently. Encryption is impossible to shortcut.
How did this virus get in?
Most likely from one of two ways. Hands down, the majority of ransomware infections come from malicious attachments in emails. These emails are designed to encourage people to open them. A shipping manifest from FedEx, past-due invoice or resume are the most common examples of subterfuge. The other less common but potentially more damaging means of ingress is a weakness in your network’s perimeter that has been put in place to accommodate a third-party, usually a payment processor.
What follows is a dramatized version of events from a fictitious ransomware outbreak. While it may seem like saber rattling, the remediation of some outbreaks go better, but many go a lot worse.
Something isn’t right. Spreadsheets and documents refuse to open. Line-of-business applications give a vague error before quitting. A call is placed to IT support. A short while later they call back. It’s ransomware. All the files and folders on the server have been encrypted and there are instructions in a text document regarding how to properly contact the bad guys so that you can pay the ransom without their identity being revealed. Not to worry, there’s an external hard drive plugged into the server and all your data gets backed up there. Unfortunately, that’s been encrypted or deleted as well.
As difficult as it may be to come to terms with, the realization that the cheapest way to get back up and running is to pay the ransom and hope that the anonymous person on the other end of the line will provide the software necessary to decrypt. The TOR browser is downloaded and the journey on to the dark web begins. Once contact is made the negotiations begin. Originally the attacker wants $10,000 worth of Bitcoins, but eventually, $5,000 is agreed upon.
Most Bitcoin exchanges require account verification before large sums of Bitcoins can be purchased. This could take upwards of 72 hours. A lucky break was caught and a friend who invests in Bitcoin is willing to sell off $5,000 without any exchange fees tacked on. Contact is made again with the hackers, henceforth known as Ivan, and the Bitcoin is sent over.
A decrypter is received from Ivan and work begins on decrypting every file and folder on the server.
The decryption software continues to run but it appears to be skipping random files.
The decryption process has finished but there are still many encrypted files left over. The entire process is started over, hoping for better results this time. Meanwhile, every old external hard drive and thumb drive is scoured for usable data. Losing a year or two of data is better than losing it all.
No luck – the software is skipping files and folders wholesale. Attempts are made to reconnect with Ivan in hopes that he is both willing and able to help with this.
Ivan responds. The news isn’t good. He thinks the software detected that the files were attempted to be decrypted without paying the ransom and has purposely sabotaged the data. In a last ditch effort he provides another decryption tool. This one seems to be working better than the last one but still skips files randomly. Nothing to do but wait and hope.
The second decrypter has conked out. Back to the dark web to reach out to Ivan again. Miraculously he is still responding. He does have a reputation to maintain after all. He takes a deeper dive through his records and realizes that the virus spread through the network so quickly that different ones were competing to encrypt files. The significance of this is that each one requires a different decryption key. So far he’s handed over two. Turns out you need twenty-two more. The good news is this will probably work. The bad news is each decrypter takes twelve or more hours to run and the server can only handle a few running concurrently.
IT worked through the night targeting mission critical data with the twenty four decrypters. After four days of downtime business resumes, albeit at a reduced capacity. Some critical data was not recovered. Even though it was decrypted, the process has corrupted it beyond repair.
Monday Morning – Week Two
Business is back to full capacity. Although attempts were made over the weekend, some data will never be recovered. Hopefully what was lost is not bound by any form of compliance or retention laws.
How to avoid being in this situation in the first place
The first key ingredient is some form of encrypted off-site backup. Every business should have a current copy of their data somewhere in the cloud. In the above scenario, the business owner would have thumbed their nose at the ransom demands while his backups were being restored. The business would have been back up and running Tuesday morning at full capacity with no data loss.
The second piece of the puzzle is to force third-party vendors to be more secure when connecting to your network. This often means the use of a secure, encrypted, VPN connection. Some companies agree without issue while others try to push back because adding extra steps adds time. If a vendor refuses, try to replace them. This might seem like a drastic step, but the alternative could be a week or more of downtime and data loss.