How XProtect has changed in macOS Sequoia

By now you should have gathered that macOS Sequoia 15.0 has brought changes to XProtect and the way that it’s updated. This article attempts to explain what has changed, and how that affects both macOS and you.

Sonoma and earlier

XProtect’s data is contained in a bundle in the path /Library/Apple/System/Library/CoreServices/XProtect.bundle, on the Data volume. When XProtect scans code to check it for known malware, it uses the Yara rules in XProtect.bundle/Contents/Resources/XProtect.yara, although it first checks unsuccessfully for rules in a file named XProtect2.yara within the bundle that, as far as I know, has never existed.

Updates to the XProtect bundle are provided through the normal Software Update mechanism, and summarised in the diagram below. Each Mac periodically checks Apple’s software update service for new updates. When it finds a version with a higher version number than that installed, the same system downloads and installs the updated bundle, so updating the Yara rules used. That may be performed directly, or through a Content Caching server, when that’s available. Checks for updates and their installation can also be performed manually, as in the command tool softwareupdate, as used by SilentKnight.

Sequoia: locations

macOS Sequoia adds a new location for XProtect’s data bundle, in the path /var/protected/xprotect/XProtect.bundle, also on the Data volume, which contains the primary copy of the Yara rules used by XProtect on that Mac. When XProtect scans code to check it for known malware, it looks for Yara rules in the following order:

XProtect.yara in /var/protected/xprotect/XProtect.bundle
XProtect2.yara in /Library/Apple/System/Library/CoreServices/XProtect.bundle (never found, as that file doesn’t exist)
XProtect.yara in /Library/Apple/System/Library/CoreServices/XProtect.bundle.

Thus, an XProtect bundle in CoreServices acts as a secondary source of Yara rules, and is only used if there’s no primary XProtect bundle in /var/protected/xprotect.

XProtect records in the log which set of Yara rules it uses for each of its ‘direct malware and dylib scans’.

Alongside the XProtect bundle in /var/protected/xprotect is XProtect’s database XPdb, which is also present in previous versions of macOS. This is likely to contain data from XProtect scans.

Sequoia: updates

At least once every 24 hours, XProtect’s Update Service automatically looks for updates to its bundle. This may include a check through softwareupdated, which may check Apple’s software update service for updates available there. If it finds any there, it appears that they are downloaded and installed in the secondary location in CoreServices.

In Sequoia, the primary check is made with iCloud using CloudKit, and is announced in the log in the entry
CloudKit update source coming online
This uses a container with the ID com.apple.sear.xprotect-updates, SEAR being the in-house name for Apple’s security teams. Any update found there is ‘considered’ by comparison with the version currently installed in /var/protected/xprotect, and the decision whether to download and install that update is recorded in the log, for example
Keeping local update 5273, installed <private>

XProtect’s Update Service appears to apply the usual rule that it will only download and install an XProtect bundle if its version number is greater than that already installed, and won’t attempt to install a bundle with a lower version number.

If the version number of the XProtect bundle in the secondary location in CoreServices is greater than that in the primary location in /var/protected/xprotect, then XProtect’s Update Service may copy the bundle from the secondary location to replace that in the primary location. However, immediately after upgrading to Sequoia, when the primary location has no XProtect bundle, several hours can pass before a primary bundle is installed by XProtect’s Update Service. Over that period, XProtect scans use the Yara rules installed in the secondary XProtect bundle in CoreServices. This is summarised in the diagram below.

Sequoia: xprotect command

Apple has added a command tool to Sequoia, to help manage the new version of XProtect and its unusual habits. As its documentation isn’t complete, here are further details of some of its options.

xprotect version (which doesn’t require sudo) returns the current version of the XProtect bundle in the primary location in /var/protected/xprotect, but not the version of the secondary bundle in CoreServices. If it returns a version of 0, that means that no XProtect bundle is currently installed in /var/protected/xprotect, although XProtect will still be able to check against the Yara rules in the secondary bundle.

sudo xprotect check (requires sudo) checks and returns the current version of XProtect available from iCloud, not that available from Apple’s software update service. If XProtect has already copied a bundle from the secondary to primary locations, then the version reported from iCloud may be lower than that reported by xprotect version.

sudo xprotect update (requires sudo) requests the latest XProtect version from iCloud. If its version is greater than that in the primary bundle, then that update will be installed automatically. It may also check the version of the secondary bundle, and is likely to copy-install that to the primary location if that version is greater than the primary bundle.

Sequoia: version therapy

The release of Sequoia was accompanied by a series of changes in the availability of XProtect versions for different macOS:

13 Sep (approx) Software Update Service stopped providing regular XProtect updates
13 Sep (approx) XProtect version 5273 available from Software Update Service for Sequoia only
16 Sep macOS 15.0 released, with version 5273 available from Software Update Service for Sequoia only; upgraded Macs updated to 5273 by copying from secondary to primary locations; 5273 not provided from iCloud, where 5272 remained the current version
18 Sep Software Update Service resumed delivery of 5272 to Sonoma and earlier
18 Sep Software Update Service started delivery of 5274 to Sonoma and earlier; 5273 no longer available for Sequoia, with 5272 still available from iCloud
24 Sep Software Update Service delivered 5275 for Sequoia; no change to Sonoma and earlier, and 5272 still available from iCloud.

Thus, those Macs upgraded to Sequoia early, or which had been running a beta-release, were likely to have a primary XProtect version of 5273. Those that upgraded after 18 September are likely to have done so after installing the 5274 update, which will then have been copied to the new primary XProtect location, and prevented them from being updated to 5273. This makes a big difference in terms of Yara rules: although the differences between versions 5272 and 5274 are largely cosmetic, 5273 contains well over 3,000 new lines to perform file size checks on potential malware.

Hopefully Apple will sort all this out in the next round of XProtect updates.