Data held hostage; backups to the rescue
As it turns out, I was both right and wrong. I encountered ransomware again, this time on my company's network, and this time it did some damage.
Last week, one of my company's employees was hit with CryptoWall ransomware in the office. Just as I expected, my state-of-the-art SIEM and its intrusion-detection data sources detected the infection right away. My team got the alert at 9:05 a.m. and dropped everything to respond to the alert. They sprang into action immediately, just as I've drilled them to do. They knocked the infected workstation off the network and shut down the infected computer by 9:10.
But this ransomware did not fail. In the less than 5 minutes it was active, it did a lot of damage.
First, the ransomware encrypted files in the personal folders on the computer. This was no big deal, because the employee didn't have any important files stored locally -- which I was pleased to discover, because I make a point of telling everyone to save their important files on our network, where they are backed up and access-controlled, instead of on their computers. But what the ransomware did next was a lot worse.
The ransomware crawled through all the network drives mapped to the victim's computers, in alphabetical order, and encrypted all the files he had access to -- which was a lot. Over 10,000 files in all were encrypted, affecting over half the company. For each file that it encrypted, the ransomware left behind a text file containing instructions on how to decrypt the files -- namely, by installing a TOR (anonymous network) browser, visiting a particular URL, purchasing Bitcoins, and using them to make a payment to the hostage-takers. While I was reading these instructions, my phone was ringing off the hook with various employees demanding to know why their important business files were not opening.
Fortunately, we did not have to do any of that. We simply restored the original files from backup. We also used a downloadable decrypter made publicly available by a well-known antivirus company to unlock the few files that were more recent than the last backup. That whole process took about two hours.
How did this happen After discussion with the affected employee, I learned that he was just looking at the day's news on a major news agency's website, and had not done anything to trigger the ransomware infection, just as has happened in the past. He received neither a notification nor a request for confirmation of the malware's installation. In fact, the only people who knew about the infection were on my team. Without our network monitoring, there would have been zero knowledge of the ransomware until somebody discovered the encrypted files.
What concerns me most about this incident is the speed at which this malware infection deployed itself and did its damage. My team responded as fast as humanly possible, yet the ransomware got in and out of our network storage before they could stop it. This tells me that none of us can expect to be able to stop, or even contain, the damage caused by malicious code while it is active. And knowing that malicious code comes from well-known websites and enters my network without any user intervention, I now realize I can't prevent all malware infections. I just have to be ready for the next one -- and be prepared to do damage control.
This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.
Join in
Click here for more security articles.