We will occasionally get an alert about a uncategorized file on our Macs. The error will always be something similar to the following:
MRT, Uncategorized file, \Library\Apple\System\Library\InstallerSandboxes\.PKInstallSandboxManager-SystemSoftware\BF320ED5-6C90-4CB6-B2F4-84E54AFD49FD.activeSandbox\Root\Library\Apple\System\Library\CoreServices\MRT.app\Con, 00000000000000000000000000000000,
The MRT will always be in a random sandbox location. I’ve talked with support on this and they said that this is a known issue and that Webroot’s whitelist only allows for MRT to be in one location, so when it is found in another location it throws this false positive. They also said that the only method for releasing this file and allow it is to put the device in an unmanaged profile and then release the file from the agent on the Mac directly.
I have several issues with both the false positive AND the way to fix it.
- Why is Webroot not using application signing to verify applications and still relying on whitelisting in this day and age? Almost every application should be digitally signed by the author. If the file is digitally signed, what does it matter what location it is in?
- Why doesn’t Webroot properly support application sandboxing? This has been present in Macs for a while now.
- Why doesn’t the mac agent and Webroot web console support releasing the file from the management console? This is the whole point of a management console--to not have to connect to endpoints directly to manage them.
- Placing the endpoint in an unmanaged profile just to release a file seems administratively excessive. The whole point of using a managed agent is to control everything centrally and needing to place a device into an unmanaged profile AND to then manage it from the local device to release a file goes against the idea of central administration.
This issue has been present for quite some time (about a year if not longer), and it has still yet to be fixed.
Best answer by dstokes1
1. We do not implicitly trust digitally signed applications: we use it as input into our threat intelligence engines but just because a file is signed (even by a well-known vendor), it isn't guaranteed that the file will be benign. Certificate theft is rampant across the industry where trusted software vendors' certificates are stolen and used to sign malware, leading it to only be an indicator of authorship, not a guarantee.
2. Webroot will scan files within sandboxes but there is no guarantee that an application sandboxed by the operating system will not be able to impact the broader system. So, we are still scanning and inspecting these files as even though they likely pose less risk, the risk is not zero.
3/4. Releasing files from the console should be a relatively infrequent action: we presently require local releasing to ensure the precise file is restored (the console operates off a summarized view of files and, as a mistake during restore from quarantine can introduce an infection, we are particularly cautious). That said, this sounds like an area where the user experience can indeed be improved. We will take this as an item to investigate soon to see if we can make the restore process more seamless.
In the meantime, if you have a copy of the file which is producing this false positive, please send it to us so that we can ensure it is proactively whitelisted.
Thank you for allowing me some time to get them addressed properly.