hoakley June 12, 2022 Macs, Technology

Last Week on My Mac: Introducing XProtect Remediator, successor to MRT

It seems only a week ago that I was assuring you that Apple’s Malware Removal Tool wasn’t going away. While I wasn’t entirely wrong, Apple had already changed this back in Monterey 12.3, released on 14 March. MRT’s successor is now installed on every Mac running macOS 12.3 or later: it’s XProtect, or to be more specific XProtect Remediator.

I happened to be looking for something in the CoreServices folder, which is firmlinked between System and Data volumes, and noticed an app there named XProtect.app which looked unfamiliar despite its name. After a quick look through my Time Machine backups, I discovered that it had been installed with the 12.3 update, so looked a bit deeper.

I’m not the first to notice something odd about this new app. The day after 12.3 was released, some of those using Webroot Business Endpoint security protection reported that one of its components was triggering a false positive report as malware. No one thought anything more about the sudden appearance of its executables, and the offending component was duly added to the Webroot exclusions definitions. If only they had realised.

This new XProtect.app is on the Data volume in the folder /Library/Apple/System/Library/CoreServices, which is firmlinked to merge with the matching folder on the System volume at /System/Library/CoreServices. When first installed in 12.3, it reported that it was version 1, and has already become version 2, upgraded as part of macOS rather than as a separate security data update.

What’s unusual about this app is that it contains eight executables, XProtect itself (which hadn’t previously existed as a discrete app or binary), and seven XProtect Remediator executables. According to their names, one is effectively MRT version 3, and the others tackle the following known malware:

Adload, an endemic Trojan known for downloading unwanted adware and PUPs, summarised here;
Eicar, a harmless standard test for anti-malware products;
Genieo, a browser hijacker acting as adware, summarised here;
Pirrit, malicious adware explained in detail here;
SheepSwap, presumably a synonym for Mac malware;
Trovi, a cross-platform browser hijacker.

Each of these executables appears to have been written using Swift.

A look through the strings in XProtectRemediatorMRTv3 suggests that it does indeed replicate much or all of the current functionality in the MRT executable, strongly suggesting that will be a replacement for MRT in due course.

At least in Monterey 12.4, these new XProtect Remediator executables don’t appear to have replaced MRT yet. The existing tool is still run shortly following user login, and its LaunchAgent and LaunchDaemon property lists are still installed. There’s no sign of any routine scan by any of these new XProtect Remediator executables after user login either. However, as MRT’s LaunchAgent and LaunchDaemon property lists are stored on the Data volume and firmlinked into the System, it wouldn’t be difficult for a security data update to disable MRT and substitute XProtect Remediator code, which is perhaps what Apple intends in the future.

Apart from its heavy hints in the latest revision of the Platform Security Guide, Apple hasn’t provided any information about this new expanded version of XProtect. Among the important questions I have are:

Is XProtect Remediator being installed with current or future Big Sur security updates?
As XProtect Remediator doesn’t appear to have been included in Catalina Security Updates, will it be included before support is discontinued shortly?
Will Apple continue to maintain MRT in the future, for those still using versions of macOS which don’t feature XProtect Remediator?

Depending on the answers, those intending to continue using macOS Big Sur or earlier versions of macOS may wish to reconsider the security of their Macs. While this is excellent news for those running Monterey or intending to upgrade to Ventura, it could leave all older versions of macOS with ageing and increasingly ineffective protection against malware.

11Comments

Add yours

1

Named on June 12, 2022 at 1:45 pm

What is the purpose of the seven individual “XProtectRemediator*” executables? What does having a separate executable per exploit accomplish that simply running the “XProtect” with an exploit-specific flag wouldn’t accomplish?

LikeLiked by 1 person
- 2
  
  hoakley on June 12, 2022 at 2:44 pm
  
  As I didn’t design or write these remediators, I don’t know, but I’ll try to guess.
  First, they’re each of them quite different. The MRT replacement looks much like a straight port of the existing MRT, with fairly static rules to correct the damage caused by a range of mostly old malware. The specific remediators appear quite separate code, which each deals with specific malware and its effects. If there’s little common code, then putting them into one big binary doesn’t have any advantage.
  The specific remediators are aimed at tackling malware which is harder to detect and fix using the simple rules in a Yara file, for example. Those malware are notoriously ever-changing to outfox rule-based detection, and in their effects. So each can be quite complex.
  Finally, this modular approach makes it easy for Apple to update individual remediators rapidly in small security updates, as each requires change, rather than having to replace a larger monolithic binary every time.
  But those are only guesses on my part.
  Howard.
  
  LikeLike
