Solved

Mac Xprotect Remediator MRT v3

  • 15 March 2022
  • 39 replies
  • 11642 views

Userlevel 3
Badge +11

Just updated to Mac Monterey 12.3 yesterday, and Webroot 9.5.0.139 detects Xprotect Remediator MRT v3 as Keylogger.Refog.1.r.

 

Can anyone verify this, please?

Thanks.

icon

Best answer by ChadL 22 March 2022, 00:11

View original

39 replies

Userlevel 7
Badge +4

I need to roll out Monterey updates soon to clients, wonder if if should wait now based on this?

Userlevel 7
Badge +63

Thanks Chad! 😎

Userlevel 5

@WaltDittrich 
If you go here 

Then here: 
 

You should see a window like this: 

This is also a reliable way of viewing the version number and subsequent definitions number. Are you by any chance on a managed computer? 

Userlevel 7
Badge +63

Thank you, TripleHelix,

It simply shows the version number:
 

However, as of today, the false positive error is no longer appearing, so I guess I’m good. 👍

 

Thank you!

I don’t know the Mac client very well maybe @ChadL can explain. Can you also tell us which version of the Mac OS you are using?

 

Thanks,

Thank you, TripleHelix,

It simply shows the version number:
 

However, as of today, the false positive error is no longer appearing, so I guess I’m good. 👍

 

Thank you!

Userlevel 7
Badge +63

Hello @WaltDittrich 

 

I don’t use the Mac version but if you look at the product version then the last 4 digits would show the definition update version under my account in the UI! Something like this: 9.5.0.139:1623 or a higher number.

 

https://docs.webroot.com/us/en/home/wsa_mac_userguide/wsa_mac_userguide.htm#ManagingYourAccount/ViewingYourAccountDetails.htm

 

HTH,

I wonder where one could see what version definitions set they have?
I see 1623 is the up-to-date version, but where can I tell I have it?
 

I suppose simply by restarting the computer and/or Webroot SecureAnywhere program, that should load the update. Also, if I’m not getting the false positive, that, too, would let me know.
I just want to be 100% sure. 🙂

Userlevel 2

 

The problem with 1000s of end users reporting same problem is it take resources away from solving the problems.  Reporting this method  is more efficient, but it is sad that a little time couldn’t be taken to: develop and proactively publish an intermediate fix to all users; provide status update here and to all users at Noon and COB each day. 

 

Not really support takes the info in and they share with Development and then QA and in this case @ChadL said they pushed out a new definition set “1623 contains the exclusions for MRT v3” that will solve this issue. 

Setting aside Webroot Mac team should have been on top of this before 12.3 was released, Webroot needs an experienced Lean Six Sigma process person who is empowered to makes changes that improve customer experience.  So often Webroot is slow to respond when prior planing would have proactively fixed the problem

Userlevel 7
Badge +22

Good news everyone,

 

There was an issue with our definitions being published properly, but that has been resolved. The latest definitions of 1623 contains the exclusions for MRT v3 and your agents should receive the updates automatically. On the next scan you should not see the MRT v3 being shown as a threat so long as you didn’t take action to quarantine the item. Let me know if you see any other issues.

We apologize for the delay in getting this out and we’re actively having conversations on how to improve this pipeline to minimize delays. As with all things, improvements take time, but we are doing our best to meet and exceed your expectations and I appreciate your feedback in helping us improve our product for you. 

Thanks Chad

Userlevel 7
Badge +63

 

The problem with 1000s of end users reporting same problem is it take resources away from solving the problems.  Reporting this method  is more efficient, but it is sad that a little time couldn’t be taken to: develop and proactively publish an intermediate fix to all users; provide status update here and to all users at Noon and COB each day. 

 

Not really support takes the info in and they share with Development and then QA and in this case @ChadL said they pushed out a new definition set “1623 contains the exclusions for MRT v3” that will solve this issue. 

Userlevel 2

Hello everyone!

 

Sorry about the continued issues and I will ping some Webroot Staff. @ChadL  @TylerM  @khumphrey 

 

Has anyone contacted Webroot support?

 

For Consumers:

Webroot Support:

Submit a ticket

Call 1-866-612-4227

 

 

For Business:

Submit a Ticket

CALL US
1-866-254-8400

 

Sorry again.

The problem with 1000s of end users reporting same problem is it take resources away from solving the problems.  Reporting this method  is more efficient, but it is sad that a little time couldn’t be taken to: develop and proactively publish an intermediate fix to all users; provide status update here and to all users at Noon and COB each day. 

