Solved

A badly indicated False Positive?

  • 24 January 2023
  • 7 replies
  • 94 views

Userlevel 7
Badge +22

So the latest run of Webroot Secure Anywhere flagged a file that I believe is incorrect? 

According to several website, this one included (https://tidbits.com/2022/09/02/macoss-new-xprotect-now-regularly-scans-for-malware/) say that this is a “new”  (around November of 2022)  built in malware protector in MacOS. Seems to me that this should not be flagged as malware?  It flagged it as “MacOS.Lazarus.1.r”


So my question is this: Is this file corrupted with a virus and should be replaced, or is this an error of Webroot? And if it should be replaced, anyone have an idea at how that can be done?

Thanks

icon

Best answer by ChadL 25 January 2023, 20:06

View original

7 replies

Userlevel 5

Hey all,

Couple things to address at it appears the issue @MajorHavoc is having is different from the one @russell.harris is encountering. 

The first issue: If you notice the application resides in the time machine area of the the Mac, we’ve seen this issue before and its due to the way MacOS changes its file locations and information stored on the file while in the time machine. Our current in place methods don’t prevent it from showing as a False Positive. We do have a solution in the works, but in doing so we discovered an Apple MacOS bug that severely degrades performance of both the system and our application. Until that Apple MacOS bug is resolved we can’t implement what we consider to be the long term solution to Apple MRT False Positives. For now, your best bet is to allow the file and move forward, and I apologize for the annoyance of having to do that. But we are working to make sure this detection doesn’t happen in the future. Our Customer Support team might also have some other suggestions on how to mitigate the issue. 

The second issue: Our Agent does currently support localized command line arguments to restore a file based on a SHA or MD5, the issue is that the console side has yet to be enabled yet. I believe they had an internal tooling that they needed to develop that was taking their capacity and time, but I can reach out to them and see what the current timeline is. We are seeing significantly less False Positives on MRT in the field since we implemented our stop gap solution, but clearly there are still some issue with that. As above, once our full solution is in place we expect to no longer see these False Positives pop up. 

Userlevel 2

Thanks for bringing this to my attention, @TylerM! I’ve talked with the team about this and our lead engineer is working on an answer for this.

Userlevel 7
Badge +22

Thanks for a great answer. I will just deal. All good. 

I guess I would have picked it as the solution, but...

@TylerM : I am surprised there was a solution picked to a question I asked? Did  someone else pick it for me? How does that work? I thought the person asking the question was the one who had to pick a solution because they know if it truly answers their question..  No? 

 I would like to make a suggestion: The person asking should be the ONLY person who picks an answer as best answer. After all, they asked, and they should be the one who judges and acknowledges that answer works for them. 

Thanks

Userlevel 7
Badge +22

@Jeremiah Voris  Can you help with this?

 

Userlevel 7
Badge +4

Thanks for the info @ChadL 

I have seen it far less this year than I did before Christmas so fingers crossed.

Userlevel 7
Badge +22

Hey @MajorHavoc 

I appreciate the feedback and suggestion

One of the jobs of admins and mods is to go into topics that have a question and answer them or if there are multiple replies to find the most appropriate answer already posted and mark it best answer. Our community has analytic metrics around how many questions get answered and how quickly. Almost always it is the question asker that picks the best answer selection, but I made an exception for this one. Since this was answered directly by our employee who is working on the product in question and was clearing up that the issue was different than what another community member had mentioned in the thread, I marked it best answer. 

Userlevel 7
Badge +4

I’ve been having this exact issue for a while on Macs running Catalina through to Monterey. When I contacted Webroot support they told me this is a false positive and the only fix is to manually per agent quarantine the threat and allow it in the list. You cant do this centrally through the web admin console which is really annoying so as these come up im having to remote into the Mac and resolve.

I was told this was being looked into but I've been having it for months...

Reply