Download Center. You can find the documents and files regarding the operating system, packages, desktop utilities and so on for your Synology product to enjoy the latest and versatile features. Please select the product category and the corresponding model you use. Select product type.

Apple is in the process of pushing an update to its malware removal tool, MRT, bringing it to version 1.29.

Although Apple neither announces such updates nor reveals their changes, this new version of MRT adds code to deal with two malware products, named by Apple as OSX.Mudminer.A and OSX.Nwm0zjrk.A. Security experts consider that OSX.Mudminer.A is Apple’s in-house name for OSX.CreativeUpdate, which was inadvertently spread by malicious links posted to MacUpdate between 1 and 2 February 2018. OSX.Nwm0zjrk.A remains unidentified.

This new version of MRT has a build date of 9 February 2018. Assuming that OSX.Mudminer.A and OSX.CreativeUpdate are one and the same, this gives an unusually precise timeline for this:

• 1 Feb – release via MacUpdate
• 2 Feb – removal of download links from MacUpdate
• 2 Feb – Malwarebytes detects and removes, other products following rapidly
• 9 Feb – MRT new version built for release
• 14 Feb – Apple pushes MRT update.

Distribution of the malware appears to have ceased once MacUpdate (and secondary aggregators) removed links on 1-2 February.

Not new, but worth noting, is MRT’s coverage of several unwanted or malicious Safari extensions. These currently include:

• Omnibar.safariextz, part of Genieo
• GoldenBoy.safariextz
• Nariabox.safariextz
• Perfetnight.safariextz
• Smokycap.safariextz
• Smokycap-2.safariextz
• SearchConnect.safariextz
• SafariProxy, part of Dok.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by LockRattler and SystHist for El Capitan, Sierra and High Sierra, available from Downloads above. If your Mac has not yet updated MRT itself, you can force an update using LockRattler, or at the command line.

I maintain lists of the current versions of security data files for Sierra on this page, for High Sierra on this page, and for El Capitan on this page.

I also maintain a detailed listing of the individual malware which the current versions of XProtect and MRT detect and remove in this article.

Unless your Mac has been isolated from the Internet for the last few days, or is running a very old version of OS X, it will have been updated ‘silently’ to MRT* 1.45 in that period. The next question which many users asked is whether the new version of MRT is run once it has been installed. As I wrote yesterday, opinion is that it has to be run manually unless the Mac is restarted after updating, and Apple’s advice is that a Mac should always be restarted after an update to MRT, although that advice isn’t given consistently either.

In this article, I show that is incorrect, and MRT should in fact run after such an update (as Al Varnell has reported), but that many users will still want to run MRT manually at that time. I also provide a glimpse into what MRT actually does.

I downloaded and installed the MRT update using my free tool EFIcienC. That was completed around 23:30:23 UTC+0100 on 10 July, with a telltale log entry preceding that of
23:30:13.843524 softwareupdated AssetCacheServices #e13d22c8 ACSLocateCachingServer(assetURL=http://swcdn.apple.com/content/downloads/46/61/041-84505/tb9wetgu8ptaa7znioombsmslxzvvdn95g/MRTConfigData_10_14.pkg, locateTimeout=30.000, options=(null), callbackQueue=0x0, callback=0x70000f63a758)

There followed a series of log entries which show that the updated version of MRT was then launched in daemon mode:
23:30:23.223168 MRT libswiftFoundation.dylib Running as daemon
23:30:24.482267 MRT Security Failed to talk to secd after 4 attempts.
23:30:24.482278 MRT Security got event: Connection invalid
23:30:24.482343 MRT Security using system preferences

Immediately after those was a succession of sandbox errors from MRT’s activity. The first seven generated extended sandbox error reports, following which there were 12 briefer error reports from the kernel. In each case, these reported denials of attempts made by MRT to access protected metadata. Then came 3 reports of:
23:30:30.688775 MRT Security Failed to talk to secd after 4 attempts.

