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

Show first post

289 replies

We already tried putting the agent into an unmanaged policy and although it did alow us try attempt to restore the files, the files never were restored, and then shortly after the quarantine list went blank.  We are now restoring to reinstalling all of the applications manually :-(  Hoping we are going to see a credit on this month's Webroot invoice!
Userlevel 7
Badge +48
We have word that the console is overloaded and not processing the backlog of requests as quickly as we’d like so the most affective way to restore these files is locally via the agent but the agent must first be put into an unmanaged policy, the agent must poll to change its policy, then the user/admin can restore the files from quarantine. We recommend starting with the most critical first.
Userlevel 1
Badge +8
When I try to go to AntiMalware Tools and Restore File, if I put in the MD5 hash it tells me the hash is invalid.
Userlevel 1
Yeah, you may be able to restore from quarantine in the cloud, otherwise you need to change the policy of the agent(s) to something like unmanaged (that's the only one we have that allows for client-side changes via captcha).  Cloud process:
  1. Click on the Site that "Needs Attention" (never understood why it still needs attention if the files have been quarantined).
  2. Click on the left "x Endpoints need attention" hyperlink to the endpoint.
  3. Click on the endpoint in the popup window.
  4. Select the files you need restored from quarantine.
  5. Click Restore from Quarantine.
That's a lot of steps to fix this issue on so many computers it has affected though.
So far, we have found that uninstalling Webroot and then restoring the files from the backup solution and then re adding Webroot....they haven't seem to requarantined
Haven't gotten a release from quarantine or restore file via MD5 to work at all .
I sure hope the Webroot general restore from quaratine back to clients fixes the multiple of other clients we are seeing.
Is there a solution to manually restore the files locally and how do you do that?
Userlevel 2
I work for an MSP. This is greatly hurting over all of my users. I've run the reverification but it's reporting as not yet received. Is there a way that I can throw all of these end points to a new policy where I can just release the items from the quarantine besides doing it through the console? I can switch the policies without issue but I can't get any of the commands to work. 
Ok the fixes are not working or not restoring the files quick enough. Is there anyother solutions? Can someone please send the instructions on how to find the MD5 file or how to get it into the restore?
Userlevel 7
@ There is no real documented command-line interface for Webroot, unfortunately.
Userlevel 2
Is there a way to restore the files from the command prompt on the users computer? It would be awesome if we could quickly write a script in our RMM and push it down tot he clients to restore the files.
How are you guys restoring the files from quarantine manually?  I don't have that option it says that it's "SecureAnywhere is currently managed by the Web Console...." when I try manually restore a file from the quarantine on a system
Userlevel 1
Now the quarantines in the cloud console are empty so I have to restore everything manually. Webroot is now on its way out of all my client machines. Last **bleep**ing straw.
Userlevel 7
Hello Drew,
Respectfully, circutbreakers are not adequate safeguards.
A safeguard is having a client that can authenticode verify files as being from Microsoft and whitelisting them. It's completely, utterly unacceptable that in 2017 you could quarantine a file signed by Microsoft's root authority. This is a glaring issue.
In fact, I submitted product feedback about this omission last year, warning that this would happen without enforced system file whitelisting. I was seemingly ignored.
You can read that feedback here: https:///t5/Webroot-SecureAnywhere-Antivirus/Product-defect-Critical-oversight-in-file-signing-via-catalog/m-p/259299#M26248
(EDIT for clarification: Note this specific recommendation would have only prevented the issues with Windows 10 Insider Preview)
Webroot's product team needs to go back to the basics of the product and review fundemental protections other vendors implement.
I tell people in my professional circles that I mostly approve of your product and quality control. This is not okay. And this isn't one person's fault, or just human error. Humans make mistakes. I make stupid mistakes and have bad judgement. But systems are supposed to be designed so those mistakes are mitigated.
Userlevel 2
manual restores are not processing, is there an ETA to the fix being pushed on your end?
Where should my company send the bill for all the time we've lost fixing this issue for our clients? Multiple core processors taken down across multiple banks and financial institutions is a very big deal.
Userlevel 1
I really wish we had more control at the endpoint to manage via passcode or what not. The cloud is great and all until something like this happens. If we had full control locally as well this could be resolved very quickly.
We are an MSP and this is causing us serious issues.  We have files that appear to be deleted, not quarantined as a result of this issue.  GSM does not show our missing files as quarantined and logs show nothing either.  I think it's quite a coincidence that files mysteriously are deleted. 

We are facing having to restore to previous day and lose entire day's work for multiple clients.  Anyone else seeing a better way to address this problem on a global scale to recover/restore files.
This is costing us lots of time and resources to deal with.  Could use some positive fixes.
I too have had no luck with restores. Even if I refresh the Webroot agent itself. I think I've seen a couple 0KB files show up in place of the ones that were deleted. Maybe the system is just taking a long time to process. 
Userlevel 2
When sending the "restore from quarantine" command - the command log is listing "Not yet received" - even though we have refreshed the Webroot configuration multiple times..
Thanks freydrew.

However what about restoring files when the listed MD5 method is not working?
Userlevel 1
Not trying to be rude or inconsiderate, but isn't 13 minutes a long time? Your monitoring must have seen a huge spike in the first few minutes as I am still receiving emails that have been from an hour ago. I would definitely look more into safeguards. Feeling very frustrated here.
FYI for everyone: A reboot may be required to get the restored files to work properly after they have been restored.  We've been white listing as many things as possible, but the list is LONG! 
Userlevel 7
Badge +48
The rule that caused this issue was live for 13 minutes before it was caught by our in-built safeguards. The result has been to mark files as trojans false positives. The rule was removed and we are in the process of rolling back all of the false positives that reside in the Webroot Threat Intelligence platform. Once this is achieved, the agent should pick up the re-determinations. Because the rule has stopped, no other endpoints should be affected by this issue. 
As you can imagine, we are all working hard at finding the best resolution for this issue. 
I get the following error when trying to restore a file via MD5... 

Userlevel 1
Even small businesses need a better solution....doing this over and over is very time consuming.