Small Business Susan

Cryptolocker Prevention kit

Courtesy of http://www.thirdtier.net and in advance of the presentation
by SMBkitchen members at
http://smbtechfest.com this weekend in Irvine,
Amy Babinchak has graciously placed group policy templates and
instructions on how to prevent cryptolocker on your client’s networks.

This proactive setting and documents can be downloaded from


http://www.thirdtier.net/downloads/CryptolockerPreventionKit.zip


The kit consists of instructions for protecting your clients from the
virus, installing blocks on domain, non-domain machines and terminal
servers. It also includes pre-made group policy template to deploy.


It’s not too late to sign up for the SMBtechfest !



14 comments ↓

  • #   Ben Krause on 10.16.13 at 10:09 am     

    I like the approach you all are using here but I am a little worried about blocking all .exe files in the %appdata% or %localappdata% folder. I did a quick *.exe search of thes folders and found that there are many legitimate .exe files in there that would be blocked by this.

    The most prevelant I saw were Citrix, Java, and other Setup/Install.exe programs. Would it not be wiser to just block the offending .exe file related to the virus or does that change randomly? Or better yet to just block {*}.exe files from running from those directories.


  • #   Rob on 10.16.13 at 11:04 am     

    You should create a whitelist instead of blacklist (SRP).

    Blocking .exe’s from %AppData% will only block them from running in that single folder – Java, Citrix, etc. would still execute, but then again, it would only take a next iteration of the virus to compensate for subfolder structures.

    Whitelist is really the best answer here for this folder.


  • #   bradley on 10.16.13 at 11:06 am     

    The name is a random guid that changes.


  • #   bradley on 10.16.13 at 11:15 am     

    Whitelisting document is up next for the SMBkitchen project documents. This is an emergency doc we wanted to get out to everyone now.


  • #   Nndy on 10.16.13 at 3:01 pm     

    Perhaps I’m missing something, but after creating this policy, restarting a test workstation, and seeing in listed in rsop.msc that it’s applied, it still isn’t working (I tested by installing Google chrome).

    SBS2011 Group Policy also showed a different interface than the guide has it. It showed WMI as “Windows 7 and Windows Vista” instead of just “Windows Vista”. Can’t imagine how that would make a difference.

    All clients are Windows 7/8 based on latest patch-levels.


  • #   bradley on 10.16.13 at 3:14 pm     

    It may take a few reboots. And no the name wouldn’t have impact.
    If it still doesn’t take, holler back and I’ll see what’s up.


  • #   Ben Krause on 10.16.13 at 4:39 pm     

    Just to share with everyone else. I created the software restriction policy but instead created rules to block the following:

    %appdata%\[*}.exe
    %appdata%\*\{*}.exe
    %localappdata%\{*}.exe
    %localappdata%\*\{*}.exe

    Since we are being specific to the Cryptolocker ransomware I felt that since it generates a random guid .exe file (which I can’t verify on the internet because everyone specifies it creates the same guid file) that this would block any iteration it creates while still allowing other programs to run out of the appdata folder since obviously there are many other programs that are storing files there that may potentially run from that location.

    I was able to test that this worked by download winrar.exe and renaming it to {lalalalal}.exe and it would not allow it. I then named it anything else.exe and it would allow it to run.

    Hope that helps someone.


  • #   Nndy on 10.16.13 at 8:44 pm     

    Not sure what changed (Group policy refresh?) but it’s now working for me. No reboots on another test client.

    Thanks. Time to work on all the whitelisting. Or I might just change policy and demand all new/current software be in standard locations.


  • #   Nndy on 10.17.13 at 3:24 pm     

    These instructions will work…for a day.

    Cryptolocker will simply adjust this and write in %localuser%. So ideally you need to put that rule in, and whitelist legacy applications that install there, or make sure no executables are stored there.

    The day of executables being run by basic users is about over.

    There isn’t even a way to tell grandpa or joe user how to be safe with this. They will still click on executables regardless of your instruction.


  • #   L on 11.01.13 at 5:43 pm     

    test it out


  • #   Jo Wheeler on 11.04.13 at 5:50 pm     

    Does this work with WHS?


  • #   bradley on 11.04.13 at 5:58 pm     

    WHS isn’t a domain controller and thus doesn’t have a group policy. What you can do is do those policies on the local security policy section on each workstation.


  • #   Allen Tarlton on 12.10.13 at 9:55 pm     

    I still support quite a few SBS 2003 domains. I get a “The version option is invalid” when trying to import the settings into the GPO. Is there a modified version that works with SBS 2003 or a fix I can apply? Thanks.


  • #   bradley on 12.10.13 at 10:53 pm     

    It should work. if it doesn’t with your setup, just manually set up the group policies. See the whitepaper as it walks you through how to do them.