Solved

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



Show first post

289 replies

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.
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 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.
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 7
Badge +48
@ We hear you and are working on it. We will have an update for you as soon as possible. 
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
@ 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.
 
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!
 
 
Same here...no agent commands going through.
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.
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...
 Gotcha. I just see tabs for PC Security, Mobile Security, and Passwords.
@ Agreed - not even close.
Userlevel 2
I can report that agent commands are most definitely not "caught up".
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 7
Badge +48
@ We hear you and are working on this as fast as we can. We will update you as soon as we have more information. 
 
Happy to hear you like our hold music. We don't want to put you to sleep. 
Userlevel 7
Badge +48
@ Operations only caught up the agent command queue. Other databases are still processing and catching up. 
Userlevel 1
So if setting allow policies on files we know are good that have been trashed in this issue, then forcing the clients to poll for the updated policies, does not then subsequently restore those good files from Quarantine this is yet another feature that should be available within the console.  We should be able to say that caseware.exe or whatever needs to be "un-quarantined" at all sites. Then it should show all endpoints that have this quarantine and we could even manually check/uncheck if we wanted to, and apply.
This entire event is unacceptable and we have already had several long internal conversations about what is obviously a serious flaw in cloud console based antivirus software. The solution to our current dilema "could" be easy to impliment if it wasn't for the fact that every single webroot customer is trying to fix their computers at the same time. Since all customers have no direct or local method of managing their webroot deployment we must rely on the cloud console to do anything and all of our workarounds have been queued up pending deployment all afternoon. 
 
I do feel that I must point out that this problem exists with all cloud managed software and as a result we will be carefully weighing the pros and cons as a result of this. In the mean time everyone needs to realize that Webroot has been a great product with very few problems in contrast to many other platforms. With that said, how they react and manage communications will define our response and the net loss in revenue they experience overall. There is no way any company could manage direct communication during a disaster that affects 100% of their customers but this forum thread appears to still be the only direct communication and it is very lacking and the updates are too infrequent. 
 
This Facebook blocking symptom that only started shortly ago has yet to be acknowledged and if it does turn out that there has been a security breach at Webroot and PR has taken control of official responses we will be departing immediately trust with customers is a requirement with any vendor in security related markets. 
 
Webroot Staff: Please make communcations a priority, even if you don't have something new to share as we are all pressing refresh on this forum over and over while listening to your hold music........ Thankfully its pleasant.
Userlevel 7
Badge +48
For those that reported that agent commands were not working or were very delayed,
that backlog of requests has processed and we are told that it has caught up.
 
For anyone that had failures, please try again.
Hi, is there an ETA on the resolution? When I call into support, we get a message that says the issue has been resolved but is that really the case? Next, if it is, what is the solution to restore all these files?
 
@ When the commands actually start going through, are we going to be able to see the data on which files were removed? At the moment a bunch of the machines have no data....
Userlevel 7
Badge +48
@ It will not. 
Ok so i got a few of my clients to restore but now the software that im restoring the exe of is shutting down every 1 to 2 min? any recommendations?
Useless Admins giving kudos to useless OP.

These fixes don't work.

Reply