Userlevel 5

Good news everyone,

 

There was an issue with our definitions being published properly, but that has been resolved. The latest definitions of 1623 contains the exclusions for MRT v3 and your agents should receive the updates automatically. On the next scan you should not see the MRT v3 being shown as a threat so long as you didn’t take action to quarantine the item. Let me know if you see any other issues.

We apologize for the delay in getting this out and we’re actively having conversations on how to improve this pipeline to minimize delays. As with all things, improvements take time, but we are doing our best to meet and exceed your expectations and I appreciate your feedback in helping us improve our product for you. 

Not sure what to do about this! Reading all the updates above on this thread and don't see an end in sight on the resolution and ETA for the updated fix or new protection file to avoid what apparently Webroot is blaming Apple on. Apparently NO way of clearing this and this is a paid subscription that was to be a better model to protect our data. Not sure why the latest definitions aren't being matched or loaded .. scan, scan scan and nothing different! 

 

Userlevel 7
Badge +22

We are aware of the frustrations and Threat, QA and Engineering are all working diligently to fix this ASAP.

We do sincerely apologize for the delay, and absolutely understand the impact this has on our customers

 

I’ll leave it to @ChadL to update once we have finished testing and released the fix for this - as soon as it’s ready. 

Userlevel 7
Badge +63

Hello everyone!

 

Sorry about the continued issues and I will ping some Webroot Staff. @ChadL  @TylerM  @khumphrey 

 

Has anyone contacted Webroot support?

 

For Consumers:

Webroot Support:

Submit a ticket

Call 1-866-612-4227

 

 

For Business:

Submit a Ticket

CALL US
1-866-254-8400

 

Sorry again.

Userlevel 7
Badge +30

I think the entire MSP/MSSP community and partners deserve some sort of explanation as to why the entire product portfolio, support and partnerships in general are taking a nosedive. 


Can we get some responses please?

We have thousands and thousands of endpoints with you and these sorts of things makes us want to go elsewhere. 

Thanks

John

 

Userlevel 2

Webroot - if you are going to take days to weeks to fix this, at least post instructions on how to temporarily clear this without turning off or uninstalling your software. 

We have a few macOS machines that are still reporting this as an alert even after the supposed updated definitions. Is there any action we need to take to get this to update? Thanks.

 

 

 

Thank you.

I came here this morning because last night I was given the same error/warning. 
Rebooted the system  (which should have loaded the latest Webroot updates) and ran a sweep last night. I am still “infected”.

Good to know I’m really not and don’t have anything to worry about, but it’s still unnerving.

@jhartnerd123 Hey so I guess I didn’t include this in my previous post, but one of the main features we have on our roadmap is an ability to remove items in quarantine from the console. I’m currently working on a component that will support this feature. We know this has been a pain point so we want to get it fixed asap as well. 

@billyb3 I’ve just received word that the latest definitions were posted today around 1:30 PM MDT which should include an exclusion for the MRT v3 Keylogger issue. Please let me know if you still see this issue popping up.

As of 3/21/2022 - This is still an issue for many of my clientele. 

Userlevel 2

Here to report I am still seeing this flagged as of 03/19. Just to be sure I am okay to set this to the allow list correct?

 

It is still broken on Sunday afternoon

 

Userlevel 2

Latest definitions as of noon PT Sunday are still flagging this MRTv3 file as a keylogger

Not sure why I had do spend several hours sweating this topic this morning when Webroot understood it days ago. Keyloggers scare the shit out of people and should be a very high priority issue to solve, or in this case flag as a false positive. Why did your team sit on it?

I agree - if Webroot would just communicate to the customer life would be easier.  Just think of the tens of thousands of hours wasted because Web Root won’t proactively update the customer - a simple message could be pushed out to all users via same system that deploys new threat definitions.  

Latest definitions as of noon PT Sunday are still flagging this MRTv3 file as a keylogger

Not sure why I had do spend several hours sweating this topic this morning when Webroot understood it days ago. Keyloggers scare the shit out of people and should be a very high priority issue to solve, or in this case flag as a false positive. Why did your team sit on it?

Now that the latest definitions are posted. MDT which should include an exclusion for the MRT v3 Keylogger issue. 

  • What action do we need to take on our end?
  • Anything we need to do for the machines that are still showing up as threat?
  • Will it disappear itself?

Here to report I am still seeing this flagged as of 03/19. Just to be sure I am okay to set this to the allow list correct?

 

Reply