cancel
Showing results for 
Search instead for 
Did you mean: 

Best practices for securing your environment against Cryptolocker and ransomware

100% helpful (10/10)

by Roy Tobin, Webroot Threat Researcher.

 

In this tutorial we are going to explore some additional steps to help secure your environment. First thing to mention is that the following guide is only a rough guide and will need to be catered for each environment.

 

This guide comes with a health warning, this may cause certain programs to not install/function

 

Some tips before we start:

  • Verify Webroot installed and setup correctly
  • Ensure the latest Windows updates are applied
  • Keep all used plugins up to date (Java, Flash, Adobe etc.)
  • Use a modern browser with an ad blocker plugin
  • Disable Autoruns
  • Disable Windows Scripting Host
  • Have users running as limited users and NOT admins
  • Backup+ Backup+ Backup+ Backup!

What we are going to do is to create some Windows Policies to block certain paths and file extensions from running.

 

Having Windows running with the latest updates is something that should be given, a number of infections are blocked by Windows if you have the latest updates. Having those disabled is not a good idea.

 

Java generally gets the most coverage when it comes to exploited software but it applies to nearly all commonly used plugins. Generally speaking if you do not intend on using certain plugins it’s better to not even have them installed (less exploits).

 

If you do use them make sure they are up to date, i.e. do not disable the run keys for the Java updaters etc.

 

Example of a Java updater service:

cryptolocker1.png

 

Having users running as local admins is generally not a good idea, it can’t always be avoided but a limiter user cant install a rootkit or access most of the registry. If possible set users to be limited users. Limited the users access to network shares and other PC’s is also a good idea

 

Introduction to common paths:

 

In this document we are going to talk a lot about paths and file types so a brief introduction is useful. Malware generally speaking drops in a few common paths, once there it is free to move around about the PC (and network paths)

 

Common paths for malware to drop:

  • Users temp folder (often called %localusertemp%)
  • Appdata and its sub folders (Roaming,local app data)
  • Users profile
  • Temp folder (%temp% or C:\Windows\temp)
  • Browsers cache folder (%cache path depends on browser used see below for an example)
  • c:\users\admin\appdata\local\microsoft\windows\temporary internet files\content.ie5\
  • Desktop folder

To go to the paths with the % in them just type the full phrase into a run window or windows start search i.e. %temp% will go directly to C:\Users\admin\AppData\Local\Temp

 

Once the infection is on the PC and is actively running (important distinction to make). It can move itself to make itself more difficult to find or to move to location that can help it spread. Common paths encountered. More sophisticated malware can spread to network paths. It can use a registry entry to autostart or another method (scheduled task, service etc)

 

  • All of the above paths already mentioned
  • C:\program data\ (this is a hidden folder by default)
  • C:\Windows
  • C:\Windows\System32
  • C:\Recylcer\ (hidden folder, recycle bin)
  • Root of the c:\
  • C:\Program files\ (both 32,64bit paths, common location for PUA’s)

Malware will often use well-known names or Windows system names to try to throw off the user. For example Winlogon.exe is a core component of Windows and is located at:

 

c:\windows\system32\winlogon.exe and is around 450 kb in size

 

If we see a WinLogon.exe file in the user’s temp folder that is twice the size it should be a red flag and the file should be looked at! Don’t worry that’s Webroot job!

 

This is all taken care by Webroot but I hope the above gives an idea of what we are trying to do with this document. In the following sections we are going to use some policies to restrict access to certain file types and paths. The more restrictive we are the better however it can lead to certain programs not functioning.

 

Browsers:

 

It’s advisable to have a second browser installed for a number of reasons:

 

  • If your only browser gets damaged it can make connecting remotely difficult (not everybody uses RDP)
  • PUA’s or malware can reduce the speed of browsers so badly that they become unusable.
  • Some sites may not render correctly on old versions of IE. Firefox/Chrome can be used to test if this is the case
  • Older versions of Windows do not have the ability to install newer versions of IE
  • Newer browsers can use plugins

There are dozens of browsers available to us but Chrome and Firefox and the two most popular browsers on the market at the moment. Another very useful ability of Chrome and Firefox is the use of plugins. Some of these can be quite helpful and can stop issues entirely.

 

Useful plugin types:

  • Ad-blockers
  • Script blockers
  • Web filters (Webroot)

The ad-blocker is one that is often asked about, while many websites need advertisements to stay online we have seen recently more and more very popular websites (i.e millions of visitors a year) infecting customers due to 3rd party hosted adverts on their websites. The FBI infections are still commonly using adverts to either scare users or get them to download an infection.These plugins can be installed and left without any user input, very useful for less technical users.

 

Script blockers stop Java scripts running on websites unless you specifically ask for. These require a bit more technical knowledge on the user’s behalf and thus aren’t recommended for the less technical user.  Many websites will use Flash, Java plugins and if a user isn’t able to figure this out it can lead to support tickets/calls.

