Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5279. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5278), this version makes a small amendment to the detection rule for MACOS.PIRRIT.CHU.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5279.
For Sequoia only: there’s no sign of this update being made available in iCloud, which now returns an XProtect version of 5278. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.
Startup
Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.
A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.
The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.
User Data
Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.
Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.
Run Apps
With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.
When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.
Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.
There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.
macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.
Private Data
Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.
Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.
No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.
There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.
Downloaded Apps
While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.
Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.
Bad Links
Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.
Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.
Summary
That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 147. The previous version was 145.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac has not yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-147.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5278. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5277), this version adds three new definitions for MACOS.ADLOAD.I, MACOS.SOMA.G and MACOS.SOMA.H.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5278.
For Sequoia only: there’s no sign of this update being made available in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that’s complete you need to update the primary XProtect bundle in Terminal using the command sudo xprotect update
then entering your admin password. If you’re unsure what to do, this article explains it comprehensively and simply.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Many of you still seem puzzled as to how XProtect installs and updates in macOS Sequoia. This article tries to make this clear, so you can keep XProtect up to date.
Sonoma and earlier
Until this changed in Sequoia, XProtect has been straightforward: its data is stored in a bundle named XProtect.bundle, in the path /Library/Apple/System/Library/CoreServices, which is on the Data volume so it can readily be updated. When you or macOS downloads an XProtect update, it simply replaces that bundle with the new one. This is shown in the diagram below.
Sequoia
XProtect in macOS 15 prefers not to use the XProtect.bundle in its old location of /Library/Apple/System/Library/CoreServices (although it can do if there’s no alternative). Instead, it looks for XProtect.bundle in its new location, /var/protected/xprotect.
However, when you or your Mac use the old update system, including Software Update, softwareupdate or SilentKnight, that still installs the update in the old location, where it won’t normally be used by XProtect when making its checks. What’s supposed to happen is that at least once a day, macOS checks whether there’s a newer update in the old location. If there is, then it should automatically prepare and move that to the new location in /var/protected/xprotect for XProtect to use.
If you want that to happen immediately, then you can run the following command in Terminal: sudo xprotect update
then enter your admin user’s password. The xprotect command tool will then complete the installation of that update from its old location in /Library/Apple/System/Library/CoreServices into its new location in /var/protected/xprotect.
There’s also a second way that XProtect in Sequoia can be updated, and that’s over a connection to iCloud. If that’s used, then the update is installed straight into its new location, and doesn’t change the XProtect bundle in the old location at all. Although Apple has used that earlier, all XProtect updates since the release of Sequoia have come using the old Software Update system, so have needed to be completed using the xprotect command in Terminal.
This is shown in the diagram below. The blue boxes show the old Software Update system, and the pink boxes are the new parts that ensure the update is installed in the new location.
SilentKnight
SilentKnight still works using softwareupdate, and can’t use the new xprotect command for updates yet, because that requires structural changes in the app that will be available in version 3. However, in Sequoia it reports the version of XProtect installed in the new location, as that’s the one that XProtect now uses.
When SilentKnight discovers a new version of XProtect via softwareupdate, it therefore installs that in the old location, in the path /Library/Apple/System/Library/CoreServices. It has no choice but to do that. Once that’s been installed to the old location, the version shown for XProtect won’t change, as that requires macOS to complete the second stage of the installation. You can then either:
leave macOS to complete the installation itself, which should happen over the next day or so, or
run sudo xprotect update in Terminal, which will complete that update immediately. SilentKnight will then show the updated version number correctly.
Key points
In Sequoia, when XProtect is updated by Software Update, softwareupdate or SilentKnight, you should either leave macOS to complete that installation, or run sudo xprotect update in Terminal if you want it to be updated immediately.
This only applies to macOS Sequoia: Sonoma and earlier still work as they always have done.
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5277. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for all supported versions of macOS (5276), this version contains extensive changes, largely of an editorial nature. It adds one new detection rule for MACOS.PIRRIT.CHU, and removes rules for OSX.Genieo.C, OSX.Genieo.B, OSX.Genieo.A and OSX.Leverage.a.
Many rules have changes to their detection hashes, where existing SHA1 hashes are replaced with SHA256. Among the rules changed by this are 36:
OSX.Proton.B
OSX.Vindinstaller.A
OSX.OpinionSpy.B
OSX.InstallImitator.C
OSX.Eleanor.A
OSX.InstallImitator.A
OSX.VSearch.A
OSX.Machook.A
OSX.Machook.B
OSX.iWorm.A
OSX.iWorm.B/C
OSX.NetWeird.ii
OSX.NetWeird.i
OSX.GetShell.A
OSX.Abk.A
OSX.CoinThief.A
OSX.CoinThief.B
OSX.CoinThief.C
OSX.HellRTS.A
OSX.MacDefender.B
OSX.QHostWB.A
OSX.Revir.A
OSX.Revir.ii
OSX.Flashback.A
OSX.Flashback.B
OSX.Flashback.C
OSX.FileSteal.ii
OSX.MaControl.i
OSX.Revir.iii
OSX.Revir.iv
OSX.SMSSend.i
OSX.SMSSend.ii
OSX.eicar.com.i
OSX.AdPlugin.i
OSX.AdPlugin2.i
OSX.Prxl.2
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5277.
For Sequoia only: so far, I have seen no sign of this update in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then once that is complete you need to update the primary XProtect bundle in Terminal using the command sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
If you’ve already upgraded to macOS Sequoia, you’ll probably be well aware of the changes it has brought in updating the data used by XProtect. Although it’s now designed to get those updates from iCloud, so far most have been delivered through the traditional Software Update route, and have had to be installed in their new location either manually in Terminal, or by waiting for the new system to get round to it. So is it worth this extra hassle: how has the new XProtect improved?
We’ve now seen two updates only for Sequoia’s XProtect, one for all Macs, and one only for older macOS. Although still early days, the differences in the XProtect bundle have been obvious. Both versions 5273 and 5275, which were only released for macOS 15, contained large additions to their detection rules, which vanished just as suddenly in 5276, the latest version common to all versions of macOS. To see what has changed, we must examine their XProtect.yara files, the only one in its bundle that has seen any changes.
YARA rules
XProtect performs static checks on code before it’s run, to assess whether there’s evidence that it’s malicious. Its tests are based on YARA rules, explained in detail here. Each rule sets out conditions that must be met for XProtect to conclude that a file is known to be malicious. For example, the rule used by XProtect to detect the Eicar test, a standard non-malicious sample used in testing, is: rule EICAR
{
meta:
description = "OSX.eicar.com.i"
xprotect_rule = true
condition:
filesize <= 100000000 and hash.sha1(0, filesize) == "3395856ce81f2b7382dee72602f798b642f14140"
}
Its meta section names the detection and states that it’s an XProtect rule. The condition to be met for this rule requires a file size of less than 100 MB and the SHA1 hash of the whole file, from its start (0) to the end (filesize), matches the hash given. Some rules have far more complicated conditions, requiring combinations of tests.
Changing rules
New rules that have only appeared in YARA files used by Sequoia have followed a different pattern. Here’s an excerpt from an example: rule XProtect_MACOS_DOLLITLE_CT
{
meta:
description = "MACOS.DOLITTLE.CT"
uuid = "[UUID]"
condition:
hash.sha256(0, filesize) == "[SHA256 hash]" or
…
}
where [UUID] is the rule’s unique identifier, and [SHA256 hash] is the hash value for that part of the condition.
For the first time this rule’s metadata includes a UUID, and its conditions require the SHA256 hash of the file contents to match one of a number of specific values. In this case, the rule gives only six different hashes, but in the rule for MACOS.SOMA.CT there are 3,124 hashes to match against.
So the new YARA rules tested by Apple using Sequoia’s XProtect don’t yet reveal any evidence of new capabilities. What they do suggest is that it’s capable of handling even larger sets of rules, including single rules testing well over 3,000 file hashes. Over the last year, XProtect’s YARA files have increased considerably in their size and complexity. XProtect.yara from version 2173 a year ago had only 223 rules in just over 3,000 lines of code, while version 5275 for XProtect in Sequoia has more than 350 rules requiring nearly 17,000 lines of code.
XProtect future
It seems most unlikely that Apple will ever update Sonoma or earlier versions of macOS to use comparable code in XProtect to that in Sequoia. We have already seen how it has forked XProtect’s YARA rules to deliver different versions for Sequoia and previous macOS, with the newer XProtect receiving odd-numbered releases, and older ones even-numbered. Although those have been confusing for those users who track security data updates, Apple expects us to leave it to macOS to download and install the right updates promptly.
If the last couple of weeks have been chaotic, I fear that the future will be similar. I’ll continue to do my best to inform you of updates to XProtect’s data, and to help you keep your Macs up to date, whichever version of macOS they’re running.
[Thanks to Arnaud for correcting my original reference to file sizes, rather whole-file hashes.]
Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5276. As usual, Apple doesn’t release information about what security issues this update might add or change.
Relative to the last version released for Sequoia (5275), this version removes all the new-style rules that had been added to that and 5273. Relative to the general release version 5274, and 5275, it adds one new rule for MACOS.PIRRIT.BM.OBF.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5276.
For Sequoia only: so far, I have seen no sign of this update in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then you need to update the primary XProtect bundle in Terminal using the command sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
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) 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.
Apple has just released an update to XProtect for Sequoia only, bringing it to version 5275. As usual, Apple doesn’t release information about what security issues this update might add or change.
In accordance with changes brought in version 5274 for Sonoma and earlier, this new version replaces the previous rule for MACOS.449a7ed with a modified version for MACOS.BUNDLORE.KUDU.5, that for MACOS.e4644f7 with MACOS.BUNDLORE.KUDU.3, and that for MACOS.0e62876 with MACOS.BUNDLORE.WBTLS.
It also adds a Yara definition for MACOS.TAILGATOR.CT using the new format of rule, with each rule given a UUID and listing SHA256 hashes of file size, of which there are just 13.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5275.
So far, I have seen no sign of this update in iCloud, which still returns an XProtect version of 5272. If you download and install it using Software Update, softwareupdate or SilentKnight, then you need to update the primary XProtect bundle in Terminal using the command sudo xprotect update
then entering your admin password.
I maintain a list of the current versions of security data files for Sequoia on this page.
Each of the main security services in macOS, such as XProtect, relies on data commonly stored in separate files on the Data volume so they can be updated directly outside full macOS system updates. Those are released silently by Apple, unannounced, and you aren’t even sent a notification when they’ve been updated.
Currently, those most frequently updated are XProtect and XProtect Remediator, normally released in two-week cycles. However, Sequoia has changed the way that XProtect’s data is updated, and it’s now intended occur over a connection to iCloud rather than through Software Update, while XProtect Remediator continues to rely on the latter rather than iCloud.
This article details each of the main security data files found in macOS 15 Sequoia, together with others involved in related system functions. Several other bundles that formerly had roles in security have now been emptied, or left frozen in time, and three have been removed completely; those are listed below for the record. As Apple doesn’t document any of them beyond mentioning their existence and simplified role, the information given is the best that I can find currently.
Main Security Data
XProtectPayloads, alias XProtect.app and XProtect Remediator
Latest version: 145, 3 September 2024.
This contains a suite of specialised malware detection and remediation tools, in the app bundle XProtect.app on the Data volume at /Library/Apple/System/Library/CoreServices. This was introduced in macOS 12.3, then version 62 was pushed to Catalina and later on 17 June 2022. Executables include a replacement for MRT, and many scanners for specific malware types. My free XProCheck inspects its reports for malware detection and remediation. This is normally updated every two weeks using Software Update or a substitute.
XProtectPlistConfigData
Latest version: 1.0 5275, 24 September 2024.
These are the whitelists and blacklists used by XProtect, as detailed here. In Sequoia, two different locations are used: the primary is at /var/protected/xprotect/XProtect.bundle, on the Data volume; the secondary is also on the Data volume at the traditional location of /Library/Apple/System/Library/CoreServices/XProtect.bundle, and is used as a fallback when there’s no bundle at the primary location. While previous versions of macOS still obtain updates through Software Update, Sequoia is intended to update the primary bundle via a CloudKit connection to iCloud, although it can still update the secondary bundle using those released via Software Update when they’re available. This is expected to be updated every two weeks, but may not be the same as updates for previous versions of macOS. You can force an update using the command sudo xprotect update in Terminal, and that will also copy an update obtained through Software Update to the primary location.
Bastion
Latest version: not given, but bundled in the current XProtectPayloads.
These provide rules and exceptions for XProtect Behaviour Service (XBS). First introduced in Ventura, this service monitors for and logs processes that access sensitive locations such as folders containing browser data. As of XProtectPayloads 137 it has 12 Bastion rules, but doesn’t block behaviours, only records them in its database at /var/protected/xprotect/XPdb. Bastion rules are defined in bastion.sb and BastionMeta.plist inside /Library/Apple/System/Library/CoreServices/XProtect.app Those are updated infrequently.
AppleKextExcludeList
Latest version: 20.0.0, 5 September 2024 (15.0 release).
This is a huge list of kernel extensions which are to be treated as exceptions to Sequoia’s security rules, and is stored on the Data volume in /Library/Apple/System/Library/Extensions/AppleKextExcludeList.kext, at Contents/Resources/ExceptionLists.plist.
Others
IncompatibleAppsList
Latest version: 140.191 (15.0 release).
This is a bundle on the Data volume at /Library/Apple/Library/Bundles/IncompatibleAppsList.bundle which contains IncompatibleAppsList.plist, listing many known incompatible versions of third-party products, including Flash Player.
Vestigial Data
MRTConfigData
Latest version: 1.93, 14 July 2022.
This was Apple’s Malware Removal Tool stored on the Data volume at Library/Apple/System/Library/CoreServices/MRT.app, so that it could remove any malware which macOS detected. This has now been replaced by the XProtectRemediatorMRTv3 executable module in XProtect Remediator, and may disappear in future versions of macOS. It usually isn’t installed as part of macOS, but may be later as a security data update.
Gatekeeper Configuration Data (GK Opaque)
Latest version: 181, but can instead be 94.
This is an SQLite database on the Data volume in /private/var/db/gkopaque.bundle/Contents/Resources/gkopaque.db may have been used to provide whitelists for Gatekeeper’s security system, which checks the code signatures of apps. Macs that have never had Catalina or earlier installed normally have the very old version 94, indicating this database is no longer used.
Gatekeeper E Configuration Data (GKE)
Latest version: 8.0.
This is an SQLite database on the Data volume in /private/var/db/gke.bundle/Contents/Resources/gk.db with an additional file gke.auth, which may have provided whitelists for Gatekeeper’s security system. gke.auth is believed to contain data for checking signed disk images, and seems to have remained largely unchanged since Sierra. gk.db was new in Catalina and hasn’t changed since.
Recently Removed
TCC_Compatibility Bundle
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/TCC_Compatibility.bundle which has been removed from Sequoia.
Core Services Application Configuration Data
This used to be a bundle on the System volume at /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle, containing a list of app exceptions in /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist. This has been removed from Sequoia.
CompatibilityNotificationData
This used to be a bundle on the Data volume at /Library/Apple/Library/Bundles/CompatibilityNotificationData.bundle, containing CompatibilityNotificationData.plist, and listing version ranges of third-party products to be notified as being (in)compatible. This has been removed from Sequoia.
One of my greatest regrets in life is that I never invested in a stock of cards with just four words on them: I told you so. Although I’m often wrong, when I see an obvious problem on its way, it’s disappointing how often it’s ignored. Instead of last week being all about Sequoia, I ended up spending most of my time trying to discover what the hell was going on with XProtect and its updates.
My feeling of unease started before last weekend. My fourth and last-ditch fallback Mac is a lovely MacBook Pro 16-inch 2019. It doesn’t see much use, so in the days before the release of Sequoia I charged it up and updated it to 14.6.1. It was still running an old version of XProtect, 2195 from the end of May, so I was surprised when it didn’t update XProtect, and no update was offered. At roughly the same time, my MacBook Pro M3 Pro running 15.1 beta updated from 5272 to 5273, and other beta-testers reported the same.
Bearing in mind that Apple had told nobody what was going on with XProtect or its updates, when last Monday came and my three other Macs that had been running 14.6.1 were upgraded to 15.0, I was still none the wiser. As with everyone else upgrading to Sequoia, any existing XProtect bundle was ignored by the new version of XProtect, and when asked what version of its security data it was running, it replied 0 (zero), indicating that it had no such data. That was a surprise to many, and something not anticipated by any information from Apple.
If you weren’t using SilentKnight, you’d then have to guess either that macOS would somehow fix that before you ran any newly downloaded apps, or that there would be a new command tool named xprotect, whose man page also doesn’t provide any guidance as to what to do.
For those who checked their new Sequoia installation with SilentKnight may have been just as surprised to see the XProtect version of 0, but at least they were guided to run the xprotect command tool, and force an update. Even then, confusion reigned when some Macs were updated to 5273 while others were left at 5272. Either has got to be better than 0, though.
Meanwhile, those who had updated to 14.7 or 13.7 got no XProtect update at all. If those Macs had already installed 5272, then that’s where they stayed, with no sign of 5273, which appeared exclusive to those who had ventured up to Sequoia. But if those Macs were still using an older version of XProtect’s data, there was no update available to take them to 5272, which others had installed when it had been released at the end of last month (28 August).
By the end of the following day, 17 September, this was the state of play with XProtect data:
those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273;
those running Sonoma 14.7 or any earlier version of macOS could have 5272 if they had updated before 13 September, or any older version if they hadn’t.
Then late on 17th, or early on 18th depending on your time zone, everything changed again. Apple’s software update servers started offering 5272 to everyone, and as an added bonus, those running Sequoia might also be offered 5273, although the new iCloud update service seemed content just to offer 5272. Within 24 hours, Apple released yet another XProtect data update, to version 5274, only this time it wasn’t made available to Macs running Sequoia. By the end of 18 September, the state of play had changed to:
those running Sequoia could have no XProtect data at all (‘version 0’), 5272, or 5273, but not 5274;
those running Sonoma 14.7 or any earlier version of macOS could have 5274 if they had updated on 18 September, or any older version except 5273 if they hadn’t.
Does any of this make a difference, though: just what came in the updates to 5273 and 5274?
For Macs running macOS Sonoma or earlier, 5274 is just a renaming exercise, and doesn’t materially affect XProtect’s ability to detect malware. Perhaps it was a placebo after all.
The new Yara definitions added to 5273 are very different, though. As I described in my announcement here: “This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.” Here’s a short excerpt: rule XProtect_MACOS_SOMA_CT
{
meta:
description = "MACOS.SOMA.CT"
uuid = "DA584E59-A152-4E5B-A906-D354144DCA69"
condition:
hash.sha256(0, filesize) == "59e01f6f925af0643f4751191d28eab11ffb014412cd66ece8e5c77ba082977a" or
following which are a further 3,123 hashes, whereas MACOS.DOLITTLE.CT has just six.
Clearly, Sequoia’s XProtect is quite a different beast from that in Sonoma. It looks like Apple has forked XProtect data files, the Yara definitions in particular. It’s now likely that each future XProtect data update will either be destined for Sonoma and earlier, or specifically for Sequoia. Keeping them in the same version numbering sequence is only going to lead to greater confusion, unless Apple only intends releasing further updates for macOS 15 and later.
As Apple continues to provide absolutely no information about this, I fear that we’re just going to be left stumbling on in the dark, wondering what’s going on with one of the primary security defences in macOS. It must be time to order a new batch of I told you so cards.
Apple has just released an update to XProtect for all versions of macOS from El Capitan to Sonoma, but not for Sequoia, bringing it to version 5274. Version 5273 was for Sequoia only.
Apple doesn’t release information about what security issues this update might add or change. This replaces the previous rule for MACOS.449a7ed with a modified version for MACOS.BUNDLORE.KUDU.5, that for MACOS.e4644f7 with MACOS.BUNDLORE.KUDU.3, and that for MACOS.0e62876 with MACOS.BUNDLORE.WBTLS. New format Yara rules that were added to 5273 for Sequoia don’t appear, suggesting that Yara rules have been forked, with one fork for Sonoma and earlier, the other for Sequoia only.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5274.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Apple’s software update servers are once again offering and providing updates to XProtect data for macOS Sonoma and earlier, as of about 0500 GMT today, 18 September 2024.
Software Update, the command tool softwareupdate, and SilentKnight should now be able to find XProtect version 5272, released on 28 August 2024, and install that for versions of macOS before Sequoia. I have verified this in both Sonoma and Monterey.
Although the update to version 5273 that was released on 16 September only for Sequoia 15.0 and later is still available, it remains unreliable. softwareupdate and SilentKnight report that both versions 5272 and 5273 are available, which is bizarre, and may then install either of them. If 5273 (or 5272) is installed into the local XProtect bundle, you can then get XProtect to ‘install’ it locally using the command sudo xprotect update. You may then end up with either version 5272 or 5273.
If you experience any difficulties with updating XProtect, please contact Apple Support so that they can report this within Apple.
macOS Sequoia 15.0 brings major change to the maintenance and updating of XProtect’s data. With the release of that new version of macOS, Apple has stopped providing any updates to XProtect data for previous versions of macOS, including the latest updates to Sonoma 14.7 and Ventura 13.7, also released yesterday.
Sequoia
If you have upgraded your Mac to Sequoia 15.0 or 15.1 beta, then it should be using XProtect data version 5273, released yesterday, 16 September 2024.
However, immediately after upgrading, the XProtect version may be given as 0, indicating that there’s no XProtect data installed at all. If that’s the case, or the version shown is 5272 or earlier, open Terminal and type in the following command: sudo xprotect update after which you’ll be prompted to enter your admin password. Once you do, the latest version of XProtect data should be obtained and installed correctly.
If you run SilentKnight after upgrading to Sequoia, it may find an XProtect data download waiting to be installed. If it does, install it. However, that doesn’t actually update the data used by this new version of XProtect. To complete that process, use the sudo xprotect update command in Terminal.
If you don’t use SilentKnight, you can check the current version of XProtect data being used with: xprotect version That should now return 5273. If it doesn’t, use the sudo xprotect update command to force an update.
Sonoma and all earlier macOS
With the release of Sequoia 15.0, Sonoma 14.7 and Ventura 13.7, Apple’s software update servers have stopped providing XProtect data updates to all versions of macOS prior to Sequoia. I have confirmed this in both Sonoma and Ventura. It’s not clear whether this is an error and Apple intends restoring XProtect updates in the future, or has simply stopped providing further updates.
The effect of this depends on the latest version of XProtect data installed on your Mac. If that’s 5272, then your Mac has the latest available without upgrading to Sequoia. If that’s any earlier version of XProtect, then there’s now no supported way for your Mac to be updated from that old version. As the XProtect bundle is located on the Data volume, you could try manually replacing the bundle (if you can get one for version 5272), but there’s no guarantee that will actually be used by XProtect, or make any difference to the protection it provides.
SilentKnight and Skint
The good news is that, if you use my free SilentKnight, and/or Skint, you should get the best information and help whichever version of macOS is running.
In anticipation of this, current versions of SilentKnight and Skint now report different versions for XProtect data depending on whether that Mac is running Sequoia or an earlier version of macOS. However, if the version found is earlier than 5273 (15.x) or 5272 (14.x and earlier), it will be reported as an issue. If Apple does restore XProtect data updates to macOS 14.x and earlier, then SilentKnight should be able to download and install them.
If your Mac is running Sequoia, SilentKnight can’t (yet) update XProtect data. To do that, you’ll need to run sudo xprotect update in Terminal.
Summary
The most recent version of XProtect data for Macs running Sonoma or earlier is 5272.
Currently, Apple’s update servers have stopped providing any updates to XProtect data for Sonoma and earlier.
Sequoia should be using XProtect data version 5273.
If your Mac is running Sequoia and has an older version, use the sudo xprotect update command to force an update.
Update
As of about 0530 GMT on 18 September 2024, XProtect updates for macOS Sonoma and earlier are available again, delivering version 5272 through Software Update, softwareupdate and SilentKnight. Fuller details are in a new article coming very shortly.
Apple has just released an update to XProtect for Sequoia only, bringing it to version 5273.
Apple doesn’t release information about what security issues this update might add or change. This adds Yara definitions for MACOS.DOLITTLE.CT, MACOS.SHEEPSWAP.CT and MACOS.SOMA.CT using a new format of rule, with each rule given a UUID and listing SHA256 hashes of file size.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5273.
If you’ve upgraded to Sequoia and are still stuck at a version number of 0 or 5272, you can either leave macOS to catch up with this in its own good time, or you can force an update by typing into Terminal sudo xprotect update
then entering your admin password.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
It’s strange to think that, as we’re wondering whether and when to upgrade to Sequoia, Apple’s engineering teams are already at work on macOS 16. While they’re thinking out what we’ll chew over next summer, you may well be asking if you should upgrade to 15.0 next week, wait for the AI features coming in 15.1 next month, or leave your decision until 2025?
For those with Macs and iPhones that can both be upgraded, iPhone Mirroring is probably the most obviously attractive new feature. It completes the integration of Continuity, and could transform your workflows. Fortunately for such a key feature, it should work with all supported Macs, not just Apple silicon models. There’s one small and temporary disappointment, though, as drag and drop between Mac and iPhone isn’t expected in 15.0, but in an update “later this year”.
The new Passwords app should spare you from wanting to pay for a third-party password manager. This is much more than just shelling out the existing Passwords feature from Safari and System Settings, and at last gives full control over passkeys and other shared secrets in your Keychain in iCloud.
Although some see Sequoia’s new dislike for apps that aren’t notarized (or from the App Store) as an unnecessary burden, for most of us this will raise the bar against running malware and increase our margin of safety. It has been some time since any malicious software has been successfully notarized, and most of the current epidemic of stealers aren’t even signed with a Developer certificate. Instead, they usually prompt the user to open them using the existing Finder bypass, something that no longer works in Sequoia without explicitly and individually giving permission to that app in Privacy & Security settings.
It will be interesting to see how malware developers respond to this challenge, as trying to give the user detailed instructions as to how they can be run without being blocked by Gatekeeper should now arouse the suspicion of even the most careless and inattentive.
While we’re on the subject of security, remember that Sequoia is now the only version of macOS that gets full security updates over the coming year. While Sonoma and Ventura will still get some, if you want the lot then you’ll need to upgrade. Monterey, of course, now gets none at all. This gets more brutal when considering other bugs that aren’t relevant to security: those will only be fixed in Sequoia, not even in Sonoma.
For those who virtualise macOS on Apple silicon, support for Apple ID gives VMs access to iCloud Drive at last, although it stops short of enabling the App Store or its apps, so isn’t as useful as it should have been. There are two important restrictions to this:
Apple ID can only be used in a Sequoia guest running on a Sequoia host, and
the Sequoia VM has to be built from a Sequoia IPSW file, and can’t be upgraded from a Sonoma or earlier VM.
As long as your Mac stays with Sonoma, you won’t be able to use Apple ID in any of its VMs, including Sequoia. This still leaves us with the paradox that Apple wants us to buy and run apps from its App Store, but VMs are the one place where you can’t use them.
Among the less prominent improvements that have caught my attention are a timed messaging feature of Send Later in Messages, and a batch of improvements in Freeform. If you’ve come to like that relatively new app, you should find Sequoia worth the effort. I’ve also been impressed to see one of the oldest bugs remaining in the Finder has finally been addressed in macOS 15. I’ll be putting the bunting out in celebration after I’ve upgraded on Monday.
As with Sonoma, some of the most important new features haven’t been documented even for developers. Among those are changes to XProtect in terms of its updating and management, and speculation as to how that might affect its function. As I have explained, XProtect’s detection rules have grown enormously over the last few months, and it’s likely that Apple intends improving how XProtect can apply its Yara rules, and making their updating more efficient.
Finally, Sequoia is almost certainly going to be delivered as if it were an update, and won’t download its installer app unless you’re upgrading from a significantly older version of macOS, just as has happened in all recent macOS upgrades. Remember that upgrading macOS these days comes with a one-way ticket: changing your mind afterwards will cost you a lot of time and messing about to step back to Sonoma. However, accidental upgrades shouldn’t be feared. For instance, if you inadvertently click the Install all updates button in SilentKnight and want to reverse that for a macOS update, let the download complete, shut down, start up in Safe mode, wait a minute, then restart in normal mode.
Whatever you choose tomorrow, I hope it works well for you. And in case you’re wondering, if you’ve got an Apple silicon Mac, you’re going to love 15.1.
Apple will release macOS 15.0 Sequoia on 16 September, that’s next Monday, alongside iOS and iPadOS 18.0, and upgrades and updates for lesser mortals. Among the latter are Sonoma 14.7 and Ventura 13.7, as I’ll explain later. Sequoia introduces two important changes to security data checked and updated by SilentKnight, for which I have built and notarized another new version of that app, 2.11, which is essential for anyone intending to upgrade to Sequoia, and worthwhile for all running Catalina or later.
What’s coming next week
Apple has just provided release candidates for the following three new versions of macOS:
Sequoia 15.0, its first full release,
Sonoma 14.7, its first security-only update,
Ventura 13.7, the first of its security-only updates for its final year of support.
There’s not expected to be any update to Monterey 12.7.6, which is no longer supported, even with security updates.
The minor version numbers of Sonoma and Ventura will then be the same, the first time this has happened. In previous release cycles, the start of the first year of security-only updates has been with x.6, as it was with Ventura, and proceeded through the year with versions x.6.1, x.6.2, and so on. Over the coming year, we can expect 14.7.1 and 13.7.1, then 14.7.2 and 13.7.2, continuing until Ventura reaches the end of its third and final year of support in a year’s time.
Sequoia 15.1, the first release with AI support, is now expected in October, and continues in beta-testing, alongside AI-enhanced versions of iOS and iPadOS in versions 18.1.
TCC in Sequoia
The TCC database in /Library/Apple/Library/Bundles/TCC_Compatibility.bundle was introduced in Mojave (when it had a different location, of course), and has been updated with each new major version of macOS since. That has now vanished, and I can find no trace of it, nor any apparent substitute. If you run SilentKnight 2.10 in Sequoia, that will be reported as an error, so version 2.11 addresses that by omitting that result both from its display box and the text report below.
XProtect in Sequoia
Since it was first introduced many moons and versions of macOS ago, there has been a bundle named XProtect.bundle in CoreServices, most recently in the path /Library/Apple/System/Library/CoreServices/XProtect.bundle, that has provided data for XProtect scans of executable code and other security services. That bundle has been updated frequently in downloads labelled XProtectPlistConfigData. Although that can still be present in Sequoia, XProtect now uses a completely different source for its data, that is normally updated through iCloud’s CloudKit rather than Software Update.
The result is that your Mac can have an up-to-date XProtect.bundle in the normal location, but XProtect itself may not be up-to-date at all. For example, in fresh installs of Sequoia, XProtect.bundle is usually absent, and the new tool to check its version may report a number of 0.
SilentKnight versions 2.10 and 2.11 have been updated to cope with this major change, which Apple has apparently not seen fit to document (yet). They check the correct current version using a new command tool, and report that version number faithfully. At present, though, SilentKnight isn’t able to update this new form of XProtect. You can either leave macOS to do that itself in its own time, or you can run a command in Terminal to force the update immediately: sudo xprotect update
following which you’ll need to authenticate with your admin user password.
I intend to address this more completely in SilentKnight version 3, but for the time being this is fully documented in SilentKnight’s Help book and Help Reference, in these latest versions.
SilentKnight, Skint, SystHist, LockRattler
SilentKnight version 2.11 is strongly recommended for anyone intending to update to Sequoia this year, and, as it also fixes a bug in reporting Studio Display firmware in VMs, is worthwhile for those remaining with Sonoma for longer. It’s available from here: silentknight211
from Downloads above, on its Product Page, and through its auto-update mechanism.
Thankfully, as Skint doesn’t check TCC, the current version 1.08 remains fully compatible with Sequoia. The current release of SystHist, 1.20, works well with Sequoia too, and usefully distinguishes between the two different types of XProtect update, XProtectPlistConfigData delivered through Software Update, and XProtectCloudKitUpdate the new one obtained through iCloud instead.
I don’t intend to update LockRattler for the time being. It won’t report the true version of XProtect, but does report that it can’t find TCC or the GKE data. Otherwise it should continue to function as expected in Sequoia.
More to come in Sequoia 15.0
These changes to XProtect are but one of the significant changes that Apple hasn’t yet mentioned. Once 15.0 has been released, I’ll be delighted to provide fuller details of others.
Summary
On Monday 16 September, Apple will release macOS 15.0, and security updates 14.7 and 13.7.
Monterey is no longer supported.
Download and install SilentKnight 2.11 if you’re intending to upgrade to Sequoia this year.
Skint and SystHist remain fully compatible with Sequoia.
Watch here for further news on Sequoia once it has been released next week.
Sequoia 15.1 with AI will be released next month (October).
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 145. The previous version was 142.
Apple doesn’t release information about what security issues this update might add or change. There are no changes in the number or names of its scanning modules, and Bastion rules also remain unchanged.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-145.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Over a series of three articles last week, I pored over thousands of log entries to examine how macOS Sonoma 14.6.1 checks applications it’s launching, under normal full security settings, with reduced security, and for known malware. This article draws together my conclusions from those tests run in virtual machines on an Apple silicon Mac.
Layered security
Like other security functions in macOS, app launch security is built in layers, including checks of
code-signing certificates (multiple times);
CDHashes, including their consistency, and against Apple’s database for notarized apps, and their revocation;
quarantine extended attributes, which normally trigger a user consent dialog, and may result in app translocation;
previous launch, in the LaunchServices database;
matches with Yara rules in XProtect’s data;
user consent to a first launch prompt dialog;
launch and other constraints.
Additional data may also be collected and stored in the provenance database that first appeared in Ventura.
Not all checks are performed on every launch of an app. At a minimum, for a notarized app that has been run only recently, these might consist of only local checks against CDHashes and with the app’s existing entry in the LaunchServices database. Checks are also modified by reducing security settings:
Disabling Gatekeeper checks doesn’t stop those checks from taking place, but apparently ignores some results, notably those obtained by XProtect. It doesn’t affect checks of CDHashes against Apple’s database.
Disabling SIP has more pervasive effects in largely disabling the com.apple.syspolicy sub-system, affecting several layers, although checks of CDHashes against Apple’s database are unaffected.
com.apple.syspolicy
In full security conditions, one sub-system dominates log entries concerning app launch security, com.apple.syspolicy. This is clearest in Gatekeeper and XProtect checks. Although the log entries that follow may appear bewildering, they are the best illustration of this point.
When launching a notarized app that hasn’t previously been run on that Mac and has a quarantine xattr, Gatekeeper and XProtect scans are reported in the following sequence of entries: com.apple.syspolicy.exec GK process assessment: <private> <-- (<private>, <private>)
com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy.exec queueing up scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec starting work for scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec allowUI is YES, creating codeEval object: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: (null)), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec Adding default exception for team: <private>
com.apple.syspolicy.exec Registered app bundle for protection: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.syspolicy.exec GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
com.apple.xprotect XProtectScan beginAnalysisWithResultsHandler continueOnError is set to 0
com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>
Those checks later complete in entries such as: com.apple.syspolicy.exec GK Xprotect results: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), XPScan: 0,-7676743164328624005,2024-08-26 08:19:01 +0000,(null)
com.apple.syspolicy.exec GK scan complete: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
com.apple.syspolicy.exec scan finished, waking up any waiters: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
com.apple.syspolicy.exec App gets first launch prompt because responsibility: <private>, <private>
com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
com.apple.syspolicy.exec GK eval - was allowed: 1, show prompt: 1
com.apple.syspolicy.exec Skipping TCC check due to process: 692, 0, 692
com.apple.syspolicy Found console users: <private>
com.apple.syspolicy.exec Prompt shown (5, 0), waiting for response: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
When SIP has been disabled, there are precious few entries from com.apple.syspolicy or com.apple.syspolicy.exec. Instead, XProtect appears to be left to its own devices, and doesn’t fare well: com.apple.xprotect XPAssessment performAnalysisOnFileImpl continueOnError set to 0
com.apple.xprotect XprotectService Calling SecAssessmentCreate with URL <private>, context <private>
XprotectService SecTrustEvaluateIfNecessary
com.apple.xprotect XprotectService Bundle is not apple signed
com.apple.xprotect XprotectService Bundle size result: 18388222 (YES)
com.apple.xprotect XprotectService Always scan: YES
com.apple.xprotect XprotectService Starting malware scan for: <private>
kernel XprotectService [697] crossed memory high watermark (15 MB); EXC_RESOURCE
kernel Full corpse enqueued for XprotectService
com.apple.xnu memorystatus kernel kernel EXC_RESOURCE -> XprotectService[697] exceeded mem limit: ActiveSoft 15 MB (non-fatal)
ReportCrash event condition bump 0 -> 1
ReportCrash post-exception thread qos drop 21 -> 17
ReportCrash PID 697 exceeded the memory high watermark; Invoking ReportMemoryException with corpse.
There are no other entries referring to Gatekeeper or those checks. The effects of disabling SIP appear extensive and pervasive throughout several of the layers of app launch security.
CDHashes are central
With the adoption of notarization, apps run in macOS should now fall into one of five categories:
signed by Apple, either its own apps or those delivered through its App Store;
notarized by Apple, with its CDHashes added to Apple’s database;
signed (either with a Developer certificate, or ad hoc) locally, and not distributed over the internet, with its own unique CDHashes;
unwanted or malicious, with revoked CDHashes,
unrecognised, and potentially malicious.
These emphasise the importance of the online ‘notarization’ checks of CDHashes performed in all circumstances where macOS doesn’t have previous records of saved CDHashes for that code. Their primary purpose isn’t to validate notarization, but to identify code as known good, known bad, or unknown. When Apple’s security engineers identify new malware, its CDHashes can quickly be added to the database as being revoked, so ensuring that all subsequent checks of the same CDHash will be classified as revoked, for malicious code. This is a rapid response that should have no false positives, in which benign code is mistakenly identified as being malicious.
Typically, the checking sequence is reported in the log with: com.apple.syspolicy looking up ticket: <private>, 2, 1
com.apple.syspolicy cloudkit record fetch: <private>, <private>
com.apple.syspolicy cloudkit request cache info: <private>, max-age=300
com.apple.syspolicy CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
com.apple.syspolicy Inserting ticket: <private>
com.apple.syspolicy completing lookup: <private>, 0
[and so on with further lookups]
and those are among the only entries from com.apple.syspolicy seen when SIP is disabled.
When full security is enabled, those are completed with com.apple.syspolicy.exec GK evaluateScanResult: 0, PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist), 1, 0, 1, 0, 4, 4, 0
But when SIP is disabled, those don’t appear, and seem to be substituted by application of Security rule 11 instead.
The downside of CDHash checks is that their false negative rate can be alarmingly high. Change a single bit in the code being hashed, and the hash will amplify that change, and is completely different. Hence the importance of notarization to establish which CDHashes definitely aren’t from malicious code.
One threat to this system occurs when a user mistakenly blocks their Mac from connecting to Apple’s database using CloudKit, for example using a misconfigured software firewall. Without a suitable vulnerability, malicious software shouldn’t be able to use this approach to block a payload from being checked.
I don’t know whether any third-party security products use a similar checking mechanism with their own local or remote CDHash databases, but this appears to be a great advantage to the protection built into macOS.
Performance
Two of the checks performed with full security enabled are dependent on the size of the app being checked. Fully validating an app’s CDHashes against those in its signature or notarization ticket should benefit from hardware acceleration, particularly on Apple silicon, and can be tackled hierarchically. It appears unlikely to result in significant delays to launching an app.
XProtect scans are more likely to be responsible for observable delays in app launch times, though. With the recent growth in the number of Yara rules, and their length, scans performed after an app’s first launch are the most probable cause of large and complex app bundles requiring several seconds before the app can be run.
Summary
I have updated the flow chart I first proposed as a result of observations made of app launches in Sonoma 14.4.1:
If XProtect Remediator came of age in macOS Ventura, then it has been XProtect’s turn in Sonoma. Starting from version 2171 with 216 rules in under 3,000 lines in its Yara definitions, it emerged a year later in version 5272 with 347 rules in over 13,000 lines, although mercifully not after 3,100 versions.
I had always assumed that those Yara rules were compiled straightaway into something more tractable for checking executable code, but it seems that each time XProtect performs one of its ‘direct malware and dylib scans’, it first looks for a non-existent Yara file, then uses the rules in the XProtect.bundle, as it reports in the log: com.apple.xprotect Xprotect is performing a direct malware and dylib scan: <private>
com.apple.xprotect Rule path is not accessible: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect2.yara
com.apple.xprotect Using XProtect rules location: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara
Apparently, to cope with this explosive growth, and potentially support more frequent tweaks to its growing horde of Yara rules, macOS Sequoia is changing the way that XProtect’s data is updated and managed. A chance find by @L0Psec revealed how this has moved beyond those updates delivered by softwareupdate, and a new command toolxprotect handles this separately in CloudKit.
Last week’s update to XProtect’s Yara file was an experience those beta-testing Sequoia 15.0 or 15.1 must have found profoundly confusing, and I quickly became aware of reports that were changing by the minute.
When XProtect 5272 was first made available through softwareupdate, Sonoma and earlier systems found and installed it as usual, as did some running Sequoia betas. That updated the visible XProtect.bundle in CoreServices, but didn’t update XProtect according to its new xprotect command tool, which still reported the local version of XProtect as 5271. Without knowing how XProtect has changed, the user would most likely see this as a bug.
A little later, I saw reports of Sequoia installations apparently updating spontaneously via CloudKit, using its new mechanism, which did change the version reported by xprotect version.
At this stage, I had a 15.0 virtual machine that had updated ‘correctly’ via CloudKit, and its host 15.1 system that had updated its bundle via softwareupdate, but still wasn’t apparently running the new version afterwards. Those of us who didn’t experience a spontaneous CloudKit update were left in limbo. I had originally changed the version databases used by SilentKnight and Skint to show a correct version of 5272 for Sequoia, and hurriedly had to revert that to 5271 before I became inundated with complaints from those whose Macs hadn’t been able to update.
It then occurred to me to try using the xprotect command to force a CloudKit update on my 15.1 system. I first entered sudo xprotect check
only to be told that the version available was still 5271. But when I ran sudo xprotect update
a miracle happened, with the response Update succeeded: Activated update LocalUpdate[5272]
That command had convinced macOS to ‘activate’ the updated bundle in /Library/Apple/System/Library/CoreServices rather than waiting for it to become available from CloudKit, a feature not mentioned in its man page or usage info. I returned to my version databases to change them a third time, back to 5272.
Previous XProtect updates such as 5271 that were obtained through CloudKit are now identified by SystHist as XProtectCloudKitUpdate, while those obtained by softwareupdate and activated using the xprotect command appear as standard XProtectPlistConfigData, as they do in Sonoma and earlier.
With the release of Sequoia due later this month, the xprotect command tool and XProtect’s new CloudKit updates have already encountered troubled water. If Apple stays true to form and doesn’t mention a word about this change, or its effect on XProtect updates, many of the millions of new Sequoia users could end up falling behind. But as we’re not supposed to know what the latest version is, nor which is currently active on our Macs without taking to Terminal’s command line, maybe most won’t be allowed to notice.
I’d like to think that Apple will explain these changes to users, document its new command tool properly, and ensure that users know the current version of XProtect data, and can check whether their Mac is up to date without having to resort to Terminal or third-party products, perhaps in System Information. Will I be disappointed?
Previous articles in this series described how macOS 14.6.1 security systems check the launch of apps when full security is in force on an Apple silicon Mac, and how those are changed by disabling SIP and Gatekeeper checks. Those have shown how checks are layered in accordance with the Security architecture of macOS, how different layers are invoked according to the status of an app (whether it’s quarantined, notarized, or has been run previously), and how extensive are the effects of disabling SIP. But no account of app security can be complete without examining how it protects against real malware, the aim of this article.
Methods
In these tests, I have again run four variants of the same 14.6.1 VM:
Full Security, with SIP and Gatekeeper/XProtect enabled;
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
Samples of malicious software were obtained from the Objective-See Foundation’s collection. Three were chosen:
Atomic Stealer (AMOS, or Soma)
Genieo (InstallMac)
XCSSET
These were downloaded directly to each of the four VMs, when they were running in isolation in ViableS. Each was then unZipped and the contents moved to the Documents folder to try to ensure that their code wouldn’t be subjected to app translocation. Full log extracts were obtained from the Full Security VM for the first 5 seconds after launching Atomic Stealer and XCSSET; as the Genieo sample only installed its payload and didn’t launch its code, no log record was obtained for that. Log records weren’t obtained for the other three VMs, although the results of running the malicious payloads were observed for comparison against those of the Full Security VM.
Atomic Stealer
This was presented in a disk image that hadn’t been signed by a Developer certificate, and encouraged the user to try to bypass full Gatekeeper checks by opening the malicious payload CardGame.app using the Open command in the Finder’s contextual menu, a common strategy adopted by malware developers. This ruse was spotted early as a security exception with the code -67062, indicating that the disk image was unsigned, and that resulted in the app being translocated in its disk SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/CardGame.app
This appears to be a less usual cause of translocation, although strictly within its rules.
AMFI quickly found a code signature issue, as reported by the kernel AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app' has no CMS blob?
AMFI: '/private/var/folders/s0/[…]/CardGame.app/Contents/MacOS/My Go Application.app': Unrecoverable CT signature issue, bailing out.
AMFI: code signature validation failed.
Gatekeeper and XProtect scans followed, and the CDHashes were checked with Apple’s database over CloudKit. This discovered that one of the hashes had been revoked Notarization daemon found revoked hash: {length = 20, bytes = 0xe430ea6d59a70ac00c1b8552092f4de0bbb80232}
resulting in another security exception, this time of -66992, confirming that this code has been revoked. That check was then repeated with the same result.
Shortly after that, the XProtect scan was completed, finding a match for Atomic Stealer A GK Xprotect results: PST: (vuid: 11F66D42-5827-3465-A741-F434860C2862), (objid: 20), (team: (null)), (id: (null)), (bundle_id: (null)), XPScan: 11,-7676743164328624005,2024-08-27 07:31:10 +0000,MACOS.SOMA.A
and the decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=2F90B5EF-D483-43C7-BBD1-77E8EABF4D62, info.ident=8D56578B-833F-4629-86F0-4E0A8EDD7D49, info={<private>}
indicating that it’s game over for the CardGame app and its disk image.
This sample of Atomic Stealer was thus detected by two different and independent methods: its CDHash ‘notarization’ check revealing its revocation, and the XProtect scan matching it to the known signature of MACOS.SOMA.A. As the first of those is unaffected by disabling SIP or Gatekeeper, it’s not surprising that the sample was detected and blocked in each of the four VMs.
Genieo
This was presented in an Installer package as an Intel binary. This claimed to install “Apple software” and triggered a request to download and install Rosetta 2 if that wasn’t already available. The installer appeared to complete without eliciting any warnings, and it’s presumed that the malware would either have been detected later when there was an attempt to launch it, or in an XProtect Remediator scan.
All four VMs behaved identically, and there was no sign of recognition that the software installed might be malicious. This raises questions about the security inherent to Installer packages and whether there might be exploits available using Intel binaries in Rosetta 2, given that it resigns translated executable code.
XCSSET
This was presented in a bogus app named Xcode. Attempting to run that resulted in its detection, and the invitation to remove it, in this case without it being positively identified.
As this was presented as an app containing unsigned code, that came under suspicion early during its assessment, and it was translocated even though it had been moved from its original location SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/s0/[…]/Xcode.app
That appears to have occurred beyond previous rules for translocation.
Gatekeeper and XProtect scans followed, and it was confirmed that the code was unsigned Error Domain=NSOSStatusErrorDomain Code=-67062
Unsigned code in: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 81906), (team: (null)), (id: (null)), (bundle_id: (null))
CDHash checks using CloudKit didn’t find a match, and were simply reported as ticket not available: <private>
Gatekeeper’s scan reported that the app didn’t contain a bundle, but XProtect found no match with current Yara rules. The decision was made to present the malware warning prompt present prompt: uid=501, conn=yes, type=Malware, op.ident=A66F9ED6-EDE7-48E9-B1F8-74CB77C43C9E, info.ident=39D1FBB5-2620-483B-AD3C-6FC5118A406F, info={<private>}
and the attempt to launch the app was blocked.
As these traits would still be detected with SIP and Gatekeeper disabled, all four VMs blocked the code and displayed the same alert to the user.
Limitations
In reality, it’s common for attacks to consist of the initial download of a small dropper, which in turn downloads the main payload. One of the disadvantages of testing malware samples is that this presentation of the payload can’t be taken into account. Payloads are often downloaded using methods that escape quarantine. Another significant difference is that samples often lack code signatures that may be present in the originals, and may change frequently as Developer certificates are revoked and replaced.
Detection information
There appears to be almost no information on how macOS detects different groups of malicious software. Inevitably, Apple provides none at all, and few in-depth analyses of malware give any details about its presentation, in terms of any signatures used, and whether they or CDHashes have since been revoked by Apple. This is a difficult area, given that many of those who analyse and report on malware work for vendors of security products. There appears to be a valuable role for independent assessment of whether and how detection takes place in macOS, major factors in any risk assessment.
I’d like to express my gratitude to the Objective-See Foundation for collecting and making available its extensive library of malware samples, without which none of these tests would have been possible.
Apple has just released an update to XProtect for all versions of macOS from El Capitan or so, bringing it to version 5272. Apple has now released this for Sequoia betas as well, using their new update mechanism.
Apple doesn’t release information about what security issues this update might add or change. This makes a small amendment in the Yara definitions to the detection signature for MACOS.d98ded3, and adds another rule to those to detect MACOS.DOLITTLE, in MACOS.DOLITTLE.DOFSTRGT.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5272.
If you’re running a Sequoia beta and are still stuck at 5271, don’t worry if sudo xprotect check
doesn’t offer you the update to 5272. Ignore it and run sudo xprotect update
and with any luck it will update your Mac to 5272.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
In the first of these articles, I examined security aspects of the process of launching various app configurations in macOS Sonoma 14.6.1, on an Apple silicon Mac with full boot security and other security settings. This article moves on to discover how those change when boot security and security settings are reduced. Full details of how this was done are given in the previous article.
To remind you, the apps used were:
SystHist – notarized, quarantined, moved from its landing folder to avoid app translocation;
SilentKnight – notarized, not quarantined, previously run;
Sparsity – notarized, not quarantined, not previously run;
DelightEd3 – not notarized, signed with a Developer certificate, not quarantined, not previously run;
DelightEd3resigned – not notarized, ad hoc signed, not quarantined, not previously run.
None of the apps run in an app sandbox, and those notarized use a hardened runtime.
This article covers these three variants of the same 14.6.1 VM:
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
In each VM, settings were confirmed using SilentKnight, which in turn calls standard system tools to determine current security settings, such as those when both SIP and Gatekeeper were disabled.
Gatekeeper disabled
Surprisingly, with Gatekeeper assessments disabled, com.apple.syspolicy.exec still reported that Gatekeeper assessments were made GK process assessment: <private> <-- (<private>, <private>)
Gatekeeper assessment rooted at: <private>
and later queueing up scan for code: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 69229), (team: (null)), (id: (null)), (bundle_id: (null))
GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 69229), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
Following that, XProtect scanned XPAssessment performAnalysisOnFileImpl continueOnError set to 0
Xprotect is performing a direct malware and dylib scan: <private>
using its standard Yara rules.
CloudKit ticket lookup also proceeded as normal. After a while, though, XProtect announced Xprotect is skipping executable assessment: <private>
The normal prompt for user consent was displayed, and handled as expected. Following that, launch proceeded normally.
Similar entries appeared in the checks made on all apps that had undergone Gatekeeper and XProtect assessment when full security was in force. There is nothing in the log entries to indicate that disabling Gatekeeper had any effect on the checks that were made, although as none of these apps failed assessment, it’s possible that any failures would have been ignored.
SIP disabled
When SIP was disabled, the structure of pre-launch assessments changed, and appeared disordered in comparison to those performed under full security and with only Gatekeeper disabled. Most notable, perhaps, was the almost complete absence of log entries from the com.apple.syspolicy subsystem, which in full security is so prominent, although its service syspolicyd did appear in entries.
Although quarantine was recognised, no entry reported the start or conclusion of any GK (Gatekeeper) assessment, nor subsequent XProtect scans. Instead, the XProtect service wrote Bundle is not apple signed
Bundle size result: 18388222 (YES)
Always scan: YES
Normal ticket checks were made via CloudKit, but shortly after those were completed, XProtect tried to use its standard Yara rules, and ran out of memory doing so, with the kernel reporting process XprotectService [697] crossed memory high watermark (15 MB); EXC_RESOURCE
XProtectService therefore ran into trouble before it had even started to scan the app. While some entries suggested prompting the user for their consent, that doesn’t appear to have happened. Eventually the app launched in spite of the disorder that had preceded.
When launching a notarized app that wasn’t quarantined, neither Gatekeeper nor XProtect appear to have had any involvement in the approval of the launch.
SIP and Gatekeeper disabled
Results were essentially identical to those obtained with SIP alone disabled, even down to XProtectService exceeding its memory high watermark, and the almost complete absence of log entries from the com.apple.syspolicy subsystem.
SIP and Gatekeeper settings
Prior to examining these log records, I thought I had a clear idea as to what these two controls do. In fact, neither of them does what you’d expect.
Disabling Gatekeeper or XProtect checks doesn’t stop them from occurring, although it might result in macOS ignoring any errors they might find. That would be consistent with the statement in the spctl man page: “Operations that would be denied by system policy will be allowed to proceed; assessment APIs always report success.”
On the other hand, disabling SIP almost completely stops the whole com.apple.syspolicy subsystem, which ordinarily plays a major role in pre-launch checking of apps. This effectively kills both Gatekeeper and XProtect, leaving those checks in disarray. When the XProtectService tries to lend a hand, its attempt to ingest the current Yara rules runs it out of memory, and it appears unable to render any useful assistance to the pre-launch checks.
This may explain why disabling SIP has the effect of shortening the time to launch an app, most noticeably with larger and more complex apps. In return for launching in a shorter time, the app probably isn’t checked against XProtect’s Yara definitions, so could still contain malicious code that would pass undetected.
In the next article I’ll show what does happen when this system encounters live malware.
This is the first of a series of three articles that look in detail at the launch process of apps in macOS Sonoma 14.6.1, with the emphasis on security checks. This follows my earlier look in 14.4.1, and covers a wider range of situations, including the effects of disabling SIP and Gatekeeper, and how known malicious software is handled.
Methods
All tests were performed in a series of Sonoma 14.6.1 virtual machines (VMs) running on a Mac Studio M1 Max host, also running 14.6.1. VMs are preferred as they enable a consistent environment and easy control of boot security and security settings, together with relatively low rates of log entries. Log extracts were obtained using Ulbow and analysed in their entirety for the first 5-7 seconds after launching apps in the Finder.
Apps used were:
SystHist – notarized, quarantined, moved from its landing folder to avoid app translocation;
SilentKnight – notarized, not quarantined, previously run;
Sparsity – notarized, not quarantined, not previously run;
DelightEd3 – not notarized, signed with a Developer certificate, not quarantined, not previously run;
DelightEd3resigned – not notarized, ad hoc signed, not quarantined, not previously run.
None of the apps run in an app sandbox, and those notarized use a hardened runtime.
Four variants of the same 14.6.1 VM were run:
Full Security, with SIP and Gatekeeper/XProtect enabled;
Full Security, with Gatekeeper/XProtect disabled;
Permissive Security, with SIP disabled;
Permissive Security, with both SIP and Gatekeeper/XProtect disabled.
All had bridged network access to the network and internet, and shared folders with the host, when running these non-malicious apps.
This article describes what happens in the log in the first of those conditions, full security with both SIP and Gatekeeper/XProtect enabled.
Quarantined notarized app
This underwent the fullest checks of these tests. Once LaunchServices announces that it’s opening the app, the following sequence of events is recorded.
CDHashes from the app are copied, here only those for the Arm architecture. As the app is unknown, it’s next registered with LaunchServices. Gatekeeper assessment is then started just 0.07 seconds after announcement of the launch, in the log entry GK process assessment: <private> <-- (<private>, <private>)
com.apple.syspolicy.exec then starts work on scanning for code, followed by the first mention by LaunchServices that the app is quarantined.
The Gatekeeper scan is announced in GK performScan: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
followed by the XProtect scan in Xprotect is performing a direct malware and dylib scan: <private>
and assignment of the risk category according to its quarantine QUARANTINE: Setting risk category to LSRiskCategoryUnsafeExecutable
XProtect states the Yara rules it’s using Using XProtect rules location: /Library/Apple/System/Library/CoreServices/XProtect.bundle/Contents/Resources/XProtect.yara
com.apple.syspolicy next processes the app’s notarization ticket looking up ticket: <private>, 2, 1
by trying to fetch its record using CloudKit. That’s followed by entries indicating the network access required to connect with iCloud and check the ticket. Success is reported by com.apple.syspolicy in CKTicketStore network reachability: 1, Mon Aug 26 09:15:45 2024
looking up ticket: <private>, 2, 0
and further lookups.
A little later, Gatekeeper announces the XProtect results GK Xprotect results: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), XPScan: 0,-7676743164328624005,2024-08-26 08:19:01 +0000,(null)
and its scan is complete GK scan complete: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: (null)), (bundle_id: (null)), 4, 4, 0
Because this is the first launch of a quarantined app, com.apple.syspolicy.exec decides it gets a first launch or “code-evaluation” prompt “because responsibility”. If the user gives approval, the app is allowed to proceed. Its quarantine flag is updated, and the bundle record registered as trusted. The final step is then to create and save its provenance data Created provenance data for target: TA(e8217440d9326f59, 2), PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
Handling provenance root: TA(e8217440d9326f59, 2)
Wrote provenance data on target: TA(e8217440d9326f59, 2), PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 62947), (team: QWY4LRW926), (id: co.eclecticlight.SystHist), (bundle_id: co.eclecticlight.SystHist)
Putting executable into provenance with metadata: TA(e8217440d9326f59, 2)
Putting process into provenance tracking with metadata: 692, TA(e8217440d9326f59, 2)
Tracking process with attributes: 692, TA(e8217440d9326f59, 2)
Without quarantine
A notarized app that hasn’t been run previously on that system and isn’t quarantined undergoes a similar sequence, but without the first launch or “code-evaluation” prompt. Its bundle record is registered as trusted, rather than being classified as an Unsafe Executable, but it still gets a full XProtect scan and ticket lookup using CloudKit.
Subsequent launches
The briefest launch process is that for an app that has only recently been run. That appears to skip Gatekeeper and XProtect assessments, and there’s no ticket lookup either. Pre-launch processes can then take less than 0.1 second.
Launching a known app following a cold boot can be as quick, although in this case there is a brief Gatekeeper assessment reported in the log. The key entry here comes from com.apple.syspolicy.exec: Code already evaluated, using results.
Those are checked by Gatekeeper before launch proceeds, with the kernel reporting evaluation result: 2, exec, allowed, cache, 1724654056, 4, c0a2e35c20a69dfd, /Applications/SilentKnight.app
Signed with developer certificate
An unquarantined app that isn’t notarized but is correctly signed using a Developer certificate is similar to its notarized equivalent, except that looking up the ticket using CloudKit is of course unsuccessful. Repeated attempts are made to find it, though, before going on to check “the legacy list” and check “legacy policy”. This results in the decision Match downgraded from DevID to None based on legacy policy for: PST: (vuid: 7C5C43BF-A338-4228-B61E-5038F1D93EDB), (objid: 60118), (team: QWY4LRW926), (id: (null)), (bundle_id: (null))
but the kernel decides to allow launch to proceed evaluation result: 6, exec, allowed, cache, 1724660700, 0, 9576bac3e248c07b, /Applications/DelightEd3.app
Ad hoc signature
This is detected early during pre-launch checks by AMFI (Apple Mobile File Integrity), despite the bundle record being registered as trusted. The kernel reports AMFI: '/Applications/DelightEd3resigned.app/Contents/MacOS/DelightEd' is adhoc signed.
AMFI then records No certificate chain found
Failure getting cert chain
Basic requirement validation failed, error: Error Domain=NSOSStatusErrorDomain Code=-67050 UserInfo={SecCSArchitecture=<private>}
and an error code of -423, given as “The file is adhoc signed or signed by an unknown certificate chain”.
Despite that, Gatekeeper assessment continues, with an XProtect scan. Attempts to look up the app’s ticket inevitably fail despite many attempts, and an error code of -67018 “Code did not match any currently allowed policy” is awarded. Launch then proceeds.
In the next article I’ll show how those are affected by disabling SIP and Gatekeeper assessments.
Apple has just released an update to XProtect Remediator security software for Catalina or later, bringing it to version 142. It appears this version was first released over 12 hours ago, early in the morning GMT, but was then removed from Apple’s update servers. It has just now been made available again.
Apple doesn’t release information about what security issues this update might add or change. For the first time since its release, this update removes a scanning module, for RedPine. Bastion rules remain unchanged.
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 SilentKnight, LockRattler and SystHist for El Capitan to Sonoma available from their product page. If your Mac has not yet installed these updates, you can force them using SilentKnight, LockRattler, or at the command line.
If you want to install this as a named update in SilentKnight, its label is XProtectPayloads_10_15-142.
I have updated the reference pages here which are accessed directly from LockRattler 4.2 and later using its Check blog button.
Login
Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s 
