Solved

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


Userlevel 7
Badge +48
Update April 28, 11:45 a.m. MDT: 
 
Please click here to see the most recent update.
 
 
UPDATE 4/28/17 11:45 a.m. MNT: We have 0 calls in queue on our phone line, and are working through about 80 tickets related to the False Positive repair utility. A good portion of those are simply awaiting customer verification.
 
Please note, the utility was built to address only this specific false positive issue. It will be deactivated in the future. 
 
If applications are operating normally on your systems, you do not need to implement the utility. 
 
If you haven’t yet submitted a support ticket and you need the repair utility, please do so here. Include your phone number as well with the support ticket.
 
Thank you.
 
icon

Best answer by freydrew 26 April 2017, 18:25

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.
View original

289 replies

Userlevel 1
Badge +8
@
 
Sadly enough the music you play on hold is the same that McAfee Support plays on hold.
 
And the really sad thing is that I had to know that...:-(
Userlevel 2
I can report that agent commands are most definitely not "caught up".
@ Agreed - not even close.
 Gotcha. I just see tabs for PC Security, Mobile Security, and Passwords.
Userlevel 2
It's times like this where you wish they had listened to MSPs and understood what real reporting is. 
 
You can't even run a report that says "This is the list of files that were quarantined across your client base in the last 24 hours."
 
And the webroot alerting system is nice enough to disable alerts per site once it reaches a certain "threshold" and just tell you to log onto the console for the site...
Please let us know why facebook is being blocked. I do not care at all if you fix that specific problem today but we need reassurance that this is not a result of a breach with your network that is not under control. I have no problem being patient while your team works late tonight getting everything fixed but your customers deserve to know if there is further risk associated with todays events.
Same here...no agent commands going through.
Userlevel 1
I'll add another vote for GETTING THE CONSOLE AGENT COMMANDS FIXED NOW!
 
As an MSP, this is killing us. It's bad enough to have the false positive. It's even worse to be told "Just restore the file from the quarantine". But it's the WORST to not have the console Agent commands not work.
 
FIX IT! And, while you're at it, write a GLOBAL script that takes ALL the false positive files found in the quarantine AND RESTORE THEM TO THE ORIGINAL LOCATION.
 
Oh, and next time, when something like this happens, WHY DIDN"T YOU NOTIFY YOUR DISTRIBUTORS? I'm already pissed that my distributor didn't notify me. Talk about dumping on your resellers. Shame on you!
 
 
Userlevel 7
Badge +48
@ Webroot has not been breached. Legitimate malicious files are being identified and blocked as normal.  We continue to work on a comprehensive resolution, but a live fix has been released for the Facebook issue and is propagating through to customers now.
 
Still waiting on ANY news for us MSPs with hundreds of systems we would need to restore files on.
 
I would also like to second that comunication to resellers should have been a top priority and the fact that I havent seen an official word on this yet is giving me flash backs to the last major issue that took DAYS to confirm.
Userlevel 7
Badge +48
@ We hear you and are working on it. We will have an update for you as soon as possible. 
Should us MSPs be trying to restore files via the steps posted or hang tight for a better solution?

I would take the minute risk of 1 of the files being quarantined being bad at this rate to have a mass restore on the hundreds that have been flagged.
Userlevel 2
We ended up grabbing the list of clients that were affected and manually going through the steps to whitelist the files and "restore" them from quarantine.
 
We prioritized servers and then did the workstations.
 
Problem being now, that the "restore from quarantine" is still hung on most systems.  Mission critical application executables were recovered from backup.
Userlevel 1
Sounds like Webroot uses the same PR department as United Airlines....
 
Why don't you just let the resellers and MSPs handle the bad press and instead, just TELL us when something has gone terribly wrong. I can't speak for everyone, but my clients and my company REALLY like Weboot. It's a great product. And we're the first line of contact when something goes wrong. We just don't like being the LAST to know.
 
So, make up for the lack of communications by sending us an email tonight, with ALL the details of what happend (Yes, that means CONFESSING TO THE PROBLEM!) and then tell us that you've written that global script and any of the falsely identified programs that were quarantined, have now been restored to their original locations.
Userlevel 1
I managed to get one system moved into the unmanaged policy and restore one file from quarantine.
Which is good.
The file was a scan service which ran our LAN management console and won't stay running.
Which is bad.
The rest of the systems which were hit haven't been able to poll so I have no idea how deep this goes.
 
I don't get paid by the hour and this will be the rest of my week.
 
I tried to find a dumpster fire avatar but it wouldn't let me upload one.
GG Webroot.
Our commands are still not going through the GSM. I've sent them again since informed that they were caught up, but they are still not being processed. We have a 15 minute check in time, so that isn't the issue.
Userlevel 7
Badge +48
@ We are in the process of creating a complete fix, but in the meantime, small business customers can follow instructions posted at the top of the thread to address the issue. 
 
 
Userlevel 7
Badge +48
We are still diligently working to resolve this issue. More updates to come when we have them. 
Userlevel 2
I agree with ATechGuy. I look forward to an e-mail from my MSP Account Manager informing me of the issues and what Webroot plans on resolving this in the future. I like Webroot's product a great deal but I dislike having my clients angry and furious at me for something I had no control over. Also, I would like to know how Webroot is willing to address this in the future for their MSPs. I was in the blind for much of what was going on. I understand that the stress of everything coming on at once but I would have appreciated an e-mail from someone at Webroot so I could pass the information along to my clients. I dislike having to stalk social media sites that I feel should be the responsibility of Webroot to notify me of an issue. If I hadn't rang my POC's phone off the hook, I imagine that I would have been left blind. :(
 
I still have several client computers that aren't fixed. I spent the greater part of my evening trying to at least prioritize workstations and who the manually fix. As an MSP, I have too many endpoints that it's not feasible to remote to all to resolve the issue. I look forward to how Webroot plans on resolving this issue for us MSPs.
We have 2 sites that use webroot and neither site is updating the clients for restore. I have 100's of requests in the Command Log to restore files and they are just sitting at Not Yet Received since 5:30pm EST. Pushing new policy, forcing a refresh configuration and also forcing a refresh via command line mentioned in the original post does nothing.
We suspended several sites to give us time to mitigate this issue, then after unsuspending, they show as expiring.  Do we need to just wait for the system to recover because of all the traffic occuring now?  The sites have been unsuspended for hours.
 
ThePhil
Level 3 Senior Tech
Computer Troubleshooters
I am seeing expired sites as well after suspending and then enabling.
Ditto
Userlevel 7
Badge +48
@ @ @ @ Please contac customer support at 1-866-254-8400 so that they can troubleshoot this further.  
@
 
Our backlog of agent commands is definitely not caught up. I still have thousands of "reverify" and "restore" commands that are "not yet received" and have been for 5 hours. 
 
When can we expect a fix FROM Webroot?

Reply