Paying a malware ransom is bad, but telling people never to do it is unhelpful advice

Posted by   Martijn Grooten on   Apr 26, 2016

I'm not usually one to spread panic about security issues, but in the case of the current ransomware plague, I believe that at the very least a sense of great concern is justified. And the threat is unlikely to disappear any time soon.

While there are certainly many things we can do to significantly reduce the risk of us getting infected — from applying all necessary patches and keeping offline backups, to running software that alerts us when files are suddenly being modified en masse — ultimately, ransomware does what we all should be doing: encrypting our files. The subtle but essential difference is that it does so with a key we don't have.

One reason why ransomware is so successful is that the ransom demanded is usually only a few hundred dollars — affordable to most people (ransomware tends to target users in Western countries) and often cheaper than the (perceived) value of the data that would otherwise be lost. However, security experts regularly tell affected individuals and organizations never to pay the ransom.

I think this is unhelpful advice.

For sure, paying the ransom should always be the last resort. We should help victims, and the jack-of-all-trades sysadmins who are likely going to assist them, find other ways to recover the data. Maybe backups have been kept. Maybe this particular ransomware is one for which a decryption tool is available. And maybe losing the data — which could also have happened because of a physical failure of the hard drive — is an expensive but valuable lesson on the importance of keeping backups.

But sometimes, none of this helps and the only sensible business decision left is to pay the criminals, much as it is bad and much as there is never a 100% guarantee that this will work. Crooks will be crooks, after all.

Of course, if everyone followed the advice never to pay a ransom, ransomware authors would come to find that it wasn't worth their effort, and the threat would eventually disappear. But this wouldn't happen instantly, and it really would depend on almost everyone not paying the ransom.

And if security experts suddenly had the power to make everyone follow their advice, maybe we should just tell people to patch instead.

locky_16mar.png

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2018 paper: From Hacking Team to hacked team to…?

Today we publish the VB2018 paper and video by ESET researcher Filip Kafka, who looked at the new malware by Hacking Team, after the company had recovered from the 2015 breach.

The spam that is hardest to block is often the most damaging

We see a lot of spam in the VBSpam test lab, and we also see how well such emails are being blocked by email security products. Worryingly, it is often the emails with a malicious attachment or a phishing link that are most likely to be missed.

Throwback Thursday: We're all doomed

Mydoom turns 15 this month, and is still being seen in email attachments. This Throwback Thursday we look back to March 2004, when Gabor Szappanos tracked the rise of W32/Mydoom.

VB2019 call for papers - now open!

Have you analysed a new online threat? Do you know a new way to defend against such threats? Are you tasked with securing systems and fending off attacks? The call for papers for VB2019 is now open and we want to hear from you!

VB2018 paper: Unpacking the packed unpacker: reversing an Android anti-analysis library

Today, we publish a VB2018 paper by Google researcher Maddie Stone in which she looks at one of the most interesting anti-analysis native libraries in the Android ecosystem. We also release the recording of Maddie's presentation.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.