3

markbot2zero on June 12, 2022 at 4:45 pm

Thank you, Howard, for your research and thoughts about the future of macOS malware detection and XProtect Remediator.

I was wondering if you were able to figure out what the Remediator for EICAR does. Quarantine it, maybe, or remove it?

For those who may be unfamiliar with EICAR, it’s a small, benign “fake” malware file distributed by a European malware research organization of the same name. It is meant to test anti-malware software by triggering a positive hit. As Howard mentioned, it is harmless.

See: https://www.eicar.org/download-anti-malware-testfile/

-Mark

LikeLiked by 1 person
- 4
  
  hoakley on June 12, 2022 at 5:25 pm
  
  Thank you. No, I don’t know, but expect that Apple uses it in testing.
  Howard.
  
  LikeLike
5

Simon on June 12, 2022 at 5:19 pm

> I happened to be looking for something in the CoreServices folder,
> which is firmlinked between System and Data volumes, …

Howard, since you mention that firmlinking, I hope you excuse a brief detour here.

Is truly only the Data volume encrypted through FV2 on an M1 while the SSV is not? I ask because I noticed that on my M1 Pro 14″ the boot process before I am asked to supply my password has become a lot longer than I recall it being on my 2020 Intel MBP running FV2 under Catalina. There I had to supply the password basically right after the chime, obviously because everything that got loaded for booting after that needed to be decrypted first. But on the M1 now under Monterey, a lot seems to happen even before password entry to decrypt per FV2. At first I thought that now there was possibly just more to boot before password since the SSV as I understood is unencrypted and my password was only required once it came to loading the Data partition which I assumed was far later in the boot process. But then it dawned on me that even fairly basic stuff is still supplied on Data (for example Safari and WebKit stuff IIRC) and gets hardlinked from the SSV, as you indicate above. So with that in mind, I would assume the boot process needs access to that material on Data fairly early on. But in reality, by the time I’m asked for my password, I’d say easily half the overall boot time has already passed. So what is actually going on before password vs. after?

[I did search around your excellent collection of articles first, but I couldn’t seem to find this detail discussed. Apologies if my sub-par search skills simply managed to miss it.]

LikeLiked by 1 person
- 6
  
  hoakley on June 12, 2022 at 5:35 pm
  
  Yes, the SSV in Big Sur and Monterey isn’t encrypted. It would serve no useful purpose, and only get in the way. It’s already fully protected, and doesn’t contain any ‘secret’ or private information – it’s exactly the same no matter which model of Mac it’s on, as each macOS release has its own hash seal.
  Standard time from pressing the Power button on an M1 to the appearance of the login window should be about 15 seconds.
  The only system components stored on the Data volume, like Safari and its supporting libraries, aren’t (and can’t be) accessed until the Data volume is unlocked at login. There’s more about this topic coming tomorrow morning, when I look at how Ventura can load system patches.
  Howard.
  
  LikeLike
  - 7
    
    Simon on June 12, 2022 at 7:26 pm
    
    Thank you, Sir. As always, much appreciated.
    
    LikeLiked by 1 person
8

Ola Dimeji on June 13, 2022 at 7:13 pm

When I need information devoid of noise – whether about a new OS or an old one’s mods, I come here. Thank you, as always, for providing info that’s apposite.

LikeLiked by 1 person
- 9
  
  hoakley on June 13, 2022 at 7:14 pm
  
  Thank you.
  Howard
  
  LikeLike
10

Andy on July 19, 2022 at 12:33 pm

The XProtectRemediators show on my Catlina 10.15.7 as last updated July 5.

LikeLiked by 1 person
- 11
  
  hoakley on July 19, 2022 at 1:26 pm
  
  I believe that they should have been updated to version 65 on 7 July. Have you run SilentKnight to check for pending updates?
  Howard.
  
  LikeLike

·Comments are closed.

Share this:

Related