Launching apps in Sonoma 14.6.1: Known malware

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.