People like to ask the security manager, "What keeps you up at night?" My usual answer: "Employees." And there's good reason. About 95% of the security incidents my department responds to are a result of an employee doing the wrong thing, whether it's clicking on an evil link within an email, installing a malicious program or sending a sensitive document outside the company.
At issue: An employee's files are all encrypted after she clicks on a ransomware link.
Action plan: Get the files back, make sure no one else fell victim, and find out how that ever got through the email filters.
Sometimes when they do the wrong thing, you can't really blame them. And sometimes you get evidence that employees are really paying attention when you tell them not to do things that are likely to lead to trouble. We just had a ransomware situation (which didn't turn out too badly in the end), and I have to admit that how it arose was quite understandable, a case of one person trying to streamline aspects of his job that don't really require his attention and another person trusting that first person. Here's what happened.
A director in the sales organization gets a lot of emails that contain faxes (or links to faxes held by a third-party fax service) from customers. The faxes might be purchase orders, contracts or other business-related documents. This sales director isn't directly responsible for any of those things, so he simply passes the emails on to the people who are. At some point, though, he grew tired of all that forwarding, so he started auto-forwarding all emails containing the word "fax" in the subject line to predefined distribution lists. And that was working out just fine -- until last week.
That was when a sales associate on the sales director's auto-forward distribution list received an email from him containing a Dropbox link. Since the email was forwarded to her by someone she knew, she figured that it was legitimate and clicked on the link, expecting it to take her to a fax document. Instead, there was a slight pause, followed by a noticeable performance problem with her PC. Then a box popped up explaining that all the files on her hard drive had been encrypted and that in order to regain access, she would need to install a program that would allow her to pay a fee to unlock the files. Of course, it was too late by the time she called the help desk and got security involved.
Fortunately, she had kept a copy of the files on her computer synchronized with a network file share, which was not affected by this event. We decided to wipe her computer and restore her files from the network file share. No ransom payment necessary.
Meanwhile, we checked with the other people on the sales director's distribution list to make sure that no one else had fallen victim to the ransomware scam. We also searched our email archive for emails containing keywords consistent with this particular attack. As a result, we found about 25 users who had received emails with that bad Dropbox link. Only a few of them had opened the email, and none of them had clicked on the link. How to explain that delightful outcome? They all remembered what they had been taught during security awareness training!
Another pleasant surprise a short time later was that Dropbox removed the troublesome link.
But we were still confronted with a troubling question: How had this email made it through our spam-filtering protections? Apparently the email team had disabled the Sender Policy Framework setting, which validates that incoming email originates from authorized domains. For example, if an email is purported to originate from computerworld.com but the email header contains an originating domain that is not authorized by computerworld.com as a valid domain, the email would be blocked. The email team had disabled this feature in order to troubleshoot a serious mail delivery problem. Needless to say, that feature was quickly reactivated.
We've also sent an inquiry to our antivirus vendor asking why this ransomware wasn't detected. I'm sure they're going to say it was due to it being a zero-day exploit, but we have to ask. I've also contacted the vendor of our advanced malware-detection tool to ask why it didn't detect and block this, since all downloaded files are supposed to be run in a sandbox, evaluated and then blocked if determined to be malware. They're all good questions to ask, I think, and I'll be interested in what the vendors have to say.
But we got lucky with this one.
No, that's wrong. Security awareness seems to have been our saving grace. It worked just the way it's supposed to.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at firstname.lastname@example.org.