Browse your product documentation including release notes and installers
Cybercrime has become a lucrative business and, unfortunately, ransomware has become an integral attack method used by cyber criminals.
The most effective means to combat ransomware is to deploy Cb Protection in a default deny posture, or what we like to call High Enforcement. In High Enforcement, any new files introduced into the environment need to be approved to run either by automated approval methods or by manual approval.
It is not always desirable to put an endpoint into High Enforcement. Computers in your environment might need to be in Medium Enforcement, allowing the end user to choose whether to run unapproved files, or Low Enforcement, in which all files that are not banned can automatically run. Even in High Enforcement, living-off-the-land attacks can leverage approved tools like script processors to encrypt your files. Fortunately, Cb Protection now provides a new way to protect endpoints from Ransomware in these situations.
In Cb Protection 8.0 Patch 5, our new Ransomware Rapid Config delivers the rules required to protect endpoints in all enforcement levels (low, medium, and high) against many forms of ransomware, automating the protection process and reducing defensive efforts.
The Ransomware Rapid Config works to protect against several attack vectors. It:
During testing, Cb Protection with this Rapid Config enabled proved to be greater than 80% effective in stopping the ransomware we tested, and this was in Low Enforcement.
The Rapid Config is broken down into several functional sections, each of which has rules applicable to a particular attach vector. Each section provides you with a means to choose how you want to handle the attack vector it responds to. You can choose to:
Protecting documents and images from ransomware that encrypts a file in-place
The first section of the Ransomware Rapid Config analyzes the contents of files, detects if there is an attempt to change the file type, and terminates the process attempting the write. This allows Protection to prevent ransomware from encrypting a file in place.
It will block or report on any attempt to encrypt the following file types: doc, docm, docx, xls, xlsm, xlsx, ppt, pptm, pptx, rtf, pdf, png, jpg, jpeg, bmp, gif, and tiff. As we get feedback from customers we will add more file types over time via the cloud.
In this section there are two types of exceptions:
There are two important points that deserve attention. The first is that that any process that triggers a block in this section will be terminated. This is why we recommend using this feature in Report mode first to determine if there may be any unintended consequences.
Secondly, if you create a file with an extension that we are monitoring (like doc, xls, ppt, etc) but the file is not actually of that type, the file will not save. Cb Protection will see that the file does not contain the correct file data and will block the save.
Protecting documents and images from renames and deletes
The Ransomware Rapid Config has three different sections that work to prevent renaming and deleting of files with the flexibility to refine the functionality for your environment.
These sections are divided by file type: Documents, Images, and Other files. For each of these sections you can specify the types of files to monitor, the processes allowed to monitor them, and specific files that should not be monitored.
In addition, for each of these sections you can decide whether to allow interactive sessions of cmd.exe and PowerShell to rename or delete the file types listed so that administrators or end users can manipulate these files from an interactive shell window.
By default the Rapid Config looks for renaming and deleting of doc, docx, xls, xlsx, ppt, pptx, pst, and pdf files by any process other than Explorer, Word, Excel, PowerPoint, Outlook, and lynchtmlconv.exe. If any process other than those tries to rename or delete those file types, the file operation will be blocked or reported upon.
While building and testing this Rapid Config, we saw a lot of file activity in the temp folder within Local AppData. Given that this is a temporary location and monitoring or blocking activity in it has the potential to create unnecessary noise and potential application installation conflicts, we added a file exception for this directory.
The image section looks to protect image files of type png, jpg, jpeg, bmp, gif, tif, and xcf. The applications that we allow by default to rename and delete these file types are MS Paint, Explorer, Gimp, and Photoshop. You can add any additional image editing applications that you have in your environment.
The Rapid Config does not monitor changes to those files types in the following locations: Local AppData, Cb Protection’s install directory, Common AppData, and Program Files.
You will likely see a high number of false positives using image protection and will need to fine tune for your environment. You may need to allow additional image tools like Snagit, Snipping Tool, and other Adobe applications that need to rename and delete files. In some cases, it might be easier to create exceptions for specific image locations rather than listing a large number of process exceptions. For example, specifying the path to your users’ Documents directory under “Image Files That Should Not Be Blocked” rather than having *.jpg, *.png, etc under “Image Files To Block” and a list of processes that can modify those.
Other File Types
If there are other file types in your environment that you want to protect, the Other Files section allows you to add any additional file types that should not be renamed or deleted. Simply add the extensions you want to block and the processes that should be allowed to rename and delete them. It’s always a good idea to add Explorer.exe to the list of processes allowed to rename or delete files so that users can manipulate the files from the shell.
Blocking file and registry changes that are indicative of a ransomware attack
Ransomware will often times create shortcut links in startup folders in an attempt to be persistent and to leverage an OS vulnerability which allows the execution of code simply by opening a folder that contains the shortcut link. The Rapid Config can report or block this behavior by looking for the creation of *.dll.lnk files in startup folders.
Other ransomware artifacts that we look for include registry entries that are created by CryptoLocker. Preventing the creation of these entries can prevent CryptoLocker from running.
Preventing the use of VSSAdmin to delete shadow copies
The final section of this Rapid Config involves the Microsoft tool that enables administrators to manage the Volume Shadow Copy service. The Volume Shadow Copy service performs file and volume backups while files are in use. A malicious process can call the VSSAdmin command-line utility to delete backup copies, preventing the user from recovering files that have been encrypted by ransomware.
Protection looks for “delete” within the command-line that calls VSSAdmin and if it detects that parameter it will immediately terminate that process.
The Ransomware Rapid Config is a powerful weapon to add to your security arsenal. We recommend that as soon as you enable this Rapid Config set each section to Report mode and see what types of events are generated. This will enable you to make modifications and customize for your environment, adding process and file exclusions that you may need.
This looks great - hope to get it in our environment soon.
If I put this in report mode, what would be the best way to filter events to see if this rapid config would block anything?
Rule Name begins with Ransomware Protection:
This has energized me to make the most of Rapid Configs!
Please see and vote up my idea on
Thanks pvz for your explanation of same.
Can I get an opinion?
Why would you? Or would you not?
Add <InternetCache> to "Image files that should not be reported"?
Do you care what happens to image files in your Internet cache? I'd probably guess you wouldn't care, so why bother reporting on them? Although, you could argue that it would alert you to the attack, but I'm sure there would be other indicators.
Just digging into RC's and without the granularity of other methods I want to ease into it.
I feel that when practical, defining a narrow path to Image Files That Should Not Be Reported
Is better than defining a process.
Now here is a bigger one.
It could write in lots of places.
Seems like a good candidate for an approved process.
Thanks as always for your help!
You should be OK adding msiexec as a process allowed to rename and delete images.
Alternatively, you could just protect the paths to where your docs and images are located. For example, if your users put everything in \Documents then you could just protect that area (and remove *.doc, etc). Then you wouldn't need to worry about potential false positives with msiexec.