The past two weeks have been insane thanks to CryptoWall and the many variants that are out in the wild. It started early Monday morning with a UK office, hit the US West coast mid-week and then finally came calling to the US East coast by weeks end. All told we had to restore some 250,000+ files on multiple Windows File Shares from either Shadow Copies or from backups. The bigger issue for us are the Windows File Shares from which the infected clients have mapped drives. So I’ve spent the past 2 days researching CryptoWall and trying to figure out how we can stem the tied and help right the ship. The current solution of re-imaging infected devices and restoring files just isn’t sustainable – we just don’t have the personnel to be playing wackamole every day of the week. So what should we be doing as an enterprise to combat this threat? It turns out you’ll need to really step up your game for this one.

Windows Software Updates and Patches – I’m hopeful this goes without saying but you never know

Java Updates – I would highly recommend you remove Java unless you absolutely need it

Adobe Reader Updates – I’m not sure if Adobe Reader is still the target is used to be but I keep it up-to-date regardless

Anti-Virus Updates – very important to keep your anti-virus up to date and functional

In my specific case we’re currently using Trend Micro as our anti-virus solution but I don’t believe many of the AV solutions are fairing well in protecting their clients due to the obfuscation.

You could be batting .400 with everything on the punch list above and still end up with CryptoWall / CryptoLocker or some variant infecting your laptop or desktop.

It turns out that you can use the Software Restriction Policies in Windows to block executables from running outside of the normal C:\Program Files\ or C:\Program Files(x86)\ folders, this helps prevent the actual launch and installation of the ransomware and/or malware. The malware will still be downloaded by the Flash, Java or Javascript code/exploit but it won’t be allowed to execute from the %AppData%, %AppLocalData%, %TEMP%, %UserProfile%, etc. There are varying discussions regarding a whitelist or blacklist approach. The National Security Agency even put out a configuration document back in 2010 covering the topic. I will stress that you really need to test thoroughly before deploying SRP across your enterprise network.

I’ll be firing up a Group Policy configuration to test Software Restriction Policies in my environment over the next week or so. I’ll probably need to-do some live testing by intentionally infecting a machine or two in order to validate that it actually works.

What are you doing to combat the threat? How are you making out? I’d love to hear, it might help save my sanity.