W32.Trojan.Gen. False Positive Fix - April 24

Show first post

289 replies

Userlevel 1
Boy there were a lot of failures and weaknesses shown with this event.  Authenticode catalogs not honored, C&C overwhelmed, no notification to users and QC inadeqacies.  I hope webroot takes this wakeup call VERY seriously and makes these shortcomings their top priority.  No more features until this is addressed.
Userlevel 5
Webroot will run the automated agent command approach. But as I said it will take time to reach all endpoints. If you have critical business apps that need immediate attention, then using a local approach will be best. To the extent you can, insure your endpoints are online so commands can be received. 
More news shortly. I am working multiple threads so I may not respond instantly.
I have had a few client machines where registry settings were quarantined along with files.
The web dashboard only showed a few of the files affected, but no registry entries.  Most had a long list of files and registry settings that were flagged and quarantined shown on the local workstation interface.  I had to manually recover all affected files and registry settings using an unmanaged policy.
If you had files quarantined and you have remote access or competent end-users, you might also want to check the local quarantine list for any registry settings that might have been flagged.  I know this is late notice, but it might be useful if programs no longer worked, even after quarantine recovery.
Hopefully Webroot will take the registry settings quarantines into consideration in their "fix".
Good luck!!
Userlevel 2
Badge +7
Will webroot be running the automated fix for quarantine themselves, or will we need to initiate it?
Userlevel 5
Endpoints that were not affected will not be affected. THe files that were mistakenly marked bad have been re-marked good.
After following the instructions on the screen for one server, 2 hours later, the files got restored. So there is still a backlog with agent commands now.
@ can you confirm that any endpoints not currently effected will remain so?
Page 1 solution still does not work.
even uninstall command from web console does not work, its been 1 hours since i tried to uninstall, none of the clients are uninstalling,
@ evidently you don't read all the comments that point out the steps here don't help much when the console shows that the endpoints seem to be sitting with the 'Not Received' message.  Doesn't seem like much of a help to give instructions that are taking so many hours to undo this issue.
@and @
We're seeing the exact same problem. Since the Web Console is stuck not doing anything, we tried releasing files locally, only to find that Webroot says it is centrally managed and this cannot be done locally.
Setting the agent to unmanaged seems to work, but this is not a solution. Why can we not seem to change this anywhere in the global policy?
Userlevel 5
Hello again
We have identified an automated approach to removing files from quarantine. But it will take time to reach all endpoints. A more detailed statement is being emailed to GSM Admins within the next few minutes It will also be posted here. In the meantime you should continue with your own remediation steps (which can be found on Webroot support or at the top of this thread.) I will jump back on here shortly. 
Mike Malloy
Userlevel 1
Dear @,
We've found that if you set the affect computers with an Unmanaged policy, and then have the user "Refresh Configuration" (by right-clicking the green W icon) it will pull the policy from the console. Once that takes effect (usually about ten seconds) you can then enter the UI and restore the items from quarantine.
FWIW, We still were having detections happening this morning, and have had to shutdown protection completely on various companies in order for them to get their production orders out.
We are not able to restore Quarantined files now from the Agent on the desktop.  Its reporting back as controled by the  Webroot Console.  But with the Webroot system queue being overwhelmed it's not restoring from the Console.  We can't find in the policy to enable client use of Quarantine.  But even if we change that, the policy will take forever to propagate out, or never. Can you help?
Userlevel 1
Your steps are probably right, providing things are working as they should.
Of all my client sites, only one was affected severely, but it was (still is) a nightmare.
I was sent these instructions severals times last night, and followed them to restore about 435 quarantined .exe files.   I have a manufacturing facility's entire engineering department shut down today, and these steps aren't helping much.  It has worked for some files, but others are still logged as "Not received" inthe logs.
Luckily, I have a great contact onsite, and he is working at manually finding copies of the .exe files and pasting them into place and so on.    A long and tedious process.
Webroot was sold to me as a product that could reverse such issues with a few clicks - nice how I wasn't told that they meant a few clicks per affected machine (or that this might not even work)!
While I agree that comms is super important and lacking the bigger issue is that this may have been avoided.  This assumes the problem was as noted in this post:
It seems likely, but even if not I can't understand why webroot hasn't addressed authenticode.
Userlevel 2
I think I speak for all MSPs on here wanting more communication from Webroot. I am pretty sure you could easily setup a spam list (mailing list) we can all sign up to for critical issue alerts.
 If you don't know how to set one of those up I bet I can find a few IT guys on here that can gladly help with this.
We know mistakes happen and most of us although are very pissed off still remain loyal because over all its a good product. But the lack of communication is unbelievable!
I hope that you are coming with a solution PDQ.
I have to assume that Webroot has a MAJOR Q/C problem.  If after 13min an update like this can cause the kind of damage it has accross my 5600 seats it COULD NOT HAVE BEEN properly Q/Ced.   WebRoot please before you release another update on your "partners" release it on your internal systems.  Also your communication has been horrible.  
Userlevel 1
Dear @,
I think it's time to put away the "Web Threat Shield Update" link and put up "HOW WE SCREWED UP Update" link instead. Over time, perhaps it could be renamed to "False Positive 4/24 issue update"
Sadly, your posting added no value, as there are no actionable comments you made. 
I'm not sure if I feel any better that not only did your company fail to alerts the MSPs, it also failed to alert the distributors, so they didn't have a chance to communicate the problem to us.
I've worked with several.  Overall I have had less problems with webroot than others and fewer infections.  But this... this is a crippling flaw and has gone unaddressed, it seems, for almost a year after being discovered.
This is a PR nightmare, the lack of communication is upsurd. My technicians, project managers, and developers have been up all night on this and they still have not slept. We are an MSP and I am the people side of our company, when I recieved the call from our techs yesterday evening they said we are on it and we will send you an email when we know more. I got an email around midnight tell us what had happened. When I started getting calls from directors and owners this morning asking if something had happened we were very transparent with our clients. The situation was company wide but we have the best techs that were able to resolve the issues overnight for most places. We did replace some hardware however $$$$$. We will be filing for compensation for this. From the business side this is unacceptable, this cannot happen I called our owner this morning. We have been very happy uptil now with WR, but this most likely will affect our bottomline and that cannot be remeded with we are sorry. We are going to need more!  
Userlevel 1
We had to uninstall webroot from 4 more servers this morning because whitelists were being ignored and preventing some .exe's from running. NOT FIXED.
Userlevel 1
I have never loved working with them. From taking 6 months to solve an issue with terminal servers, to this.
^^^This.  I saw the report last year.
The fact this was left unaddressed is not acceptable.  I'd like webroot to explain their reason for not fixing this.  
Overall I have loved working with webroot and fortunately we had no endpoints effected by this problem yesterday, but this may be a dealbreaker.