Kaseya Community

Cryptolocker Mitigation ideas?

  • I'm surprised I haven't seen any posts about this threat yet.  I'm wondering what other providers are doing to mitigate the CryptoLocker threat?  If you haven't heard of this lovely slice of heaven, here additional details:

    http://www.bleepingcomputer.com/forums/t/506924/cryptolocker-hijack-program/page-26#entry3165383

    http://www.reddit.com/r/sysadmin/comments/1mizfx/proper_care_feeding_of_your_cryptolocker/

     In addition to email and web filtering it seems many people are using Software Restriction Policies to deny .exe files from running under the %AppData% folder or subfolders.  We were hoping there might be a way to deploy a SRP via command line or similar so we could simply script it.  I haven't had any luck finding a way to do that.  In the meantime we're using a GPO at our customers in Domain environments but it would be great to come up with a solution for workgroup PCs and road warriors.  Any ideas on how we can use Kaseya to accomplish something similar?



    formatting
    [edited by: topdogpc at 6:37 AM (GMT -7) on Oct 11, 2013]
  • There is an area in the registry where SRP lives, but the challenge is going to be how these rules generate hashes. I'm looking into some alternative deployment methods because Group Policy sucks for MSP's.

    technet.microsoft.com/.../cc786941(v=ws.10).aspx

  • Using Process Monitor, I found two registry keys generated when I created the SRP rule manually:

    [code]HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\safer\codeidentifiers\0\Paths\{UNIQUE_ID}[/code]

    [code]HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{7B72EA4D-22D1-40FF-99D2-741BB6507A7A}Machine\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\0\Paths\{SAME_UNIQUE_ID}[/code]

    So far, simply re-importing these keys and values does not appear to re-create the SRP rule in the GUI, however, it may be actually blocking stuff... Still experimenting...

  • Thanks, i am researching solutions too.

    I believe the path we want to be blocking is %userprofile%\appdata\*.exe

  • I'm shooting for %AppData%\*.exe & %AppData%\*\*.exe per the Reddit post you linked above. It sounds like %userprofile% only comes into play after CryptoLocker runs.

  • Here's the part I'm citing:

    "Once the program runs it spawns two more executables with random names in %userprofile%. Adding a SRP to cover %userprofile%\*.exe may be desired, though this will prevent GoToMyPC from running at a bare minimum."

  • %AppData% = C:\Users\{user}#\AppData\Roaming\

    If your trying to get to the root of appdata folder than you need the path i listed.

  • I see what you're saying now. Give me one sec and I'll have a script for you to test.

  • I'm still in the early stages of testing this.

    I've had luck internally exporting the hklm\software\policies\microsoft\windows\safer\codeidentifiers key from a system that I'd created the %appdata% SRP rules and importing them to a new machine.  I also found that I had to copy registry.pol to the destination machine from c:\windows\system32\grouppolicy\machine\registry.pol.  I've imported the .reg file and copied the .pol file to a couple test 64 bit machines via a script and it is effective after a reboot.

  • Try running shell command "GPUPDATE /FORCE /wait:0" instead of rebooting.

  • When you did that did it copy only that one security setting or all security settings? Just in case some users have custom security setting from previous time i dont want to overwrite those settings.

  • So even though this works for us (so far), it does not show the newly created rules in GP.  Probably not a huge issue.

    On 64-bit systems the script is copying to %windir%\Sysnative\GroupPolicy\Machine\Registry.pol

    on 32-bit systems the script is copying to %windir%\System32\GroupPolicy\Machine\Registry.pol

  • I'm not 100% sure we need to mess with the registry.pol file yet. See its description here: technet.microsoft.com/.../cc978247.aspx

  • It copied all security settings from the original system.  In this case, it was the 2 default settings that are created when you enable SRP and the 2 I created to deny *.exe from %appdata% and its subfolders.  Copying the .pol file obviously overwrites what's there.  I've not yet tested the registry import on a system that already has a policy set so I'm not certain what the effect is.

  • You might be right about the .pol file.  I'm checking it out.