Preventing and Mitigating Ransomware

I'm a poor writer - hopefully this will be better than my anti-Lavabit rant.

With the proliferation of Locky and it's variants, I'm sure every single one of us is finding that we're missing a piece of the security puzzle somewhere.  If you're unfamiliar with Locky, it's a form of malware that encrypts vital documents and programs and requests you pay a fee in BitCoin in order to decrypt them.

My networks have been hit twice. Fortunately I run FreeBSD Samba servers, with ZFS snapshots and replication. Desktops are considered disposable. We're also primarily manufacturing, so a rollback on affected areas was a snap.  A GPO (discussed below #3) prevented further outbreaks. Another connected company, considered 'lower risk' due to it's type of employees then had it's own outbreak.  There were MANY failures involved there.  I'll start with triage, and move on to prevention and containment.
This blog post assumes you are already doing the basics: No local admin rights. Some sort of centralized directory authentication and policy deployment. Anti-Virus installs (yes it's still helpful - every little bit helps no matter how insignificant it may seem). Patching of any sort whatsoever.  Regular backups.

One HUGE hole in our defenses - SQL.  Once Locky starts using ODBC and encrypting preconfigured DSNs, we're all going to be in a world of hurt. I've been in many organizations, and even in the larger ones (credit card processing specifically) I highly doubt ANYONE is properly securing tables. You'd think SQLSlammer would have been a wakeup call - IMHO the next Locky will be that call.

Anyways, here is where I started - how Locky was executed, and what we're doing to mitigate the issue of ransomware.  I do not include 'user training'. 
IMHO, When planning a proper defense, one should consider EVERY piece of end-user accessible equipment to be hostile - including your own.  DO NOT, UNDER ANY CIRCUMSTANCES, EXCLUDE YOURSELF FROM ANY RULES.


1.    Email not in junk folder.  CompanyA users had it in Junk.

• Fixed, applied GPO to CompanyB and CompanyC so Outlook properly filters email marked as Spam.
• This is due to our use of ASSP on the front-end of mail for Spam tagging, and the funky requirements for Outlook/Exchange to filter email based on a simple header.

2.    Word Macros executed.

•  Fixed – Assuming Macros were enabled.  Microsoft disables by default.  Policy forces disabling of Macros.  Does not prevent user from enabling macros on a per-document basis.

3.    Macro wrote bat file, executed VBScript (1)

• Fixed %temp% and %appdata% execution allowed in CompanyB and CompanyC.  Policy applied to CompanyC to prevent, but not CompanyB yet as it interferes with installers.

4.    Bat file executed VBScript.  cscript allowed to run (VBA commandline)  (2)

• No Action. Not sufficiently tested.  Disabled cscript/wscript site-wide in past lives.

5.    AV disabled by script.

• Fixed.  No user can disable AV on their desktop, was enabled for CompanyB.

6.    Download malicious file allowed - ran from %temp%

• Possibly Fixed.  Added 3rd party DNS category blocking service.

• Investigating transparent proxy w/AV. This will communicate with web sites on behalf of client PCs, AND scan downloaded files with a different AV.
• Proxies can be an issue if they’re not transparent, because – in a properly built environment - the application must support both the proxy and AD authentication.

• Fixed (see 3a)

7.    No backup for desktops.

• Compensating Control – Reminded users that local systems are not backed up and are vulnerable to many issues that can destroy local data.
• This can be anything from a HD failure to a virus to TSA confiscating equipment.

That was my initial investigation.  Since then, I've added to the list:

8.    Locky SMB browses all systems, and encrypts accessible data on all shares:

• Testing disabling browsing services - (Mapper IO Driver & Responder Driver).  This prevents Windows from seeing any other systems on the network.
• We map Network Locations to users based on AD Groups upon login. Drive letters are still used primarily, but can be UNC paths as well.
• Some shares have 'Everyone' allows in subdirs.  WTF?!?!  At least one Historical install has this.  Audit needed.

 9.  What can Locky do in the future?

• Can't browse PCs?  Ping local subnet.
• Segregate client & server networks to prevent subnet fingerprinting.
• Remove List rights from AD OUs that contain computer objects

•  SQL.  ODBC DSNs defined in local PCs?  
• Remove where possible.
• Rewrite reports to use DSN-less connections where possible
• Avoid popular SQL Servers (MSSQL).

Locky is a scary piece of malware. It can, and has, taken down companies large and small. We need to be vigilant and do our best to protect from what we know, and expect the unexpected.

Any suggestions?