How To Avoid CryptoLocker Ransomware

Hi
Recently one of our customers was infected by a ransomware that was missed by WSA. It encrypted all files giving them the extension .omg! (Link to discussion if some wants to know more about this ransomware: http://www.bleepingcomputer.com/forums/t/506924/cryptolocker-hijack-program/).
It's a shame that Webroot missed it but there's no point crying over a spilt milk. I wonder what can we do to avoid it in future. If WSA is not 100% malwareproof maybe there are some other ways? I'm not an expert so I don't know if my way of thinking is right...but it seems to me that file encryption is quite a long process and operating system must be aware of this. So maybe Webroot should alert user everytime it detects the process of encryption? If it is initiated by a user then he can ignore it. If not then he can kill the process immediately. I don't know if it makes sense so I hope to hear from experts.

Did you contact Webroot when that machine was infected?
 
To me it seems that even if Webroot missed it, the Rollback and Journaling should be able to clean this up if the originated file is marked as bad.

Yes Webroot Support is working hard on this case but it seems that it's not as easy as it looks.

Last week my computer was infected by "Cryptolocker" and I lost all my files.  This happened before I installed WSA on my computer.  I had all my files backed up so all is well, but it was a hassle for a couple days as I had to do a complete reinstall on my hard drive.  Can someone update me as to whether WSA is now updated so as to defeat this ransomware?  From this three week old thread, it isn't clear WSA was up to the task at the time.  I've installed WSA on the recommendation of several different people, but I really need a product that can protect me from "Cryptolocker" and similar ransomware (the only infection I've ever gotten, by the way). Thanks.

One of the greatest things about Webroot is that when Support is notified about something getting past Webroot, it prompts our threat researchers to immediately jump on the files in question and get them blacklisted. We are usually out in front of these sort of issues before they become apparent, but in the instance something does slip past, the turnaround time for blacklisting an infection is nearly immediate once the issue lands in Support's capable hands. Two weeks out, yes, this variant is certainly classified by now. There will always be new variants of most any sort of infection, and we do our best to keep up with them.  Thanks to the support dynamic, in the event any threat makes it past WSA, the first person to notify us ends up protecting all of the other WSA-protected computers in the world by bringing it to our attention.

Is there any update from Webroot on this? 
 
If the product doesn't offer any protection, perhaps other things we can do to limit our exposure?

The biggest problem with ransomware is that you really cannot remedy the damage. When you have your files encrypted with RSA-1024 you're pretty much screwed. In this case Webroot didn't do a good job. I heard from our customers that signature-based AVs (Kaspersky, Eset) were able to detect this ransomware after about 10 days from the moment it appeared. One of our clients using WSA was infected with it 3 WEEKS after it was reported for the first time. Signatures vs Behavioral Analysis - 1:0. But still I believe in WSA:D

WSA can detect and block Cryptolocker, and if an unknown variant happens to slip through, WSA should be able to roll back the changes as part of the cleanup routine using journalling as long as WSA was installed prior to the files being encrypted. WSA can not decrypt files encrypted by Cryptolocker on a system that was infected prior to WSA being installed. We have improved and continue to improve WSA in order to handle these types of threats.
 
-Dan

Hi Dan,
If Cryptolocker was able to run and encrypted network files, does WSA restore that as well? Also, I've heard of gigabytes and gigabytes of data being encrypted on local and network drive. How does WSA respond to that, when it would never have enough capacity to journal it?

@ wrote:
Hi Dan,
If Cryptolocker was able to run and encrypted network files, does WSA restore that as well? Also, I've heard of gigabytes and gigabytes of data being encrypted on local and network drive. How does WSA respond to that, when it would never have enough capacity to journal it?

WSA currently doesn't reverse the changes on a network drive because of the risk with data loss if another user has changed a file. The best scenario would be to install WSA everywhere, including the system hosting the network drive if possible. Even if gigabytes of data are encrypted, WSA will continue happily journaling it - there will be a limit based on storage space but WSA compresses the data it journals and the storage requirements are limited to how much data is actually on the disk, so it shouldn't dramatically exceed the available storage space. The largest I've seen so far myself was 800MB which WSA restored 100% - it took a while (about 20 minutes during cleanup) but it was all replaced correctly.

Thanks for the answer Joe.
What heuristics or protections does WSA have in place regarding unknown applications making mass changes to network drives?

@ wrote:
Thanks for the answer Joe.
What heuristics or protections does WSA have in place regarding unknown applications making mass changes to network drives?

WSA monitors network drive changes but I don't believe we trigger any upfront block actions on them automatically, due to the legitimate nature of many network-accessing applications (backup tools, other AVs, etc.)

Thanks Joe. I understand. I wish there was another layer of protection, but I can't think of a solution that fits in your product scope.
Regards,
explanoit

@ wrote:
Thanks Joe. I understand. I wish there was another layer of protection, but I can't think of a solution that fits in your product scope.
Regards,
explanoit

I agree, I think there could be room for something to add here but an obvious solution isn't coming to mind immediately, without potentially creating a HIPS-like nightmare of prompts. Happy to take any suggestions if you have some, however. Thanks!

I've thought about it a bit. I think the best way to do this is to set a threshold for files written to over a time period for monitored processes, then send an alert. Unfortunately, WSA reporting is only for detected threats. (:(). Plus Webroot is all about set it and forget it so I'm sure the PMs would shoot it down.
 
My point about this is that network modification of files definitely seems to be your weakspot. And this kind of threat is likely to grow. If I was a Cryptolocker victim, heck yes I would pay them the money.
Customers are expecting your rollback functionality to work regardless of where the changes take place. I had a suspicion this was the case, and it makes sense, but it's still makes me uneasy knowing it for a fact now.
 
There has to be some kind of behavioral heuristics that can be applied, there can't be that many unknown processes out there that start wholesale replacing every file the user has access to on the network share. Frankly, I really don't want any process Webroot doesn't know about touching large numbers of files on network shares anyway.
 
Unfortunately, I can imagine exposing an option to business customers to allow them to chose the sandboxing restrictions isn't a very sexy feature request. So much of what I want improved in the product are deep-management stuff that the majority of even your business customers would be oblivious to.
 
Webroot should make a HIPS extension. It would be the first one ever that doesn't consume 20% CPU.

@ wrote:
WSA can detect and block Cryptolocker, and if an unknown variant happens to slip through, WSA should be able to roll back the changes as part of the cleanup routine using journalling as long as WSA was installed prior to the files being encrypted. WSA can not decrypt files encrypted by Cryptolocker on a system that was infected prior to WSA being installed. We have improved and continue to improve WSA in order to handle these types of threats.
 
-Dan

Hi Dan.
 
I just want to verify that I am reading this correctly, so I can make sure that I cam tell my customers the correct information:
 
If a user is running Webroot, and a variant of the Cryptolocker malware gets past and encrypts their files, as soon as Webroot determines that it is a bad process it will be able to roll back everything including the encrypted files.
 
Is that correct? If so, how does Webroot decrypt the files? Does it store compacted previous versions somewhere or does it actually have the ability to decrypt the files using the data gleened from the initial encryption process?
 
Thanks,
Corey

@ wrote:

@ wrote:
WSA can detect and block Cryptolocker, and if an unknown variant happens to slip through, WSA should be able to roll back the changes as part of the cleanup routine using journalling as long as WSA was installed prior to the files being encrypted. WSA can not decrypt files encrypted by Cryptolocker on a system that was infected prior to WSA being installed. We have improved and continue to improve WSA in order to handle these types of threats.
 
-Dan

Hi Dan.
 
I just want to verify that I am reading this correctly, so I can make sure that I cam tell my customers the correct information:
 
If a user is running Webroot, and a variant of the Cryptolocker malware gets past and encrypts their files, as soon as Webroot determines that it is a bad process it will be able to roll back everything including the encrypted files.
 
Is that correct? If so, how does Webroot decrypt the files? Does it store compacted previous versions somewhere or does it actually have the ability to decrypt the files using the data gleened from the initial encryption process?
 
Thanks,
Corey

You're correct - with its journaling/rollback technology, Webroot stores the clean copy before it is modified by the infection, then it replaces it once it is determined to be bad. This works with any system change, whether it's a registry modification or file deletion/etc.

Thanks for the clarification. That is really good to know as this little piece of malware is staring to cause havoc on some small to mid-scale networks.
 
I read a report from a Carbonite rep that said they are getting thounds of requests per day from users needing restores of their files.

@ wrote:

Also having Webroot SecureAnywhere will protect you from this infection!

Happy, Happy, Happy. Thank you Webroot!  😉

At work over the last couple of weeks we have been seeing quite a few calls regarding this bug.  Nasty Nasty!

 @ do tell.

Was webroot useful in the removal and decryption of the malware infected machine or did you have to do a restore from backup?
 
I still don't get how a webroot could unecrypt an encrypted drive even if the webroot is installed during the infection process.
I mean ok, so the webroot sets the new undiscovered baddie in "Monitor" state, so while in monitor mode the baddie can't access specific files but it's free to go other places and encrypt those, so what happens after its encrypted?  I mean we can't just revert back from encrypted version, we don't know the encryption key we only know the salt (from registry).
 
I don't want any details etc...just paint me sceptical.  Untill I see some comparision or a case study of a webroot protected machine being infected, encrypted, then the malware discovered and the machine recoverd, I will remain high sceptical of any recovery of post infected machine.

@ wrote:
Was webroot useful in the removal and decryption of the malware infected machine or did you have to do a restore from backup?
 
I still don't get how a webroot could unecrypt an encrypted drive even if the webroot is installed during the infection process.
I mean ok, so the webroot sets the new undiscovered baddie in "Monitor" state, so while in monitor mode the baddie can't access specific files but it's free to go other places and encrypt those, so what happens after its encrypted?  I mean we can't just revert back from encrypted version, we don't know the encryption key we only know the salt (from registry).
 
I don't want any details etc...just paint me sceptical.  Untill I see some comparision or a case study of a webroot protected machine being infected, encrypted, then the malware discovered and the machine recoverd, I will remain high sceptical of any recovery of post infected machine.

Webroot does not unencrypt the files - it basically reverts them to their previous (unencrypted) state that they were in before the malware started it's nasty work.

@ 
You can read more here:
http://www.webroot.com/shared/pdf/reinventing-antivirus.pdf
https://community.webroot.com/t5/Webroot-SecureAnywhere-Antivirus/How-exactly-does-Webroot-allow-you-to-restore-files-encrypted-by/m-p/65147#.Unk0HamrRhE
 

We arent seeing as much of the Crypto ransomware as some vendors as generally the infection vector for this has been the same as the FBI infections and we are blocking it before it can even execute. One of the benefits of operating in realtime in the cloud is we can see patterns emerging in realtime and we can go hunting for the malware before it really starts to spread. 
 
I have seen the client roll back the changes before I dont have any case details but I`ll save the next one I see.
 
However if the client is installed after the event there isnt much we can do.
 
My top tips for this infection:
 
Disable/uninstall Java -unless you really need it dont use it (you would be suprised how many sites dont use it anymore)
Use flashblock/Adblock in your browser (noscript is useful too)
Dont open any executable from your email -no exceptions even if the mail is from a friend (I dont touch pdfs/zips either)
If in doubt about a file dont open it and ask us or even google the MD5 
Backups, people seem to have forgotten about this lately
by backups I mean physical ones not online like Skydrive/Googledrive due to the files that get encrypted the changes get pushed to the backups 
 
In order to stop this type of infection we have to stop the incentive of these bad guys which is money. If nobody pays the ransom they will stop and move onto something else.