9to5Mac Security Bite is exclusively brought to you by Mosyle, the only Apple Unified Platform. Making Apple devices work-ready and enterprise-safe is all we do. Our unique integrated approach to management and security combines state-of-the-art Apple-specific security solutions for fully automated Hardening & Compliance, Next Generation EDR, AI-powered Zero Trust, and exclusive Privilege Management with the most powerful and modern Apple MDM on the market. The result is a totally automated Apple Unified Platform currently trusted by over 45,000 organizations to make millions of Apple devices work-ready with no effort and at an affordable cost. Request your EXTENDED TRIAL today and understand why Mosyle is everything you need to work with Apple.
Last week, Jamf Threat Labs published research on yet another variant of the increasingly popular MacSync Stealer family calling attention to a growing problem in macOS security: malware that’s sneaking around Apple’s most significant third party app protections. This new variant was distributed inside a malicious app that was both code-signed with a valid Developer ID and notarized by Apple, meaning Gatekeeper had no reason to block it from launching.
Historically, Apple’s model has worked quite well. Apps distributed outside the Mac App Store must be cryptographically signed and notarized to open without having users jump through a lot of hoops. But that trust model assumes that signing proves good intent. What we’re seeing now is that attackers are obtaining real developer certificates and shipping malware that looks indistinguishable from legit software at the time of install.
After speaking with multiple people familiar with the matter, there are a few ways threat actors are going about achieving this. In many cases, they’re using a combination of the following:
Signed and notarized malicious apps could be operating with Developer ID certificates that are compromised or even purchased via underground channels, which significantly lowers suspicion. As we saw in Jamf’s report on a new MacSync Stealer variant, the initial binary is often a relatively simple Swift-based executable that appears benign during Apple’s static analysis and does little on its own.
The real malicious behavior happens later, when the app reaches out to remote infrastructure to fetch additional payloads. If those payloads aren’t available during notarization and only activate under real-world runtime conditions, Apple’s scanners have nothing malicious to analyze. The notarization process evaluates what exists at submission time, not what an app may retrieve after launch, and attackers are clearly designing around that boundary.
The first instance of Apple-notarized malware dates back to at least 2020, discovered by a Twitter user. Earlier this July, there was another instance of a similar malicious application that was signed and notarized by Apple. Now, has this reached the boiling point? Probably not. On one hand, I agree that even one instance of this happening is one too many.
On the other hand, I think it’s too easy to put the blame on Apple here. The system is largely working as designed. Code signing and notarization were never meant to guarantee that software is benign forever, only that it can be traced back to a real developer and revoked when abuse is discovered.
Top comment by John Lockwood
I am not a developer myself but I am an experienced administrator. Whilst I can see that malicious code downloaded after installation obviously does not get scanned during Apple's notarization process that there might be an approach that Apple could adopt to help mitigate this.
First, the notarized binary should include a hash value to show if it has been modified, that is if additional code has been added inside it. If the hash of the app bundle has then changed the notarization should be invalidated. Second if the original binary downloaded additional code but stores it outside the original binary and hence would not change any hash value then it should not inherit the original notarization.
This would only leave a potential opening of the downloaded and externally stored code being codesigned by a valid but compromised certificate but not notarized.
Some people may suggest that all code trying to do potentially risky tasks including downloading additional code should trigger an alert requesting approval. Unfortunately it is already the case that far too many notifications requesting permission are being displayed and even if admin level authorisation is required either it would result in admins pre-approving these or having to give out admin level access in order to allow users to work effectively without having to wait for their support team to assist them e.g. allowing a legitimate genuine video conferencing app to access the camera has to be approved by each user.
This is an intriguing attack vector and one I’ll continue to track going into 2026.
At the end of the day, the best defense against malware is to download software directly from developers you trust or from the Mac App Store.
Security Bite is 9to5Mac’s weekly deep dive into the world of Apple security. Each week, Arin Waichulis unpacks new threats, privacy concerns, vulnerabilities, and more, shaping an ecosystem of over 2 billion devices.
Follow Arin: Twitter/X, LinkedIn, Threads
FTC: We use income earning auto affiliate links. More.
Comments