Cryptolocker/Webroot fail


We recently had a system infected with Cryptolocker, we can see a 2Gb DB file has been generated and attempted to scan/remediate this system. During the cleanup/remediation scan the system blue screened and reset itself, after the reset numerous attempts have been made to complete a remediation scan but nothing happens on completion, Cryptolocker appears to be removed however files remain encrypted. Discussing this with support we have been told as the system crashed during the first attempt it no longer knows where it was at and can no longer roll back any changes. This system was left idle during the initial rollback process and it crashed approx 12Hrs into it so I would say that any crash that occurred was due to the rollback itself! Seems a big claim to say that Webroot can prevent and roll back Cryptolocker when the reality seems to be more like we'll have a crack at rolling it back when our product misses it but when it all goes south you're on your own!

34 replies

Well guys, this morning I downloaded an archive of repaired files from Webroot.....looks like they managed to recover about 90% of the data I would say. The client is verifying the files now and so far it seems good. In the end it has taken something along the lines of 85 days and we did have to ship the laptop over to them for some reason but I guess we were able to get most of the data back, though I'm not entirelyu sure if this should really be called a win.
Userlevel 5
Exactly, done right testing is valuable, done wrong it's a disaster waiting to happen, and WR is reluctant to open itself up to liability by encouraging testing when they can't ensure that the tester is taking the required precautions to test safely.
Userlevel 7
Badge +56
That's exactly right @ - if you know what you are doing then have at it, but we don't want to publicly encourage it or have instructions on our community.
Userlevel 7
Badge +6
There's no problem in testing malware if you're an IT pro and taking precautions.
 
The issue with testing malware which most people don't do is that it really requires a dedicated network segment to keep the infected endpoint away from ever speaking to any clean computers.
Also, there is malware that will infect consumer-grade routers so you have to be careful you're using something that's secure and locked-down.
 
For this reason, Webroot seems to be distancing itself in any way from encouraging malware testing, since they can't guard against people who may think they are qualified to try it. Additionally, people testing malware and making incorrect conclusions is rife.
Userlevel 7
Badge +56
I'm not saying nobody should test, just that we don't recommend it for the general public.  We do our own testing internally of course.
 
If you know what you're doing and you want to test your system with viruses or malware then I can't stop you.  We just don't recommend it and we don't discuss how to do it on our community because we don't want people who don't what they are doing getting themselves in trouble.
Userlevel 2
Badge
I do not agree with that testing is impossibble, otherwise
 
#1: How do Webroot developers test their own technology before selling it?
 
Surely, we are talking about test environments and in such environments it does not matter if you got - as you said - "infect your system deliberately, which has the potential to cause you problems".
 
#2: How did those test organization test Webroot that gave good results at the end?
 
So, after all, it some kind of excuse telling everyone "do not try testing ... bla-bla". Tests have to be done with every product, the question is if Webroot can provide a guideline how to do it.
 
On the other hand, let's not forget I did thorough testing with samples I collected and those tests were just real life execution of different malware. I found that Webroot monitored them first, and then I found that Webroot could not roll back after blocking them. And this was not 1 particular malware but tens of malware. I think I am going to upload the video to Youtube for everyone to see because looks like nobody takes care of this results and nobody givesexplanation what happened in the video and why from Webroot channel... And looks like you just keep telling the same: do not test.
 
But I say: do test!
 
 
Userlevel 7
Badge +56
Well the way to test would be to infect your system deliberately, which has the potential to cause you problems.  It would be like testing out a human vaccination by trying to go get infected with the measles.  Sure you are probably safe, but what if you are the 1 in a 1000 for whom the vaccine didn't work?  Now you've got the measles.
 
Due to traditional anti-virus being definition based, their "tests" involve downloading sample files which aren't viruses, but which have been added to the signature definitions.  It really doesn't tell you anything other than the fact that the anti-virus is running and is recognizing that one sample test file.  We really don't think these tests add anything to your security so we haven't bothered to replicate them for our software.
Userlevel 2
Badge
Why can we mess up our system while testing Webroot? It is not only me but our customers are also very keen on testing every AV they consider to use. How would one decide to trust Webroot if not by testing it? Why cannot Webroot provide the tech guys around the world with testing instructions just as they seemed to provide it for some test labs that Webroot says they do AV testing "in a correct way, not like Virus Bulletin and many others" where Webroot is not a good player on the tests?
Userlevel 7
Badge +56
Thanks for posting back with the update.  I'll keep you updated on what I hear from support.  @ we discourage people from AV testing because you can easily mess up your system - I'd say reach out to support and see whether they can help you out.
Userlevel 5
They will eventually, they typically hold on posting until they have a solid explanation of whats going on. It may take a little time for them to look into the situation if it's something new.
Userlevel 2
Badge
@I get this screen even with the Enterprise version. Recetly I did many real-life tests, downloading some 0-day samples (at least WSA really monitored them so they were 0-day for WSA at least).
 
