Once again, BaseSystem.dmg, which is part of the recovery partition installer for MacOS 10.11.6 is yet again being reported as a threat.
Our MSP only offers Webroot as an AV solution, and although I wish it weren't the case, it really appears that Mac support in webroot is: "Well... if we HAVE to" level of support.
I've been through the Adobe Creative Cloud crippling false positives of a year ago where if you didn't hit the right button, your CC install would be trashed. I've been through the total lack of interest in fixing the "Secure keyboard entry" conflicts with Adobe apps. I've been through the horrendously slow drive scans compared to other products. The high CPU usage... the firing off of multiple simultaneous scans... the CPU fans going nuts... The persistant Exclamation mark in the menu bar because it is going to find something wrong that isn't. Its so bad I've given up asking users to report it to me.
I am normally a very civil and calm person, but this is really getting under my skin. Will webroot ever give a crap about the Mac product?
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
I would have the Professionals at Webroot Support do this. Please submit a Support Ticket or Contact Webroot Support to sort this problem. This service is FREE with a Paid Subscription.
Support Ticket System is Open 24/7
Note: When submitting a Support Ticket, Please wait for a response from Support. Putting in another Support Ticket on this problem before Support responses will put your first Support Ticket at the end of the queue.
I am still running MacOS Sierra.
Basesystem.dmg - PUA.OSX.Adware.BucaApps.1.r
Any idea how I actually go about this without wrecking anything?
There was a file contained within this DMG that is a list of plain text malicious URLs that OS X used in a previous version (10.11) Parental Controls. This file is not included in current releases that I have found so I believe that they have changed the method in which they store these URLs or provide an entirely different mechanism.
Annoyed User opted to allow the file manually so that we could continue to protect against any malicious file that embed the URL in question within a payload file.
VirusTotal shows the 470MB disk image to be clean.
I'll PM you with info.
This is an older FP that occasionally pops up here and there in a couple of circumstances. It's possible that an older definitions file is still being used by the agent on this system, or it had an older definitions file upon it's first start up after a long period of not being started up. If a scan is performed in this state, older false positives can be detected and reported to the console.
Another possibility is that this infection was detected with the original false positive date and has continued to report to the console that the machine is infected, even after a definitions file has been updated. This could be a bug that we would want to investigate through support channels.
If this is the case, the agent on the physical machine would actually show a green, "Protected" status, while the only the console shows the infection history.
I don't have many details from your post. Could you try to confirm whether the agent reports a green status? Also could you reply and let me know if this false positive alert was noticed from within your console.
We do not have any other volume on support regarding this false positive detection. Feel free to PM me your email details and I would be glad to look at your account information.
The answer to your question I believe is what you see is what you get with WSA on a Mac computer sorry to say. I'm waiting for the new surprises with WSA when Apple releases macOS Catalina 10.15.
Please see THIS POST that I posted a few days ago.