Web filters are very commonly installed by AV products and can act as a first line defence against threats. They can scan websites before the user gets a chance to see them, thus stopping threats from getting a chance to be executed.

 

Below is the Webroot Filtering Extension installed in Chrome.  This checks website reputations and will alert the user if they are visiting a site that is unsafe:

cryptolocker2.png


Disabling Autorun:

 

While Autorun is a useful feature it can be used by malware to spread around a corporate environment. With the growth of USB sticks there has malware is increasingly using Autoruns as a method to automatically run (and spread). Commonly used by VBS malware and worms to spread its best to disable it as a policy. We can disable Autorun easily enough by using the Local Group Policy Editor:

 

Note that this doesn’t affect the functionality of USB drives

 

  • Click the start Menu and type gpedit.msc and hit enter
  • Under Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Autoplay Policies.
  • In the Details pane, double-click Turn off Autoplay.
  • Click Enabled, and then select all drives in the Turn off Autoplay box to disable Autorun on all drives.

cryptolocker3.png

 

Using the Policy Editor to block paths:

 

Policies are a powerful tool that you can use for a multitude of reasons. They are commonly used to stop users from opening or installing certain software however you can get quite creative with them.

 

In the cases below I am using local policies but the same principle applies to network group polices.This guide is only a brief introduction but if you want more information I would advise looking at the link from Microsoft show below:

 

https://technet.microsoft.com/en-us/library/bb457006.aspx

 

Policies can be setup in groups so you can have more/less strict policies for certain groups. This can be useful if you have a group of users that need more access or are more tech savvy. When creating new policies it is vital that they are tested on a non-mission critical PC’s.

 

Examples of useful policies:

 

  • Block the opening of executables in temp
  • Block the modification of the VSS service
  • Block the opening of executables in temp+appdata
  • Blocking creation of startup entries

Realistically the following files types shouldn’t be run in the following directories:

 

  • .SCR,.PIF,CPL in the users temp, program data or desktop

A policy on the above would be a reasonably safe. Crypto ransomware are currently using the .SCR file format at the moment. The .SCR file format is a portable executable which is sometimes forgotten.

 

You could go another step and create a policy blocking PE file formats from common paths where droppers are located

 

  • EXE,DLL,SYS,FON,EFI,OCX and .SCR
  • Temp+Appdata+ProgramData etc

You can open the Local Group Policy Editor by running the following process.

 

Please note that we advise that you test any policies on a test PC that is not mission critical!

 

To open the Local Group Policy Editor from the command line

  • Click Start , type msc in the Start Search box, and then press ENTER .

To open the Local Group Policy Editor as an MMC snap-in

  1. Open MMC. (ClickStart , click in the Start Search box, type mmc , and then press ENTER .)
  2. On the File menu, click Add/Remove Snap-in .
  3. In theAdd or Remove Snap-ins dialog box, click Group Policy Object Editor , and then click Add .
  4. In theSelect Group Policy Object dialog box, click Browse .
  5. Click This computer to edit the Local Group Policy object, or click Users to edit Administrator, Non-Administrator, or per-user Local Group Policy objects.
  6. Click Finish.

cryptolocker4.png

cryptolocker5.png

 

Testing out a policy:

 

To create a policy you need to expand out the tree to get to the following:

Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies

First thing is to modify a setting in the Enforcement. Change it from “All software files except libraries” to “All Software Files”

 

cryptolocker6.png

 

Creating a Policy:

 

To create a policy right click on the right hand side of the Policy window and select “New Path Rule”

 

cryptolocker7.png

Then we get a small window in which we can use to create our rules. In this window we can browser to specific folders or we can use common Windows wildcard paths.  In the case below I have created a policy that will block an executable files running from the following path:

 

C:\Windows\Temp

 

This is the Windows temp folder and it is used by a number of programs and installers and thus will probably cause some issues but it’s useful to demonstrate what we can do. We can get quite creative with the paths and in the screenshot below.

 

Note that in the case above the user can’t run anything from their desktop!

 

  1. %appdata% (this is the local users app data folder, a common location for droppers)
  2. %temp% (most common location for dropped malware)
  3. %userprofile% (root of the users profile path, can be a bit too strong)
  4. %localappdata% (local users appdata)
  5. %programdata% (Windows Vista and above)
  6. C:\Windows\Temp (Windows temp)

Please note that a number of legitimate programs (and updaters) run from the user’s appdata.

 

cyrptolocker8.png

 

In the case below I have created a few policies to block executables from running from the following paths:

 

cryptolocker9.png

 

In the case below I have attempted to run an executable that is located on the local admins desktop. As you can see Windows pop-ups an alert and the program doesn’t run. If I move the file to another path that doesn’t have a restricted policy (in this case c:\) the program will open without any issues.

 