Experience #1: WSA showed this alert screen which I think is really bad.
 
Experience #2: WSA did not roll back many-many things. Actually, eg. when I started with a downloader app, it downloaded some other and those downloaded even more and more and most of them downloaded again more and WSA monitored each of these but could not remove them. I still have the video of the test, but I do not want to make it public.
 I sent this to ou Webroot rep. but he did not even replied that he got it... 😞
Userlevel 2
Badge
I just wonder if we (users, admins, etc.) will countinue this talk here forever based on experiences, or maybe a Webroot employee would answer the questions thoroughly to us? Are they reading this at all?
Userlevel 7
Badge +6
@ I think his contention is that WSA should be configured to be fail-secure and not fail-deadly. He is totally correct.
 
@ I'm not sure how you're even seeing that screen in an enterprise configuration, I've never seen it on any of my clients, only on the consumer version.
 
Userlevel 5
I could be wrong, (if I am someone who has hung out with the webroot engineers more than me will correct me 😛 ) but that looks like an "unknown," not a "known bad" executable.  Webroot breaks stuff down into 3 categories known good, known bad and "idk wtf you are" where it's something new. If that's the case, webroot is doing exactly what it's supposed to and allowing an unknown to run but giving you the opportunity to block  it and will be generating journeled back ups for any changes the program makes. 
I didn't really want to post an update yet as technically nothing has changed however this is currently with some of the developers being reviewed. From the updates I have seen it appears the journaling is still working correctly but something causes Webroot to hang or go into a loop whilst trying to roll back these changes. From what I have heard the developers seem to be thinking the data will be able to be recovered however I'll post back when I actually have a final outcome.
Userlevel 7
Badge +6
Windows is such an incredibly complex system with so many edge cases, and journaling involves so many things working right, I'm not surprised it's possible. Other vendors have been subject to subversion attacks targeting specific products for years, I guess Webroot is just now getting a taste of it. WSA is apparently some pretty raw C code, which is not very resilient against programmer errors being exploited. All the other vendors are vulnerable, sometimes even allowing privilege escalation, I don't see how WSA would be completely exempt. Luckily they do have a much smaller area to target.
 
The main issue here is that WSA is maintaining journaling data in some kind of format where the very developers themselves can't read it? They can't find a single file in the whole thing? I'm fully aware of differencing and other compression/storage methods, but that seems a little strange. Or was Cryptolocker doing the modifications behind the hooks that WSA uses, so it was just journaling encrypted data?
 
I doubt they will be very forthcoming with specific details, it doesn't really help them any discussing what they know publicly for malware authors to read. The apparent forced BSoD in this case was possibly a trick they figured out to throw a wrench in WSA operations somehow.
 
I'm just a stupid sysadmin, not a coder, so it's completely possible I'm full of it and have no idea what I'm talking about here.
Userlevel 2
Badge
Hi All,
 
I am also very much surprised readind through this thread now. I was always believing that journaling and rollback was meant to be something that malware could not trick. I really wonder what could be the real issue with the Webroot software because if we experience that one malware could trick it today then we absolutely cannot be sure this technology will work with other new threats.
 
Can anyone explain how could a malware stop WSA journaling?
 
Maybe, if automatic rollback would not even work (that I could imagine better in rare cases) but I still would like to believe that journaling should always do its job good and that in worse case Webroot could do the rollback manually for us. If not, then really, how can we trust Webroot's unique technology anymore? The things I read here are degrading WSA to the effectiveness of any AV in the world.
 
I am very much frustrated becuase we are just in the middle of preparing big marketing campaigns in our country through lots of marketing channels (facebook, TV, email, news sites, etc.) and the main marketing message would be that Webroot's journalling and rollback technology can cure everything, all zero-days and even Cryptolocker-like malware infections. Now I have big doubts if we should run the campaings at all??? Hmmm.
 
------------
 
On the other hand, taking a look at the issue technically: we all know the heart of all modern malware is to communicate with its control center (CC). If Webroot would block any network communication for unknown processes that would protect us. I think this is the main thing to focus on. Even APTs rely on communications to the CCs. This has to be the first and main thing to block. Cryptolocker cannot do its encyrpting job without communication to the CC either. Do I feel that a really good personal firewall performs better than an AV? If I were the Webroot development director, I would focus on doing this job the best first and then journaling and rollback. Show me a modern malware that would do its job without network communication!
 
And actually, I found a very bad default setting in WSA as well. I already told our Webroot rep. some time ago that it is a very big mistake (at least in the consumer version for sure it is like this) when you get an alert about a new unknown process trying to to connect to the network and the alert window counts down 120 sec and the default is to allow after 120 sec. So what if I have to go to the 2nd door just that time? Or I left for lunch or to my boss? Or I do not know what to do (allow/block) and I call the IT guys? Well, WSA defaults to allow the connection! Absolutely unsafe default action! (Not to mention, nothing happened so far, you can check it for yourselves.)
 
