Solved

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



Show first post

289 replies

Userlevel 5
Yes you can deploy the tool using the Download and Run a File agent command from the WSA console or by using any other deployment method that you may use.
Mike
@
 
If this tool is an .exe file and hosted at a url, wouldn't it be easy enough to actually use the webroot console to "download and run a file" from the 'Agent Commands option - Advanced' in the endpoints list rather than using a separate interface? Seems like Webroot employees would recommend that over using a script or RMM tool to push it to endpoints. One to one contact in the interface that is affected would be much easier for the person fixing the problem.

I have used the "Download and run a file" with great success with shared google drive files (with direct download link conversion). However, it doesn't work if you select a full page of hosts and check the 'send to all pages' option. It also doesn't work with an .msi file. I use msi2exe to convert the file.
Userlevel 5
I hear you. There is not a problem deploying across both affected and unaffected machines.
Mike
Userlevel 1
Is there a full explaination as to what this "Fix" does?

It moves the quarantined files back into their proper folders, what about systems which we've manually restored quarantined files already but the agent is unresponsive to the cloud?

What else does this fix do?
@ Would it be ok if we run it on all machines though? We aren't certain which are afffected or not so it would be a hassle to sort through thousands to figure out which are affected if we could just run it everywhere without any issues.
Userlevel 5
Just the affected ones will benefit from the tool because its specifically designed to move the affected files back into the right folders. 
Mike
Userlevel 2
@
 
All endpoints or just the effected ones? We lucked out on some clients and have not had the issue, others we have manually fixed and some still struggling.
 
Thanks
Userlevel 5
Hi When you get the tool from support, plan to push it out to your endpoints and it will execute automatically. It will restore files from this incident to their original locations. So you should plan to use a script or your RMM tool to push it to endpoints. 
Mike
Userlevel 2
But I am over an hour already...... Can you respond on other questions? I also posted those to the ticket as well. Just wanting some clarification.
Userlevel 7
Badge +48
@ Just talked with support and we're seeing an average response time of one hour. 
Userlevel 2
@
 
Can you tell us as MSP's officially what is the plan for this utility? Do we need to run it on every client? Or just infected clients? what about clients we seem to have fixed and stabalized?
 
Just trying to make a plan of attack for our team. Thanks for any input you can give. Also how long before support ticket gets answered?
 
Appreciate all that you guys are doing.
Userlevel 7
Badge +48
It is not our intention to be deceptive. We want to work with customers still being affected by this issue on an individual level to make sure that the issue is completely resolved.
 
If those customers and partners can notify us via a support ticket, that is the fastest way for us to identify and assist them. We are happy to submit a ticket on your behalf if that would be helpful. 
Userlevel 2
@
 
Do we know how long it will take them to respond to support tickets for the Utillity?
Userlevel 7
Badge +35
@ we will get a letter for our SMBs shortly and post a link to it here.
That is the one focused for MSPs... I'm not a MSP.  
Userlevel 1
@ A letter was posted here:

http://images.saas.webroot.com/Web/Webroot/%7B70bbf60f-4ea4-40d7-a427-38593a613e93%7D_WebrootIncidentResponseLetter.pdf
Userlevel 2
@
 
I believe you can use this one
http://images.saas.webroot.com/Web/Webroot/%7B70bbf60f-4ea4-40d7-a427-38593a613e93%7D_WebrootIncidentResponseLetter.pdf
 
Any update on an official letter for businesses that can be shared with executives?  
 
Thanks!
Userlevel 2
Are you serious webroot? As if we didn't wait for hours monday trying to get in on your support phone line and getting a ticket submitted via the completely non funcitonal GSM portal before finally giving up. Now that you finally have a fix you make us come and grovel for it?
 
I'm sure you will have some excuse like you need to track the number of people that need it or something, just put a **bleep** download counter on it and post it publicly. The world already knows about your screw-up, being shady about it now is not helping your case to keep your existing clients, and that is what I'm sure this is really about is making sure that we contact you so that you can send us to the retention department because you know about every MSP out there is scrambling to test other options right now.
 
Want to mitigate the customer loss? Own your screw up, don't minimize it with this "13 minutes" BS that you are trying to spread as if that makes it better, it's been an ongoing issue for us and our clients for days now.
 
Tell us what you are going to do to be better in the future. This is at least the 3rd major screw up from webroot in the past year, and some of them like the terminal server issues are still ongoing but webroot lost interest in fixing them. No updates have been released for the agents in the past 6 months, oh except that one that broke everything and had to be rereleased with rolled back code.
 
We want to know what the heck is going on at webroot and be convinced why we shouldn't change vendors, because we are losing clients because of you, and no I don't want to call you and ask for the privilege of lip service, it needs to be public and it needs to include an actual apology from the people in charge and a plan for turning the ship around.
Userlevel 2
I would third that, many of us MSP's use a management and monitoring program and could easily use scripts to better service our clients.
Userlevel 5
Badge +24
@ wrote:
Some of the ability is already there like requesting a checkin with the console. They just need to expand on it and maybe add a CMD interface.
I agree.  If Webroot had a documented commandline set of switches and options, it would make life much easier for MSPs; we could issue scripted commands immediately to machines.
Userlevel 5
Badge +24
@ wrote:
Can anyone offer suggestions for a computer that has been almost completely disabled by these false positives? I cannot boot to safe mode or safe mode with networking to performing any of the gui-based fixes. sfc /scannow via windows 10 startup troubleshooting is unsuccessful. I was able to capture the dlb.db file from the broken laptop's hard drive (per tech support's instructions) and load it on an unmanaged webroot endpoint to view all of the files that were quarantined. The list has got to be 200-300 items long and is 95% registry entries. How can I get this broken laptop working again? Support has suggested various fixes (none of which have worked) but has also stated that these fixes don't apply to the registry files that were incorrectly quarantined. Help!
Have you tried booting from recovery media or into Recovery mode and using System Restore to go back to an earlier time?
 
That's about the only option I can think of that you have.
Userlevel 2
Ticket created 85277
Userlevel 7
Badge +48
UPDATE: April 26, 2017
 
In addition to the manual fix issued Monday, April 24, we have now issued a standalone repair utility that provides a streamlined fix for business customers. It will release and restore quarantined applications to working order on the impacted endpoints. 
 
For access to the repair utility, customers should open a support ticket, or reply to your existing support ticket related to this issue.  Please include your phone number within the support ticket.
 
Our sincerest thanks to the MSP beta customers who worked with us to test and validate this repair. We appreciate the support of our customers and thank you for your patience.
Userlevel 2
Will you post here or on other thread or both?

Thanks for the updates! Still having command issues from Console, We have also found that if machine is left on and programs open they don't get RE-Quarantined.

However as soon as a restart comes through it rescans and re-quarantines

Reply