A Wall Against Cryptowall? Some Tips for Preventing Ransomware

Published: 2016-03-09
Last Updated: 2016-03-09 13:09:50 UTC
by Rob VandenBrink (Version: 1)
15 comment(s)

A lot of attention has been paid lately to the Cryptowall / Ransomware "family" (as in crime family) of malware.  What I get asked a lot by clients is "how can I prepare / prevent an infection?"

"Prepare' is a good word in this case, it encompasses both prevention and setting up processes for dealing with the infection that will inevitably happen in spite of those preventative processes.  Plus it's the first step in the Preparation / Identification / Containment / Eradication / Restore Service / Lessons Learned Incident Handling process (see SANS SEC 504, or ask anyone with "GCIH" after their name)

My best advice is -  look at how the infection happens, and make this as difficult as possible for the attacker, the same as you would try to prevent any malware.  Most malware these days outsources the delivery mechanism - so Cryptowall is typically delivered by an exploit "kit".  These days, that typically means the Angler, Rig, or maybe Nuclear exploit kits (Angler being the most prevalent at the moment).  These kits aren't magic, they generally try to exploit old versions of Java, Flash, Silverlight or take advantage of missing  Windows updates.  When patches come out, the authors of these kits reverse the patches and bolt the exploits into their kit.  We've analyzed several versions of these kits over the last few years, most recently Manuel's post last week

So to help prevent these kits from working, we need to give them fewer toeholds in your environment - start by uninstalling these add-ons across the board:

If you can't uninstall them, be sure that you are patched up, and that as new patches and updates come out you have an AUTOMATED way of keeping them up to date.  But seriously, if you can, uninstall them.  Maybe you needed Java and Flash 5 years ago, my bet is that you don't need them now.  Any you likely never needed Silverlight. 

Keep your windows desktops and servers patched up.  Patch on Patch Tuesday already!!  Patch Tuesday was yesterday - have you patched yet?  Have your rebooted your patched servers yet so the patches are actually live?  Is there a really good reason why not?

Know what's on your network, and be sure it's all patched as patches and updates are released.  If you've got old gear that isn't being updated anymore, it's time to retire and replace those stations.
Know what software is running on each of your workstations, and be sure that's all patched or updated as updates come out.  
Hardware, OS and Software inventory is one of the basics - you need to automate this as much as possible, because not everything on the network always comes in through IT.  Think TV's, projectors, exersize equipment, thermostats and HVAC systems, door controls, fridges and teapots (yes teapots) - the list only starts there.  Everybody seems to be entitled to bolt things onto your network. 
Those "appliances" on your network aren't immune to malware, they're likely more susceptible because they don't get patched.  That 20 Ton press on your shop floor?  That IV pump?  They're both likely running a 10 year old OS (either XP or a Linux variant).  Even if you bought them last week they might be running an OS that old, even in the best case it'll be months or years behind in patches.
Uninstall any software that you don't need.  You can't infect what isn't there.
Be sure that folks aren't running as administrator on their workstations, and don't have access to that set of rights.

Is that it you ask?  Nope - cryptowall almost always comes in via email as SPAM.  If you don't have a decent anti-spam solution, it's time to get one!  If your firewall has the capability of running attachments in a sandbox (for instance, Palo Alto and Cisco both have this), it's time to crank this feature up.

Block attachments that will execute  (exe's, msi's, scr's, jar's, cmd, bat, etc)

Block zip files with passwords

What else should you have in place?
Using Group Policy, force your users to store their data on a network share rather than their local disk (redirect "my documents" etc).
Be sure that you have control of the ACLs on your server shares.  The days of "we trust our users" are long gone - you can't trust your users' malware, so if you don't have a "you have access to what you need and only that" policy, it's time.  Those "permit all" directories were all created in teh 1990's, and it's time to rethink them - "Read Only" is your friend!  There is very little data in your organization that everyone needs read/write access to, but that's what we so often see, and that's what things like Cryptowall takes advantage of.

Also using Group Policy, disable Macro's in Microsoft Office, and disable VBS while you're at it.  You can do this station by station, but the true win for a medium to large organization is using Group Policy to enforce a consistent set of rules across the board.  The Australian Cyber Security Center has a nice document that outlines possible settings, depending on how your organization's requirements.  Me, I'd say disable all of it.  As awesome as document automation is, running someone else's automation to destroy your data is the exact opposite of awesome!  If you use automation within your organization, trust your own macros and disable the rest (yes, you can do that and yes, it's easy - stay tuned, I'll write this up in the next week or so).

