“That’s criminal!” said my wife when I told her about Cryptolocker. Actually, all malware is criminal (Computer Misuse Act 1990, for the legal eagles), but Cryptolocker is particularly nasty, and currently running rampant. In case you haven’t heard of it, it’s malware which once running on your PC sets about encrypting your files; to get them back you’re asked to pay a ransom in Bitcoin.
The problem is worse when you’re connected to a corporate network, because the malware works to encrypt every file it can get to. You can imagine the potential for harm.
Naturally, the first thing you can do is restore from backup, after cleaning the malware from your machine. But that means you lose all your work since your last backup. You do backup, right? And confirm that the backups can be restored? Good. I’ll understand if you stop reading now and run off to check…
The second thing you can (should) do is make sure that no-one on your network has more access rights than they need. This is a core security control called the principle of least privilege, and problems like Cryptolocker are one of the reasons people like me repeat it so often. Giving everybody write access to everything they need read access to is easy – and lazy, and dangerous. Giving everybody full control of everything is completely irresponsible, and surprisingly common. Concerned? Go to the root folder of your network share, right-click, properties, security. Don’t like what you see? Stop reading and fix it.
The answers are less straightforward from here on.
Third? Make it easier to tell if someone has been infected. There’s a number of ways to do this, including using an intrusion detection tool to monitor for unexpected file changes; scanning for the .png file the malware drops containing the ransom instructions; using process monitoring to identify unexpected new processes on PCs (this is fairly tough to do in practice, although it can be helpful on Citrix or RDS servers); monitoring network activity for unexpectedly high SMB traffic from a single workstation. One trick is to make sure you have a honeypot directory – the first one a directory traverse will find – containing a file that you monitor for changes. Give everyone access to it, but make sure they know not to touch it. If it’s updated – by being encrypted – sound the alarm and cut off network access.
The fourth, and best, is to avoid getting infected in the first place. Not as easy as it sounds. Cryptolocker attacks use clever software techniques to make sure each piece of malware is unique, which defeats virus scanners. They’re usually delivered as attachments to apparently innocuous emails sent from compromised machines not on any block list, so they often penetrate anti-spam filters too.
Three steps to part four:
- Security Awareness Training. Here I go again – wetware trumps software. Teach your users to be careful of opening attachments, especially from unexpected sources. Teach them to be diligent about checking dialogs before saying OK, and make it clear that if they authorise execution of an unsigned macro, they will be at fault for the resulting infection.
- Desktop controls. If you can, without making your business stop functioning, disable user authorisation of unsigned macros and executables. Install an ad-blocker in the user’s browser – some Cryptolockers are drive-by payloads from compromised ads. Use group policy to prevent execution of programs in temp folders. If you can, implement comprehensive process whitelisting; another colossal pain, but effective – and again easier on Citrix and RDS boxes. Crank up local desktop security – not just no local admin rights for users, but as many restrictions on installation and execution as you can get away with.
- Network controls. Use Websense or a similar proxy filter to control user browsing; keep them away from potentially damaging websites – this isn’t easy, or cheap, and needs constant diligence since all sorts of reputable sites have had their ad-server networks compromised. Crank up the filtering on your spam filter; consider blocking attachments from anyone not on the whitelist. This can be unworkable for many businesses, though. If your firewall supports it, prevent executable (and analogous installer) downloads; you can also do this on the desktop depending on whether you’re running a local software firewall, and on which one you’re using.
None of this is foolproof (or rather, clever hacker proof) but it will make you a harder target. Even if you do everything I’ve listed, you still need to monitor vigilantly, and make sure you have frequent and effective backups. Otherwise you’ll end up having to pay the ransom, which won’t look good on your expense report.
A bigger picture 