Finally, at 23:30:39.884729, 11 seconds after the update had been installed, MRT started work, which was marked by a series of thousands of signature checks against Apple’s Certificate Revocation List (CRL), such as
23:30:40.031811 trustd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (MRT[36501]/0#-1 LF=0)

Interspersed among those were signature checking errors, such as
23:30:40.097221 MRT Security MacOS error: -67062

Errors reported include:

• -67014, unsealed contents present in the bundle root;
• -67030, invalid Info.plist, indicating the Info.plist file or the signature had been modified;
• -67062, code object is not signed at all;
• -2147409652, the signing certificate has been revoked;
• errors registering stapled tickers for notarized bundles;
• Trust evaluate failure: [leaf TemporalValidity] [ca1 TemporalValidity];
• Trust evaluate failure: [leaf Revocation2].

Some 39 seconds after MRT had been started in daemon mode, it was complete, with the entries
23:31:02.441295 MRT libswiftFoundation.dylib Daemon finished.
23:31:02.441461 MRT libswiftFoundation.dylib Finished MRT run

Just 0.02 second later, MRT was started in both daemon and agent mode together:
23:31:02.464387 MRT libswiftFoundation.dylib Running as agent
23:31:02.464951 MRT libswiftFoundation.dylib Running as daemon
23:31:02.464952 MRT libswiftFoundation.dylib Caught xpc notification.
23:31:02.629866 MRT Security got event: Connection invalid
23:31:02.629879 MRT Security Failed to talk to secd after 4 attempts.
23:31:02.629956 MRT Security using system preferences

There followed at least 20 more sandbox errors (which appeared identical to those reported on its first run), then after just 0.29 second, the MRT agent had finished, writing to the log essentially the same messages which it writes to Terminal when run manually:
23:31:02.670791 MRT libswiftFoundation.dylib failed to check loginItems
23:31:02.750492 MRT libswiftFoundation.dylib Agent finished.
23:31:02.750605 MRT libswiftFoundation.dylib Finished MRT run

The MRT daemon wasn’t done yet, not by a long way. It reported three times
23:31:03.167073 MRT Security Failed to talk to secd after 4 attempts.
then ran what appeared to be the same CRL checks all over again.

Please visit for updates.KU Information Technology. KU IT support staff are working to resolve the problems and will provide more information as it becomes available. Until resolved, restrictions can be removed from messages in Outlook on a per-message basis by opening a new message, clicking 'Options,' and deselecting the 'Do Not Forward' option under 'Encrypt.' If you have new information not included here, please contact IT CSC at 864-8080.

After running for another 16.3 seconds, MRT’s daemon mode completed:
23:31:18.753180 MRT libswiftFoundation.dylib Daemon finished.
23:31:18.753348 MRT libswiftFoundation.dylib Finished MRT run

MRT then ran a second time in agent mode, writing the same messages as it had the first time:
23:31:18.773987 MRT libswiftFoundation.dylib Running as agent
23:31:18.774545 MRT libswiftFoundation.dylib Caught xpc notification.
23:31:18.944266 MRT libswiftFoundation.dylib failed to check loginItems
23:31:18.974010 MRT libswiftFoundation.dylib Agent finished.
23:31:18.974131 MRT libswiftFoundation.dylib Finished MRT run

Total elapsed time was just under a minute for two runs of MRT in daemon mode, and two runs in agent mode.

It’s clear that MRT does, or rather should, run after updating, in both agent and daemon modes. But unless you check your logs, the user gets no feedback to indicate whether it completed successfully, or ran into fatal errors. In this case, if a Mac had a hidden Zoom web server directory, MRT would have deleted it without any report to the user either: the only record of its actions is in its log entries, therefore inaccessible to the great majority of Mac users.

Does MRT run following startup? Inspecting the unified log does indeed confirm that MRT runs once in daemon mode, then once in agent mode, shortly after starting up in macOS 10.14.5. Interestingly, this time it generated no sandbox violations, in contrast to when it was run immediately after updating.

Other than shortly after starting up or updating, I can find no evidence that MRT is run at any other time, although I’d presume that it would be called when appropriate by XProtect or another part of the security system when its services might be needed. But there’s no evidence in the logs that it is run at regular intervals, for instance.

What MRT does in daemon and agent modes appears very different. When running as a daemon, it scans bundles checking their signatures against the Certificate Revocation List (CRL), and presumably against its own list of known malware which it can remove. When running as an agent, it appears to run through a different set of rules which, in the case of the hidden Zoom web server, enable it to detect and remove that web server. User reports confirm that MRT 1.45 run in agent mode does indeed recognise and remove that hidden folder.

The snag with all of this is that nothing appears to be reported to the user, unless they happen to be an avid browser of the unified log:

• MRT updates occur in almost total silence. Apple doesn’t tell anyone when they occur, nor what they should do. Ironically, the only notification a user is likely to see is when an update is installed. Not knowing that the update was expected in the first place makes that information of no use at all.
• In normal circumstances, the user is completely unaware of whether the version of MRT they have installed is up to date. Delays in updates being pushed to some Macs are common, and failures do occur, leaving users running old versions of MRT.
• MRT runs in complete interface silence. When it encounters errors, or makes changes to the file system such as deleting a hidden web server (in the Zoom case), the user is not informed that anything has happened.
• Complete failure of the MRT protection system could occur without the user being warned at all.

If you’re happy to place complete trust in MRT being updated correctly, running automatically after an update, and soon after starting your Mac up, then you shouldn’t worry about trying to run it manually after an update. Personally, I think I’ll run it manually in agent mode just to be safe – it’s far simpler than wading through thousands of log entries to check whether everything worked properly the first time.

* MRT = “Malware Removal Tool”, one of the key security components in macOS (thanks to @rosyna for pointing out that I had for once omitted to explain that).

Postscript (19 July 2019):

Following the MRT 1.47 update of 18 July, MRT followed exactly the same behaviour, spontaneously running twice in daemon mode, and twice as an agent, with apparently identical errors. Your mileage may of course vary.