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