Mac malware
Entrenched within enterprises, macOS systems now face similar threats to Windows systems.
If your organization has software engineers or graphic designers, you’ve likely already managed macOS systems for quite some time. Throughout 2025, we spoke to several organizations that wanted to prepare as some areas of their companies sought to use macOS systems instead of Windows for a variety of reasons. As more employees switch to Macs, the macOS-specific attack surface for your organization expands, requiring a new tailored approach to defense.
As more employees switch to Macs, the macOS-specific attack surface for your organization expands, requiring a new tailored approach to defense.
macOS threats in 2025
macOS default controls
Just like Windows, macOS has some default security controls to protect against malware execution. Apple’s platform security documentation shows that macOS default controls are made up of Gatekeeper, Notarization, and XProtect. Gatekeeper requires any apps that execute on macOS be notarized, which in turn requires the app developer to submit it to Apple for scanning (but not a full code review). For folks working in Windows, this is similar to the Windows App Certification that is required for apps in the Microsoft Store.
While Gatekeeper and Notarization are imperfect, Apple has taken steps to keep those controls resilient against bypasses and abuse. An excellent example of this is the patching of a Gatekeeper bypass in late 2024 that was simple enough that adversaries could coach users through executing.
Finally, XProtect is the anti-malware control for macOS, similar to Windows Defender. And just like with Defender, Apple periodically updates signatures for XProtect to find and remediate malware families.
Paste and run to evade Gatekeeper
Gatekeeper is awesome at preventing non-notarized apps from executing on macOS, but what if the malware doesn’t need to execute from an app? This is the exact path that adversaries took in 2025. Astute readers of previous Threat Detection Reports may remember that Apple slowed down stealer execution in September 2024 by taking a well-known bypass out of Gatekeeper (referenced above). As a result, adversaries began exploring how they could distribute malware in script form to evade Gatekeeper entirely.
This experimentation and evolution took place as paste-and-run initial access methods were already popular on Windows. Adversaries began using those same paste-and-run methods on macOS, replacing PowerShell with a combination of shell script and AppleScript code. Unfortunately, this worked rather well, as many macOS users were already familiar with performing curl | bash commands to download and install software. Once the fateful paste into a Terminal window took place, the traditional AppleScript stealer code we’ve observed in previous years executed to gather data and exfiltrate.
Mac stealer families by the numbers
Atomic Stealer remained popular this year, even as Poseidon rebranded as Odyssey Stealer and resumed distribution to become the second most popular. Towards the end of 2025, we began to observe three additional newcomers to the macOS stealer market: MacSync Stealer, Phexia, and DigitStealer.
Of the stealer families we observed, Atomic Stealer was the most popular, while Odyssey and MacSync stealers both achieved similar popularity. Phexia and DigitStealer were the least common, potentially indicating they weren’t as widely distributed.
Stealer family breakdown in 2025
For time distribution, Atomic and Odyssey Stealers were commonly distributed throughout the year, while MacSync Stealer and Phexia appeared only at the end of 2025.
Atomic & Odyssey stealers
MacSync Stealer & Phexia
Just a little bit of BeaverTail
In addition to the usual legion of stealers, we also observed BeaverTail malware executing on macOS in 2025. BeaverTail relies on social engineering techniques for initial access, with lures posing as job interviews or programming tasks distributed through gig work sites. In the cases we observed late in 2025, the BeaverTail instances we observed matched activity reported by NVISO.
macOS devices should have comprehensive protections in place, including antimalware and EDR tools. Without visibility, detection and response is much more difficult. To explore what telemetry data is possible to gather, check out the free Mac Monitor tool.
We’ve also seen some organizations use Santa for macOS for application control. Santa can be complicated to configure and deploy, but recent developments in 2025 show that the tool is becoming more useful in behavior-based blocking. Starting with version 2025.8, Santa can use Common Expression Language (CEL) rules to block specific instances of process and command-line combinations from executing. This example rule from North Pole Security shows how organizations can block osascript processes from prompting users for passwords:
(
args.join(" ").lowerAscii().matches(".*\\W+with\\W+hidden\\W+answer.*") ||
args.join(" ").lowerAscii().contains("password")
) &&
args.join(" ").lowerAscii().matches(
".*\\W+display\\W+dialog.*") ? BLOCKLIST : ALLOWLISTUsing this rule as a starting point, organizations can improvise blocking rules specific to stealer command lines such as:
(
args.join(" ").lowerAscii().contains("login.keychain-db") ||
args.join(" ").lowerAscii().contains("cookies.binarycookies") ||
args.join(" ").lowerAscii().contains("notestore.sqlite") ||
args.join(" ").lowerAscii().contains("login data") ||
args.join(" ").lowerAscii().contains("web data") ||
args.join(" ").lowerAscii().contains("dscl . authonly")
) ? BLOCKLIST : ALLOWLISTAlternatively, orgs could also craft blocking rules to prevent osascript from executing any shell commands in their command-line arguments, but this can also prevent legitimate tools from working:
(
args.join(" ").lowerAscii().contains("do shell script")
) ? BLOCKLIST : ALLOWLISTAs with any application control solutions or detection rules, tuning adjustments and testing are needed to make sure configuring Santa in these ways does not negatively affect business operations.
Additional mitigations here are the same for any other stealer families, providing safe software sources and a robust response plan. For macOS-specific actions, consider further educating users on TCC controls in macOS and presenting scenarios when users may not want to bypass TCC to preserve their own security and privacy.
For endpoints where a stealer has run, consider resetting all TCC permissions so they will re-fire in the future even if a user approves access by executing: sudo tccutil reset All
Password theft via osascript
The following pseudo-detector looks for adversaries abusing the osascript process in an effort to prompt a user to enter passwords.
process_name == osascript
&&
command_line includes ('password' and 'answer')Stealing files and cookies with osascript
The following pseudo-detector looks for adversaries abusing osascript to steal Safari cookies.
process_name == osascript
&&
command_line includes ('duplicate file' && 'Cookies.binarycookies')AppleScript spawning dscl to validate credentials
This pseudo-detector looks for AppleScript processes using dscl (directory service command line utility) commands to validate input credentials.
parent_process == 'osascript'
&&
command_includes 'dscl'Testing
Start testing your defenses against macOS malware using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
The following Atomic Red Team tests can help generate telemetry common to macOS stealers:
This test copies the contents from Keychain using the cat utility in a manner consistent with Atomic stealer.
T1539: Steal Web Session Cookie (Atomic Test #5 – Copy Safari BinaryCookies files using AppleScript)
This test leverages AppleScript to copy cookies from the Safari browser in a manner consistent with Atomic Stealer.
T1005: Data from Local System (Atomic Test #3 – Copy Apple Notes database files using AppleScript)
This test leverages AppleScript to copy the contents of the Apple Notes database in a manner consistent with Atomic Stealer.
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.