Here's the screenshot I am talking about:
 

Userlevel 5
Not surprised, that's how this kind of thing typically works, the bad guys are going to do what they can to keep their program working.
Userlevel 7
Badge +56
Just a quick update to let anyone who is following this thread know that our threat research team is still working on this issue to figure out what happened so that we can address it in the future.
Userlevel 7
Badge +56
@ wrote:
@ @,
 
With all due respect, I think this shows very clearly that Webroot does not have us covered - the infection was not blocked nor able to be rolled back (Mustve missed the memo about Webroot no longer being able to do this as there are still plenty of references to ~4 or 5 months ago that say you can and nothing official that says you now cannot that i've found!) In fact had Webroot not been installed we wouldve been much better off time wise, wouldnt have burnt ~20 hrs with support and if the client ends up paying the ransom then they'd have been much better off doing it initially instead of after this waste of time and having to pay the higher amount, an argument could most certainly be made that had we been using Trend etc. we'd have the same net result but would've got to this point a lot quicker and recovered the data cheaper.
 
As a MSP provider I am now VERY concerned for our other clients using this AV, basically from what you have just alluded to they are completely open to infection by Cryptolocker and should be relying on backups - thats fine long term but recovering a few terrabytes of data for a file server is not a quick process. Surely this is not that hard to detect, a file that tries to encrypt all documents on your system doesnt really sound legit and I wouldve thought behaviour analytics could detect that pretty easily...sure we wouldnt be able to save all documents but at least we'd still have some.

I agree with you and I'm sorry that you had to go through this.  Part of the problem is that we're using the same name "Cryptolocker" for a couple different versions of malware.  It isn't like the authors of the malware put version numbers on their software 🙂  So we can't say "we protect against Cryptolocker versions 1.5 through 2.7, but not versions 3.0+"  I also agree that we should have been more upfront about the recent versions being harder to combat.  We are doing our very best to stay up to date with the most recent exploits and versions of Cryptolocker, but we can't guarantee 100% protection any more than any other AV product can.  The folks writing the malware have gotten pretty damn sophisticated so it isn't a trivial problem to solve, unfortunately.  I second what @ suggested about talking to your account manager.  
Cheers @ we have brought them in and I think they have asked for some senior people to look into this but I'm trying to keep as many avenues open as possible in the hopes that someone comes through with some breakthrough answer.
 
No thats fine, ask away - the system is running Windows 7 Pro x64.
Userlevel 7
Badge +6
@ I hear you. I would recommend  take this to your account manager. We've found ours very receptive and a good way to get connected to resources within the company, though it's never been in this sort of regard. Other than that I'm not sure what to do. I do appreciate you sharing this so we're aware. I have recommended Webroot with information on their protection against Cryptolocker-like threats.
I know that's not much help and I can imagine the situation you're in with your customer. 
 
Also, can I ask what OS was this computer running? This is in no way pushing it back onto you, it's a purely technical question as the OS hooks between XP/Vista+ are different.
Hi@nic,
 
With all due respect, I think this shows very clearly that Webroot does not have us covered - the infection was not blocked nor able to be rolled back (Mustve missed the memo about Webroot no longer being able to do this as there are still plenty of references to ~4 or 5 months ago that say you can and nothing official that says you now cannot that i've found!) In fact had Webroot not been installed we wouldve been much better off time wise, wouldnt have burnt ~20 hrs with support and if the client ends up paying the ransom then they'd have been much better off doing it initially instead of after this waste of time and having to pay the higher amount, an argument could most certainly be made that had we been using Trend etc. we'd have the same net result but would've got to this point a lot quicker and recovered the data cheaper.
 
As a MSP provider I am now VERY concerned for our other clients using this AV, basically from what you have just alluded to they are completely open to infection by Cryptolocker and should be relying on backups - thats fine long term but recovering a few terrabytes of data for a file server is not a quick process. Surely this is not that hard to detect, a file that tries to encrypt all documents on your system doesnt really sound legit and I wouldve thought behaviour analytics could detect that pretty easily...sure we wouldnt be able to save all documents but at least we'd still have some.
Userlevel 7
Badge +56
@ wrote:
Thanks Nic for the upfront explanation. Are you saying that we should use traditional AV as well as Webroot ?
 
Would the "outgoing" firewall in WSA not pick up the attempt to dial home ?
 
Rocky
We should have you covered - I don't think you need another AV product instead of or besides Webroot.  
 
As to the attempt to dial home, that's part of the behavioral analysis that we continually try to catch as part of the arms race with Cryptolocker.  The malware writers can get pretty clever about disguising that traffic as something else, which is why we have to continually tweak our software to catch that.
Userlevel 3
Thanks Nic for the upfront explanation. Are you saying that we should use traditional AV as well as Webroot ?
 
Would the "outgoing" firewall in WSA not pick up the attempt to dial home ?
 
Rocky

Reply