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!
Page 1 / 2
Userlevel 7
+6
That would be an interesting attack method, force a bluescreen during a WSA cleanup operation to prevent rollback...
Ignoring the full rollback being perhaps broken, they can't extract the data directly/selectively apply it from the DB file for you?
Ignoring the full rollback being perhaps broken, they can't extract the data directly/selectively apply it from the DB file for you?
Given the apparent single try at rolling back it certainly would be effective it seems, particularly given the amount of time it appeared to need in order to roll back, after 12 hrs it did not look like it was even almost done.
This is what I thought as well but we have been harrassing support for about 3 weeks now and the only answer we get is that nothing is recoverable. I mean I wouldnt have thought this to be the case considering we still have the original 2Gb DB file so surely the journalled changes are still recorded and selected data could be rolled back but unless this particular support engineer (Have asked numerous times for it to be escalated but so far Webroot have refused to do this) is very bad at his job this is the case.
We are currently in a worse place than when we were first infected with Cryptolocker as now Webroot has removed the infection we cannot even go to the last resort of actually paying the ransom, thankfully the user was not in his office with network access at the time and it was just a single PC that was compromised!
This is what I thought as well but we have been harrassing support for about 3 weeks now and the only answer we get is that nothing is recoverable. I mean I wouldnt have thought this to be the case considering we still have the original 2Gb DB file so surely the journalled changes are still recorded and selected data could be rolled back but unless this particular support engineer (Have asked numerous times for it to be escalated but so far Webroot have refused to do this) is very bad at his job this is the case.
We are currently in a worse place than when we were first infected with Cryptolocker as now Webroot has removed the infection we cannot even go to the last resort of actually paying the ransom, thankfully the user was not in his office with network access at the time and it was just a single PC that was compromised!
Userlevel 7
+6
That...isnt encouraging...
Userlevel 3
Wondering if you have had any success with Webroot support . Surely rollback ability goes to the heart of the Webroot approach ?
Rocky
Precisely why I have started this thread and have been on their Twitter account, they specifically brag about being able to roll this infection back and yet they were all too ready to bail out as soon as we ran into an infection.
As we knew of Cryptolocker before this PC was infected we called Webroot support as soon as this system was found. We went through it with them and they even had a remote session to the system at one point but unfortunately still no progress - this dates back to a little over a month ago now.
Since starting this thread and also making some noise on the@ Twitter account another engineer has looked over the old ticket and has mentioned the notes say that it may have failed on the initial clean due to lack of RAM (First I had heard of this and theres 8 Gb installed so I'm not really accepting this as a valid reason!) short of that I have no more information now than I did 3 weeks ago :(
On the other hand at least we have found that we can pay ~$2300 to Cryptolocker if we want to try and recover the remaining data....given the time that has been burnt on this going back and forth with support it might be the more economically viable option...Certainly not going to be a big advocate of Webroot in future.
As we knew of Cryptolocker before this PC was infected we called Webroot support as soon as this system was found. We went through it with them and they even had a remote session to the system at one point but unfortunately still no progress - this dates back to a little over a month ago now.
Since starting this thread and also making some noise on the
On the other hand at least we have found that we can pay ~$2300 to Cryptolocker if we want to try and recover the remaining data....given the time that has been burnt on this going back and forth with support it might be the more economically viable option...Certainly not going to be a big advocate of Webroot in future.
Userlevel 7
+6
As a fellow Webroot customer this is worrying to me. As noted, Cryptolocker is a threat WSA is supposed to be uniquely capable of dealing with.
Userlevel 7
+56
Here's the deal - when Cryptolocker found out that we were able to roll back, they started developing counter-attacks specifically against us. Since then it has been an escalating arms race between us and them. This means that depending on the variant that you encounter, you may or may not be able to roll back successfully. In the end the final defense is going to be having good backups, so make sure your backups are working and test them by doing test restores regularly. At the time we were announcing that we could defeat Crytolocker, that info was accurate, but since that is no longer always true then we aren't making that claim anymore. So in the end, layered defense is the key: educate your users on avoiding malware, use anti-virus and anti-malware protection, and have good, tested, backups.
Userlevel 7
+6
Thank you for the information Nic.
I agree with what you say, of course. Was hoping WSA was going to fly under the radar a bit longer for direct mitigations, but, hey, you made it. Congratulations....
I agree with what you say, of course. Was hoping WSA was going to fly under the radar a bit longer for direct mitigations, but, hey, you made it. Congratulations....
Userlevel 7
+56
Sure thing - I'll always give you the straight dope if I know it 🙂 It is indeed flattering to be targeted specifically by malware writers. One of those things that lets you know you've arrived.
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
Would the "outgoing" firewall in WSA not pick up the attempt to dial home ?
Rocky
Userlevel 7
+56
We should have you covered - I don't think you need another AV product instead of or besides Webroot.@ 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
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.
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.
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
+6
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.
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.
No thats fine, ask away - the system is running Windows 7 Pro x64.
Userlevel 7
+56
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@ 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.
Userlevel 7
+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 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.
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:
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 7
+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.
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.
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 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.
Userlevel 7
+6
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?
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 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.
Page 1 / 2
Reply
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.