XProtect is another of the front-line security features in macOS. While MRT’s purpose is to remove malicious software, the purpose of XProtect is to scan potentially malicious executable code to detect known malware. The Apple Platform Security guide reveals more about how XProtect works than other parts of macOS security, although that isn’t quite the same as has been described to developers.

Components

XProtect consists of an on-demand service buried within the many security services in macOS, and a more visible set of data files which are updated periodically by Apple. That XProtect.bundle containing data files is located in /Library/Apple/System/Library/CoreServices/, among the unprotected Data volume additions to /System/Library/CoreServices/ on the System volume in Catalina; in Mojave and earlier, that’s simply /System/Library/CoreServices/

The bundle’s Resources folder contains the following components:

• gk.db, an SQLite database which was introduced in the summer of 2019, and only appears to be installed in Catalina. Its purpose is unknown.
• LegacyEntitlementAllowlist.plist, a property list which was added in February 2020 with version 2114, and contains many cdhashes. These changed again in version 2118 (April 2020). Their purpose is unknown.
• XProtect.meta.plist, a property list which contains a blacklist of Safari extensions which are blocked, seven file types such as com.apple.python which are subject to Gatekeeper checks, a minimum version of Java, and a list of plugins including Flash with minimum permissible version numbers. These haven’t been updated for a long time, and may no longer be functional.
• XProtect.plist, a property list containing non-YARA signatures for malware which XProtect can detect.
• XProtect.yara, a YARA file containing signatures which are considered to be those of malware. YARA definitions follow an open format detailed here.

All malware signatures added to XProtect.plist and XProtect.yara since 2018 have used obfuscated names such as MACOS.1c119be.

When is it run?

According to the guide linked above, “XProtect checks for known malicious content whenever an app: is first launched”, or “has been changed”. If it detects the signature of known malware, macOS refuses to load the executable code, the user is presented with an alert, and offered the option to remove the affected app. There is no option to continue to launch that app.

However, in his presentation for session 701 of WWDC 2019, Garret Jacobson stated clearly that, in Catalina, XProtect checks the executable code of every app and command tool whenever it’s run, regardless of whether its quarantine flag is set. Prior to Catalina, XProtect is only run when Gatekeeper performs first run checks on an app whose quarantine flag is set, or which hasn’t previously been run from its current path.

The process for apps in Mojave is summarised in the diagram below.

The new scheme for Gatekeeper functions in Catalina is as shown below.

Big Sur is expected to follow the same rules as Catalina.

XProtect identifies itself in the log as the subsystem com.apple.xprotect, and typically writes
Xprotect is performing a direct malware and dylib scan: <private>
to mark the start of a scan, but any result is normally censored to remove any meaningful information.

Signature-based malware detection

Matching software against signatures is a well-established and widely used method of malware detection, and can be very effective against malicious software. However, it has several limitations, the first of which is that it can at best only detect existing known malware. Novel malware which doesn’t match any of the signatures can’t be detected at all.

Devising detection rules for signatures is quite an art, and their success dependent on sensitivity and specificity. Rules which are too general will over-detect and return too many false positives, non-malicious software which is misclassified as malware. Rules which are too specific won’t detect genuine malware, and can easily be circumvented by malware authors.

One recent example of both was a signature in XProtect which matched a section of script in which there was a timeout. That wasn’t likely to be sufficiently specific, as the same code could be encountered in many non-malicious scripts, and it wasn’t sensitive enough as it was very easy for malware authors to circumvent by using a small change in the length of the timeout.

These limitations make signature-based detection best-suited to malware which changes little and contains distinctive sections of code or data. Malicious software which is being actively developed to escape detection usually has little trouble in doing so.

Appendix: Known malware which XProtect should detect

This list is based on what XProtect 2099 was known to be able to detect, before obfuscation of malware names in 2018 made this impossible to determine. It has also been checked against signatures included in the current release of XProtect.bundle, version 2133.

XProtect 2133 aims to detect the following well-known malware:

• Abk A
• AceInstaller B
• AdLoad A, B1 and B2
• AdPlugin i and 2i
• Bundlore A, B and D
• CoinThief A, B and C
• CpuMeaner A
• CrossRider A
• DevilRobber A and B
• Dok A and B
• Eleanor A
• ExtensionsInstaller A
• FileSteal i and ii
• Findzip A
• FkCodec i
• Flashback A, B and C
• Geneio A, B, C, D, E, G and G1
• GenieoDropper A
• GetShell A
• HellRTS A
• HiddenLotus A
• HMining A, A2, B, C and D
• iKitten A
• InstallCore A
• InstallImitator A, B, C and D
• Iservice A and B
• iWorm A, B and C
• KeRanger A
• LaoShu A
• Leverage a and A
• MacDefender A and B
• MacHook A and B
• MaControl i
• Mdropper i
• Mughthesec A and B
• NetWeird i and ii
• Netwire A
• OpinionSpy (regular) and B
• ParticleSmasher A
• Proton A and B
• Prxl 2
• QHostWB A
• Revir A, ii, iii and iv
• RSPlug A
• SMSSend i and ii
• Trovi A
• VindInstaller A
• VSearch A
• XAgent A
• XcodeGhost A.