Cryptolocker

Detect CryptoLocker on a System

Proactive Detection Before Execution

Description

Proactively detect CryptoLocker on machines on which it has not executed so you can remove this particularly damaging form of malware before it does harm to your customers' systems.

Note: this Procedure doesn't remove CryptoLocker.

Category
Developer
  • Name: Marc Reiter
  • Company: Intrust IT
  • Website: http://www.intrust-it.com
  • Contact Developer
  • Summary
  • Detect CryptoLocker on a System
  • 304 Downloads
  • Released on June 20th, 2016
  • Average Rating

    5.00stars

    Rating Breakdown
    2 total reviews

    2
    2 5 stars reviews.
    0
    0 4 stars reviews.
    0
    0 3 stars reviews.
    0
    0 2 stars reviews.
    0
    0 1 star reviews.
    Reviews
    Gravatar for Jonathan Springham
    by Jonathan Springham on July 11th, 2016

    This works fantastically well - we have had several clients hit with this in the past few months so having this in place, running every hour gives us extra peace of mind. Very well written script. No reason not to use it!

    Gravatar for Marc Reiter
    by Marc Reiter on June 21st, 2016

    Please give credit to the original authors when pilfering their work. I wrote this. http://community.kaseya.com/resources/m/knowexch/86518.aspx

    Discussion
    Gravatar for Jonathan Springham
    Jonathan Springham about 1 year ago

    This works fantastically well - we have had several clients hit with this in the past few months so having this in place, running every hour gives us extra peace of mind. Very well written script. No reason not to use it!

    Gravatar for Matthew Bradley
    Matthew Bradley about 1 month ago

    I'm confused. Can't most (if not all) the damage inflicted be caused within the hour the scan hasn't run? We've had machines infected in the past and in about 15 minutes blow through mapped drives and entire user folders. Seems you need a honeypot approach that catches these infections within a few seconds.

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    We use several methods and all have been automated by kaseya scripts 1. FSRM on all servers that notify us when encryption files are being written to server disks in real time 2. A honeypot .doc file in every ones home drive that we scan every 5 minutes. If that file is messed with we automatically shut the computer down 3. Dummy folder structure at the top of all shares on servers with 2000 zero byte text files that tend to get hit first, then FSRM kicks in 4. Locking out the %appdata% directories on users so no exe and other files are written 5. We heavily use and automated the Kaseya application blocker on all agents 6. a few other fine scripts to automate recognition of the encryption process Lets face it, we will not be able to stop it. Best we can do is recognize when its happening and put enough things in place to notify and stop it before it does any further damage!

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    We use several methods and all have been automated by kaseya scripts 1. FSRM on all servers that notify us when encryption files are being written to server disks in real time 2. A honeypot .doc file in every ones home drive that we scan every 5 minutes. If that file is messed with we automatically shut the computer down 3. Dummy folder structure at the top of all shares on servers with 2000 zero byte text files that tend to get hit first, then FSRM kicks in 4. Locking out the %appdata% directories on users so no exe and other files are written 5. We heavily use and automated the Kaseya application blocker on all agents 6. a few other fine scripts to automate recognition of the encryption process Lets face it, we will not be able to stop it. Best we can do is recognize when its happening and put enough things in place to notify and stop it before it does any further damage!

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    We use several methods and all have been automated by kaseya scripts 1. FSRM on all servers that notify us when encryption files are being written to server disks in real time 2. A honeypot .doc file in every ones home drive that we scan every 5 minutes. If that file is messed with we automatically shut the computer down 3. Dummy folder structure at the top of all shares on servers with 2000 zero byte text files that tend to get hit first, then FSRM kicks in 4. Locking out the %appdata% directories on users so no exe and other files are written 5. We heavily use and automated the Kaseya application blocker on all agents 6. a few other fine scripts to automate recognition of the encryption process Lets face it, we will not be able to stop it. Best we can do is recognize when its happening and put enough things in place to notify and stop it before it does any further damage!

    Gravatar for Marc Reiter
    Marc Reiter about 1 month ago

    This is something I wrote years ago when cryptolocker was first showing up. Our techs were getting calls from people unable to access files on network shares because they were encrypted, then came the task of figuring our which workstation did the encryption so it could be removed from the network. The purpose of this script was to help identify the computer responsible for encrypting files, and to be a little pro-active to identify that a workstation is doing this before a client calls. Datto does something similar now. They will examine your backups to check for lots of newly encrypted files and will alert you of the issue. It's too late to stop it at that point, but now you know there is an issue and can start restoring. By the way, this script is pretty old now and really only checks for registry entries created by the original cryptolocker and cryptowall ransomware.

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    We use several methods and all have been automated by kaseya scripts 1. FSRM on all servers that notify us when encryption files are being written to server disks in real time 2. A honeypot .doc file in every ones home drive that we scan every 5 minutes. If that file is messed with we automatically shut the computer down 3. Dummy folder structure at the top of all shares on servers with 2000 zero byte text files that tend to get hit first, then FSRM kicks in 4. Locking out the %appdata% directories on users so no exe and other files are written 5. We heavily use and automated the Kaseya application blocker on all agents 6. a few other fine scripts to automate recognition of the encryption process Lets face it, we will not be able to stop it. Best we can do is recognize when its happening and put enough things in place to notify and stop it before it does any further damage!

    Gravatar for Matthew Bradley
    Matthew Bradley about 1 month ago

    Hey Dan. Thanks for the reply. We're currently implementing FSRM policies on servers with a honeypot approach but I'd like to hear more on how you're implementing Kaseya's application blocker. What exactly are you blocking here?

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    With the Kaseya application blocker, we add known problematic executables daily to the list on the kserver only. We then have a script that runs hourly to copy the list down to all agents. In the past we would select all agents and enter the executable but found that when you add a new agent, the new agent does not get the previous list, only new items added to the list. This new method guarantees the list gets to all machines hourly. Kaseya then blocks those executables from running. Still not a perfect science but none-the-less the more you can throw at the issue to be proactive, the better. Regarding FSRM, our script determines if a server has any file shares. If it does and FSRM is not installed, it will install it and configure it automatically per my specs. The FSRM script runs every 4 hours on servers and updates the file block list from an update internet site that has been managing known encryption text files placed on systems after the encryption process.

    Gravatar for Duane Godwin
    Duane Godwin about 1 month ago

    Hey Dan, your approach is great, and we are working towards the same setup. Would it be possible to see your app blocker list?

    Gravatar for Duane Godwin
    Duane Godwin about 1 month ago

    Hey Dan, your approach is great, and we are working towards the same setup. Would it be possible to see your app blocker list?

    Gravatar for Duane Godwin
    Duane Godwin about 1 month ago

    Hey Dan, your approach is great, and we are working towards the same setup. Would it be possible to see your app blocker list?

    Gravatar for Chris
    Chris about 1 month ago

    Hi there. I currently use the FRSM method to file screen all our servers and have found it to be a very good method of protecting files from encryption. I would recommend you have your list update every x minute(s) rather than 4 hours, it uses little resources to pull the txt file from the internet otherwise you leave yourself with a 4 hour window for "in the wild" malware.

    Gravatar for Matthew Bradley
    Matthew Bradley about 1 month ago

    I assume we're talking about this list from github which keeps up with the latest blocked file extensions? https://fsrm.experiant.ca/

    Gravatar for Chris
    Chris about 1 month ago

    Correct. VERY handy to have on all servers. We have Kaseya monitoring event logs for the ID it gives which automates account lockouts then shuts down the PC.

    Gravatar for Duane Godwin
    Duane Godwin about 1 month ago

    That's the list that I use, and it blocked an encryption event about five hours ago. Our client has several international offices - we look after the UK office. All other offices got nailed. We are smiling :-)

    Gravatar for Dan Mathieu
    Dan Mathieu about 1 month ago

    That is the list we use to

    Gravatar for T-Consulting
    T-Consulting about 1 month ago

    Apparently you cannot perform scheduled updates.(https://fsrm.experiant.ca/installation) How do you refresh the list every x minutes?

    Gravatar for Chris
    Chris about 1 month ago

    Run the PS1 file again and it updates it (For anything older than Server 2012). Or there is a second PS1 you can run for Server 2012 and above which will update the file group. Create a PS1 in C:\SCRIPTS with the two lines: new-FsrmFileGroup -name "Anti-RansomwareFileGroups" -IncludePattern @((Invoke-WebRequest -Uri "https://fsrm.experiant.ca/api/v1/get" -UseBasicParsing).content | convertfrom-json | % {$_.filters}) set-FsrmFileGroup -name "Anti-RansomwareFileGroups" -IncludePattern @((Invoke-WebRequest -Uri "https://fsrm.experiant.ca/api/v1/get" -UseBasicParsing).content | convertfrom-json | % {$_.filters}) Create a scheduled task to "start a program" with program "powershell.exe" and argument -ExecutionPolicy Bypass C:\scripts\updatelist.ps1

    Gravatar for Bill Philpot
    Bill Philpot about 1 month ago

    I believe to simply update, you only need the second line: set-FsrmFileGroup -name "Anti-RansomwareFileGroups" -IncludePattern @((Invoke-WebRequest -Uri "https://fsrm.experiant.ca/api/v1/get" -UseBasicParsing).content | convertfrom-json | % {$_.filters}) The group is created in the first, you will error out if you run it again due to the group already existing.

    Gravatar for Chris
    Chris about 1 month ago

    It works either way. It just skips the first time.