Lately it has been noticed an increasing spread of threats which, entering a system by various means are encrypting several files on the attacked system like office documents, database files, e-mail archives, which represent a value for the attacked customer.
Those threats generally, after encrypting the files, sometimes delete themselves or propagate through the network.
To decrypt the file the hackers generally ask to pay a certain amount of money.
In order not to create misunderstandings, customers need to be aware of the following: encrypted files will remain encrypted. These should be replaced from a known-good backup (and Enterprises are responsible for regularly backing up their own important data).
Symantec products do not decrypt files that have been affected by these threats.
Why? The reason is as simple as very often not considered. The majority of these kind of threats is using an RSA public-key cryptography at 1024 or 2048 bits. Despit of a number of commercial tools which are released the truth is such: for large RSA key sizes (in excess of 1024 bits), no efficient method for solving this problem is known (this is the so called "RSA problem")
To know more about it:
http://en.wikipedia.org/wiki/CryptoLocker
http://en.wikipedia.org/wiki/RSA_(cryptosystem)
http://en.wikipedia.org/wiki/RSA_problem
Anyway, to pay the hackers is not a solution at all.
When a customer pays the hackers, there is no guarantee that the attacker can or will supply a method of unlocking their computer or decrypting their files. For some variants, Symantec has received reports that the threat was received, the attacker provided a code to allow the threat to un-do the encryption that has been done on the customer’s files. Then, once Symantec updated our detection, the threat .exe is removed (deleted/quarantined) and the un-encryption can no longer continue.
When customers pay hackers for threats, such as these, it encourages attackers to continue these tactics and additional attacks against everyone.
Please do not pay the hackers!
Additional information about those threats
http://www.symantec.com/docs/TECH211589
https://www-secure.symantec.com/connect/blogs/ransomcrypt-thriving-menace
https://www-secure.symantec.com/connect/blogs/cryptolocker-alert-millions-uk-targeted-mass-spam-campaign
https://www-secure.symantec.com/connect/blogs/cryptolocker-qa-menace-year
First Response
If the infection somehow already entered in our environment, the damage, unfortunately is already done.
Anyway, if we identify the threat in a timely manner, we can prevent the threat to spread and contain the damage.
Whenever you find a system in your environment which is being infected from this kind of encrypting threat, the first thing to do, even more than in other cases is:
Isolate the machine from the network!!
Afterwards, you will need to identify the virus finding the executable file and submit it to Symantec Security Response.
Hint: in order to help yourself in identifying the malicious files, you can run a threat analysis on the affected machine using the SymHelp tool:
http://www.symantec.com/business/support/index?page=content&id=TECH215519
Then, contact the Symantec Enterprise Technical Support to know how to submit files:
http://www.symantec.com/support/contact_techsupp_static.jsp
In order to stop the eventual expanding of the threat in your environment, through the Symantec Endpoint Protection, you can use the “Application and Device Control” component to block the execution of that specific file, identifying it through the hash MD5:
http://www.symantec.com/business/support/index?page=content&id=TECH93451
An alternative way to get the hash MD5:
http://www.symantec.com/business/support/index?page=content&id=TECH96745
Once the threat has been blocked and the incoming new definitions from Symantec will remove the threat we can restore our data from backup.
There are many ways to maintain a safe backup of sensible data: each organization can choose the most suitable to its needs. Here an example:
http://www.symantec.com/connect/articles/recovering-ransomlocked-files-using-built-windows-tools
How to prevent this unpleasant situation to repeat?
What the most of the people who faced this kind of threat at least once surely will desire, it is not to face it anymore.
To achieve this it is possible to take proactive steps to protect our environment.
- Disable Auto-Run
The first thing to do, if not done already, surely is disable Auto-Run feature on all machines:
http://www.symantec.com/business/support/index?page=content&id=TECH104447
- Enable IPS (Intrusion Prevention System) component:
http://www.symantec.com/business/support/index?page=content&id=TECH95347
http://www.symantec.com/business/support/index?page=content&id=TECH104434
http://www.symantec.com/connect/articles/two-reasons-why-ips-must-have-your-network
- Increase the overall security
Moreover, again using the “Application and Device Control” component it is possible, it is possible to harden the overall security of the system with a specific policy:
http://www.symantec.com/business/support/index?page=content&id=TECH132337
http://www.symantec.com/business/support/index?page=content&id=TECH132307
Anyway, this is a general mean of prevention, helpful but not specific for this kind of threats.
It is always recommended to test the policy accurately before applying it massively to any production environment.
- Lock your system down
Surely effective solution which will protect you from this and other kind of threats, it is to use the Symantec Endpoint Protection feature which is called “System Lockdown”.
It is based on the idea that an organization uses a determined and pre-allowed set of application which can be collected and allowed by an administrator, blocking the execution of anything else.
This document contains a guide to this feature:
http://www.symantec.com/business/support/index?page=content&id=HOWTO55130
CAUTION! Anyone who would like to implement this feature is invited to test it deeply! An incorrect deployment of the feature can highly compromise the functionality of the systems in object.
- Granular approach (using Application and Device Control)
We can implement an application and device control policy to block the execution of the most common file extensions used by this class of threats, in the paths which are known to be the common launch points.
About “Application and Device Control” in general:
http://www.symantec.com/security_response/security updates/list.jsp?fid=adc
Attached to this article it is given an example of policy which can be imported in SEP Manager and it is ready to use.
Please keep in mind: before implementing this policy massively in a production environment, test it on a small grouop of machine, verify its compatibility to your needs. Also feel free to customize it as you may find more appropriate
What are the features of our policy?
- Blocking Auto-Run (works out of the box)
- Blocks access to script files (works out of the box)
- Blocks execution from removable drives (the details about the device types should be added. For an example of device ID check: http://www.symantec.com/business/support/index?page=content&id=TECH175220)
- Blocks the execution of files with extension “.exe”, “.com”, “.scr”, “.pif” from the known launch points of those threats and also from some kinds of archives.
Here the complete list:
%appdata%\
%appdata%\*\
%temp%\
%temp%\*\
%temp%\rar*\
%temp%\7z*\
%temp%\wz*\
%temp%\*.zip\
%iappdata%\
%localappdata%\
%localappdata%\*\
%userprofile%\Local Settings\Application\
%userprofile%\Local Settings\Application\*\
C:\$Recycle.Bin\
C:\$Recycle.Bin\*\
Please Note: This policy is going to block whatever file with the listed extension which is executing from the given locations. This may include also genuine third party applications or custom made applications.
You can anyway exclude custom application from being blocked adding them in the section “Do not apply to the following processes” located in the condition of the rule.