Apple's notarization process exists to answer one question before a Mac ever runs a downloaded app: has someone at Apple scanned this and found nothing obviously malicious? A notarized app shows no warning. Gatekeeper lets it run. For years that made notarization a reasonable, if imperfect, signal of safety.

In July 2025, Jamf Threat Labs published findings that undercut that signal directly for one of the most prevalent current macOS threats: a sample of Atomic Stealer (AMOS), the commodity information-stealer-as-a-service that has become the dominant macOS infostealer, had been successfully notarized by Apple.

[INFO]
This article summarises public reporting from Jamf Threat Labs and Sophos. It makes no own-data claims; no sample analysis, account age or infection count below is this site's own research.

//What Jamf Found

Jamf reported that at least three distinct macOS infostealer samples were signed and notarized under the same Apple Developer Team ID, and distributed in the wild afterward. The sample at the centre of the report was a bundle called Gmeet_updater.app - a fake Google Meet updater, which Jamf described as a sloppy repackaging job rather than a sophisticated bypass.

Jamf reported the Developer Team ID to Apple. The associated certificate appears to have since been revoked, according to Jamf's account.

Notarization abuse is not a Gatekeeper exploit

It is worth being precise about what this is and is not. Nothing here describes bypassing Gatekeeper's checks or forging a notarization ticket. The attackers submitted real malware to Apple's real notarization service under a real developer account, and the service did not catch it. That is a detection failure, not a cryptographic one - the equivalent of a guard checking IDs at the door and being handed a genuine ID for a different, disguised person.

That distinction matters for the defensive takeaway: there is no patch for this. Apple can revoke the specific certificate once reported, as it appears to have done here, but the notarization process itself still depends on scanning catching malware it has not seen before, and a disposable developer account is cheap to replace.

//How Big a Problem AMOS Is

Sophos reported that AMOS accounted for almost 40 percent of its macOS protection updates in 2025 - a measure of how much of its detection activity on the platform that single malware family represented, not a count of infected machines. Sophos describes AMOS as malware-as-a-service that targets Keychain data, browser-stored credentials, cookies, autofill data and cryptocurrency wallet data.

Distribution leans heavily on social engineering rather than technical exploitation. Sophos and other researchers have reported ClickFix-style lures as an increasingly prominent infection vector for AMOS specifically: a fake error message or CAPTCHA that instructs the visitor to open their own terminal and paste a command, which does the work a browser exploit used to do. Other campaigns impersonate legitimate update dialogs or bundle the stealer with pirated software and cracked installers.

//Why Notarization Status Is Not Enough

The practical lesson for anyone evaluating a downloaded Mac app is not "check that it's notarized" - the Jamf case shows that check can pass for live malware. A notarized app is one Apple's automated scanning did not flag at submission time, nothing more. The things that still hold up as defensive signals are the ones notarization does not cover: whether the software came from the vendor it claims to, whether the install flow matches what that vendor's real installer looks like, and whether anything asked for the macOS login password outside of an expected system prompt - Keychain and credential theft on macOS routinely relies on a fake password dialog, not a stolen one.

[WARNING]
This site has no original telemetry on AMOS infections, certificate revocations or the current state of any particular developer account. Status checks should go to Apple's own developer tools and current vendor reporting, not to this article.