cryptolocker10.png

 

Fixing issues with blocked programs

 

As mentioned earlier a number of programs will stop working if you apply policies to the local user’s appdata and temp folder. For example in the case below the popular browser Chrome will no longer run on the PC.

 

This is due to the policy of blocking all executables from the users profile folder. This is quite a strong policy but is quite broad reaching! In this case after some testing I have disabled that policy and started creating small more focused path + file polices

 

cryptolocker11.png

 

Mozilla Firefox will still open as its installs to the C:\Program Files\Mozilla\ location. Internet Explorer will also still run as it’s located in the program files path.

 

We can create an individual path+file policy rule as shown below.

 

cryptolocker12.png

 

Blocking access to the Volume Shadow Copy Service

 

On Windows XP and above Windows will create local copies of files using the VSS copy service. It is located in the following path:

 

C:\Windows\System32\VSSAdmin.exe

 

In the earlier versions of CryptoLocker it was noticed that it didn’t stop and remove the VSS copies and thus data could be recovered. One of the most popular tools for this is Shadow Explorer although you can use the Windows function to roll the data back. It’s worth noting that VSS copies are only for the local drive (normally C:\).

 

The VSS service is realistically only useful in Vista and above and it’s a last ditch option for encrypted files.

 

cryptolocker13.png

 

Please note the VSS is not a substitute for backup!

 

We can lock access to the service and thus stop Cryptolocker from trying to erase file backups. We just create a policy like have earlier but point to the VSSAdmin executable. Any attempt to access/stop the service will result in a block.

 

 

cryptolocker14.png

 

If a program tries to access the VSSadmin service it will either be blocked or it won’t open.

 

cryptolocker15.png

 

Disabling the Windows Script Host to block VBS scripts:

 

VBS scripts are used by malware authors either to cause disruption in an environment or to run a process that will download more advanced malware. The ILOVEYOU VBS malware caused a huge amount of damage back in the early 2000’s. Nowadays most VBS scripts causing more irritation like hiding folders, moving files etc.

We can disable them completely by disabling the Windows Script Host engine which is what .VBS files use to run.

 

Warning if your company uses any login scripts they won’t be able to run

 

Note you can also use a policy to also disable the use of VBS files  (see the MS link posted earlier)

 

The following two registry entries are the two entries that are used to block the Windows Script Hosting Engine Executable from running (Wcscript.exe)

 

HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings\Enabled

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings\Enabled

 

When a VBS file attempts to run with the above registry key enabled any VBS script that attempts to run will see the following error message:

 

cryptolocker16.png

 

This is a simple method to block these, the following two registry keys are located below if you wish to use them. You can use the policy editor to create more custom versions if you do need to run scripts:

 

http://download.webroot.com/VBSDisable.zip

 

http://download.webroot.com/VBSEnable.zip

Version history
Revision #:
10 of 10
Last update:
‎07-30-2016 05:20 AM
Updated by:
 
Comments
Microsoft Windows
Webroot

Awesome Thanks Roy and Nic I have bookmarked it!

 

Daniel Smiley Wink

Roy knocked this one out of the park, if I could give him 1000 kudos, I would. Great article!

RenatoRei

Thanks for the article very informative and well put together!

LuisPires

Gold! well done!

 

Smiley Happy

shenkee

Nice article! Thanks!

But I cannot find Webroot Filtering Extension at Chrome web store. Neither at the Mozilla Addons Site.

The filtering extension should get installed with Webroot automatically.  But if it's not working for you let me know and we can get you on the beta version, which has a new driver-based filter, which doesn't depend on browser extensions.

tcsllc

I couldn't find the filtering extension too. Is it only for PC?

Microsoft Windows
Webroot

@tcsllc would you be using the Gamer version by any chance? I have seen issue with the Web Filter and no PKG Folder and wrUrL Folder in the WRData Folder but never reported so I will now!

 

Thanks,

 

Daniel Smiley Wink

tcsllc

@TripleHelix I'm using Business Endpoint version.

Microsoft Windows
Webroot

@tcsllc I'm not sure if the Web Fiter extension is released to the Business Endpoint version? @foo @nic @JamesG

 

Thanks,

 

Daniel Smiley Wink

The web filter on the business side uses a different technology currently.

Microsoft Windows
Webroot

@nic is it the old version that pop-ups this Block Window Box on the Business version?

 

2015-04-12_7-22-25.png

I believe so - there's plans in the works to shift the business version over to the newer technology that the consumer version uses, but that's a work in progress.

KyleS

 If you block access to the VSSadmin.exe program using SRP won't you prevent Windows System Restore from creating new restore points?

Windows System Restore runs under the SYSTEM account which is (confirmed) not affected by this policy. So, it shouldn't Smiley Happy

edanto

Could this be updated if needed?