Get some semblance of a Security Awareness program going in your workplace.  Folks should know NOT to click links or open attachments in email.  This won't protect them from malvertising, but it's a great start.  It also won't protect you after that "second click".  Once a user has clicked "OK" to run malware, each successive click comes easier and with less thought.  After the second click it's a foregone conclusion, they're determined to get to the end - if the malware is any good that person (and their workstation) is compromised.

Hopefully, with the list above, you've got a number of layers in your defence-in-depth (yes, I had to say it) strategy.  But in the end, the link between the keyboard and the chair really is your last line of defense.

Have an incident response plan.  Be sure that nobody is talking about "cleaning" workstations or servers.  The absolute best recovery from any malware infection is "nuke from orbit" - wipe the drive and re-image from scratch.

BE SURE YOUR BACKUPS ARE UP TO DATE.  Be sure that you can recover yesterdays files, last week's files and last month's files.  Cryptowall attacks are often delayed, so that they get better coverage to help avoid detection.  Know that in the end, you will be compromised, and you will need to do the Incident Response and data recovery thing.

Does this list sound familiar?  I'm hoping so - essentially it's the first 14 of the 20 CIS Critical Controls https://www.sans.org/critical-security-controls and https://www.cisecurity.org/critical-controls/.

Is this list complete? I'm guessing not - what important thing am I missing?  Please, use our comment form and let us know what you've been doing to stem the tide of malware we're seeing lately.

 

===============
Rob VandenBrink
Compugen

15 comment(s)

Comments

Unfortunately, "get rid of those plugins" is not as easy as it may seem.
For example, Flash is still (or rather, once again) required for the VMware ESX/VSphere client, after they decided to ditch the traditional standalone (fat) client for a fancy web-based solution. Same goes for Silverlight on home PCs, as it seems to still be necessary for Netflix and Amazon Video clients. At least Java seems to be on its way out, as I see less and less business application needing it, aside from rather old SAP GUIs and Oracle Forms based stuff, and no significant home use software, since even Minecraft moved away from a global JRE.
Several of these suggestions, while not false, are completely unrealistic in many work environments. Many industrial and medical systems are running on old OS's and are using Java and Flash, old versions at that. Why haven't I patched everything on Tuesday and rebooted them all? Ever hear of change management? Scheduled outages during downtimes? Or maybe even TESTING? Microsoft has been known to release a bad patch. Even if they aren't bad themselves, they may not pay well with applications in our environment. As a result, a smart person would push them out to a test environment first.
Thru GPO you can restrict where programs can be run from so blacklist executables trying to run from a user's profile location such as ..\Users\username\AppData.
"...Have your rebooted your patched servers yet so the patches are actually live? Is there a really good reason why not?..."

Well, to give time to test the patches and see if they break something.

As for eliminating java, company uses an in-house, mission critical java app. No way that's going to change any time soon. But I can, on all but 3 computers, disable the java browser plugin. And for the 3 that still need the java plugin, that's because our bank requires it. Yes, you read that right. My pleas to switch banks have gone nowhere.
Glad to finally see a write up mentioning the need to properly ACL server shares - huge vector there for causing heartache to operational/prod systems (versus just a single user screaming because their laptop got held hostage).
the sans link is missing a colon after https

https://www.sans.org/critical-security-controls
It seems that there is always some user interaction needed to infect computers with ransomware. If you can't patch the system, then block access to the web and email completely will stop the vast majority of threats. Vulnerable systems should be sandboxed as much as possible.
We fought a losing battle last summer when Flash vulnerabilities and updates were coming faster than we could test them on our pilot group and then push them out to all workstations. User education didn't help because workstations were getting hit at legitimate web sites by drive-by downloads of a malicious ad calling an exploit kit, which delivered the Cryptowall. Searching for additional defenses, I looked into software restriction policies. Following the Third Tier Cryptolocker Prevention Kit recommendations, we tested and implemented GPO that prevents executables from running in the appdata and temp folders. We had no negative effects from that and we have a few confirmed cases where the Cryptowall randomly-named executable landed in a user's appdata folder but did nothing because it couldn't execute and then our anti-virus quarantined it.
Very cool, great approach!
Old OS's:
Yes, lots of us are saddled with these old OS's. The best approach is to put them in a VLAN by themselves, and restrict access in and out of that VLAN to just what's needed. If possible don't give that subnet internet access.

Change Management:
Patch Tuesday is known in advance, scheduling a change window that evening or the following Wednesday should take care of that. You can schedule the next 12 Windows tomorrow :-)

Testing:
I don't know of many IT groups that have time to test Microsoft Patches to any degree. If you do, you're in an exceptional organization. Again, booking a "Patch Wednesday", and watching the IT press for problems on Tuesday is a good approach for lots of shops.

Diary Archives