It’s essential to know when an authentication request is genuine. Without that knowledge, it’s all too easy to give your password away to malware, or to a badly-behaved app that’s trying to work around macOS security rules. By far the best way to authenticate now is using Touch ID, but many Macs don’t support it, either because they can’t, or because their keyboard doesn’t, and macOS doesn’t always offer it anyway. This article looks at how you can recognise genuine requests.

All Macs

The traditional non-biometric dialog is still in widespread use, and can appear on any Mac, even when Touch ID is available, and in Sequoia. I’ve been trying to work out a simple rule to predict when you should expect to see a classic request, and it appears to be associated with more traditional apps like Keychain Access, and when asking to access a file-based keychain such as the login keychain. But there don’t appear to be any simple and robust rules.

When an app needs to access a secret that requires authentication, the security system, not the app, displays a dialog asking you for the password to that keychain to authenticate before it will provide the password or other secret to the app.

That authentication dialog is very important: although malware might try to forge it, it contains distinctive features you should always look for:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component that has asked to access the keychain.
• The bold text names the app or component that has called for keychain access, and states which item it’s asking to access: here, a named secure note.
• The smaller lettering specifies that it’s asking for the keychain password, that is the password used to unlock the named keychain, not that for your Apple Account or any other password.
• If you’re in any doubt about its authenticity, click on the Deny button and the request will be denied.
• If you’re in any doubt about its authenticity, open Keychain Access, lock the keychain there, and repeat the action while watching the keychain to ensure that it’s unlocked and handled correctly.

Note that this doesn’t provide or ask for your user name, only the password for that keychain.

Macs without Touch ID

If Touch ID isn’t currently available to your Mac, either because it doesn’t support it, or because it doesn’t have a keyboard connected that includes Touch ID support, you should see the non-biometric versions of other dialogs requesting authentication. These are for purposes other than keychain access that require elevated privileges, such as for a process to run a privileged helper, or to make changes in System Settings.

This new vertical format should contain the following:

• The icon consists of a locked padlock, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Enter your password to allow this.
• There are two text boxes, to contain your user name (already completed) and password.
• There are only two buttons, one of which may be OK or something more specific, and the other is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

Macs with Touch ID

If your Mac supports Touch ID (all Intel Macs with T2 chips, and all Apple silicon Macs), and currently has a keyboard connected to it with support for Touch ID, macOS should offer you the biometric version of that authentication dialog.

This should contain the following:

• The icon consists of a Touch ID fingerprint, on which is superimposed a miniature icon representing the app or component that is asking for your password.
• Bold text names the app making the request.
• Below that is a general indication of the purpose of the request.
• Below that is the instruction to Touch ID or enter your password to allow this.
• There are only two buttons, the upper being Use Password…, and the lower is Cancel.
• If you’re in any doubt as to its authenticity, click on the Cancel button to deny the request, and consult the app’s documentation.

This dialog has distinctive behaviour that’s difficult to forge. When you place your fingertip on the Touch ID button on the keyboard, it will either authenticate successfully, so dismissing the dialog, or the dialog shakes to indicate you should try placing your fingertip on the button again.

If Touch ID authentication fails, or you click on the button to Use Password…, the dialog expands to resemble the non-biometric version above, with the following two important differences:

• The icon still consists of a Touch ID fingerprint, with a superimposed miniature icon representing the app or component.
• The instruction remains to Touch ID or enter your password to allow this.

Although you will continue to encounter classic non-biometric authentication dialogs on a Mac with full Touch ID support, you may also come across some that you might have expected still to use the old dialog, but which now use a biometric dialog, such as that below.

Perhaps as Touch ID support extends this will become more consistent.

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.

I maintain lists of the current versions of security data files for Sequoia on this page, for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

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 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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

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.

Thanks to Joe for reporting this.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Updated 17 September 2024 making it clear this update is only for Sequoia.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.

Updated with details of Sequoia beta update at 1902 GMT 28 August 2024.

Reviewing security products intended to detect and remove malicious software is far harder than it used to be. There was a time when all you had to do was set your virtual machine to Reduced Security, disable SIP, and maybe Gatekeeper too, then strip any quarantine extended attributes from samples of recent malware. With nothing to trigger checks by macOS security, the malware was fully exposed to the security software under test, and you could assess how successful the product was at detection.

Yet in Sonoma it seems that you also need to disable AMFI (Apple Mobile File Integrity), or macOS will intervene to detect the malware before the product under test, which then won’t get a look-in.

Back in Sonoma 14.4.1 I summarised those layers of checks in this diagram.

Although it’s encouraging that malware detection is now so pervasive, this makes it almost impossible to assess the other side of an anti-malware product, how well it can remove the malicious software it discovers. The same applies to Apple’s own XProtect Remediator. Stunting and tricking macOS to the point where malware can deploy fully isn’t anywhere near as easy as it was.

You know you have failed again when macOS pops up an alert like this, telling you that it has intercepted your attempt to bypass its protection.

From a user’s point of view, this can only be good. macOS security protection is designed and applied in multiple layers so that, even if something manages to trick its way past one check, the next layer is there to stop it in its tracks.

The strangest thing about XProtect Remediator isn’t the fact that, left to its own devices, it doesn’t inform the user when it detects malware, but that it will happily remove the malware it detects and let you carry on using your Mac as if nothing had happened. If you’re as old school as me, you might wonder why you shouldn’t have to wipe your Mac completely, restore it in DFU mode if an Apple silicon model, and rebuild it from scratch. Surely the slightest suspicion of anything malicious demands such a scorched earth approach?

That too depends on what security protection your Mac has active. If that includes SIP and the SSV, then there’s no known malware that can alter anything on the SSV, and what it can do on your Data and other volumes is also limited. The days of viruses wreaking havoc throughout your entire Mac thankfully seem long since past. Viruses, of course, were designed to replicate themselves throughout a Mac’s storage, but today’s trojans and stealers are after two things, and those are your secrets and money.

But that depends on the behaviour of potential victims of malware. Like any business, those who try to profit from theft of our secrets and other malicious behaviour have to consider the size of their market of victims. For many years, this was one of the Mac’s defences against malware: why would anyone want to develop for such a small proportion of potential victims, when PCs readily provided far more? More recently, some have unfortunately recognised our potential, and now we’re suffering the consequences.

This is where standard macOS security protection comes into play. At present, the great majority of Macs running Big Sur or later have SIP enabled and their SSV fully protected. The victim market for malware requiring write access to the System volume is tiny. But what if it became more usual for Macs to be unprotected, and all that malware had to do was gain root privileges to be able to write to the System volume?

This is a phenomenon akin to vaccination and resulting herd immunity in pandemics like Covid. States and nations with low protection by vaccination and little herd immunity suffered the highest rates of infection and consequent death rates. But so few realised that exercising their personal choice to remain unvaccinated had that effect, despite the fact that humans throughout the world had eliminated the deadly disease of smallpox by building herd immunity in the late twentieth century.

Security protection in macOS works in layers. Each layer you disable opens wider the window of opportunity for attackers. The more Macs that have any given layer of protection disabled, the lower the herd immunity to attack, and the more likely that malware will try to take advantage of that.

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.

I maintain lists of the current versions of security data files for Sonoma on this page, Ventura on this page, Monterey on this page, Big Sur on this page, Catalina on this page, Mojave on this page, High Sierra on this page, Sierra on this page, and El Capitan on this page.