In January 2026, Microsoft Defender Experts observed Atomic macOS Stealer (AMOS) moving from initial access to full credential harvesting in minutes — using nothing but native macOS tooling. No exploits, no kernel tricks, just Apple’s own features turned against the user.

macOS is no longer a safe haven. As enterprises embrace Apple hardware at scale, attackers have followed. The attack surface is different from Windows — but it’s just as real.

TL;DR

  • macOS has unique security layers (TCC, Gatekeeper, SIP, Keychain) that attackers specifically target and bypass
  • The most dangerous techniques use Apple’s own legitimate features: osascript, security CLI, launchd
  • Launch Agents and dylib hijacking provide stealthy persistence that survives reboots
  • Detection relies on macOS Unified Log, endpoint security frameworks, and behavioral monitoring
  • AMOS and similar infostealers are actively exploiting macOS users in 2026

Why This Matters

macOS has long had a reputation for being “more secure” than Windows — and in some ways, Apple’s security architecture is genuinely strong. But that reputation leads to complacency. Enterprises deploy Macs without EDR, assume Gatekeeper is enough, and skip security baselines.

For pentesters: macOS environments are increasingly common targets, and the techniques are fundamentally different from Windows. For SOC analysts: if you don’t know what a LaunchAgent looks like or how the macOS Unified Log works, you’ll miss the attack entirely.


macOS Security Architecture: What You’re Up Against

Before attacking or defending, understand the layers Apple built:

Security LayerWhat It Does
GatekeeperBlocks unsigned or non-notarized apps from running
SIP (System Integrity Protection)Prevents modification of protected system directories, even as root
TCC (Transparency, Consent & Control)Controls app access to camera, microphone, contacts, Desktop, Downloads
KeychainEncrypted credential store for passwords, certificates, keys
SandboxIsolates apps from each other and from sensitive system resources
XProtectApple’s built-in signature-based malware scanner

Each of these is a target. Attackers don’t break through them — they find ways around them using macOS’s own APIs and legitimate features.


Initial Access: Malicious DMG, PKG, and Gatekeeper Bypass

Most macOS attacks start the same way Windows attacks do: the user runs something they shouldn’t. On macOS, the delivery vehicles are .dmg disk images and .pkg installers — the native formats users expect.

Gatekeeper bypass via social engineering:

The attacker delivers a signed or notarized-looking app. If Gatekeeper flags it, the phishing page shows instructions: “Right-click → Open to bypass the security warning.” The user follows them, and Gatekeeper is defeated by the user themselves.

In late 2025, the MacSync macOS stealer used a legitimately signed app to pass Gatekeeper checks entirely — Apple’s notarization system failed to detect the malicious payload embedded inside.

CVE-2026-20684 — Authentication bypass:

This 2026 vulnerability allows unsigned apps to bypass Gatekeeper enforcement entirely when executed under App Translocation — macOS’s mechanism for running apps from untrusted paths in a randomized quarantine directory.

What defenders should watch:

Terminal window
# Check if a file has the quarantine attribute (downloaded from internet)
xattr -l /path/to/suspicious.app
# Quarantine flag looks like:
# com.apple.quarantine: 0083;...

Apps executed with the quarantine attribute and no user approval show up in Unified Log as Gatekeeper process events. Apps that bypass this entirely leave no quarantine attribute — that absence is itself a detection signal.


TCC Bypass: Silently Accessing Everything

TCC — Transparency, Consent & Control — is Apple’s privacy gatekeeper. It controls which apps can access your camera, microphone, contacts, Desktop folder, Downloads, and full disk. Every time an app requests these, a dialog appears asking the user to approve.

Attackers bypass TCC to access sensitive data without that dialog ever appearing.

CVE-2025-43530 — VoiceOver TCC bypass:

This 2025 vulnerability exploited how macOS trusted Apple’s own VoiceOver accessibility service. VoiceOver has system-wide permissions — including the ability to send AppleEvents to other applications and access the file system. An attacker who could communicate with the com.apple.scrod service (VoiceOver’s backend) could execute arbitrary AppleScript and access files silently, with no permission dialog shown to the user.

Apple patched this in macOS 26.2 by requiring the com.apple.private.accessibility.scrod entitlement validated via audit token. But the technique illustrates the pattern: trusted system services with broad permissions become privilege escalation paths.

Common TCC bypass patterns:

  • Abuse apps that already have TCC permissions (e.g., Terminal has Full Disk Access → spawn a child process from Terminal)
  • Exploit accessibility APIs which historically receive elevated trust
  • Inject into processes that already have the required TCC entitlements

Keychain Credential Theft (T1555.001)

The macOS Keychain is like a master password vault — it stores Wi-Fi passwords, browser credentials, SSH keys, certificates, and application secrets. Critically, the Login Keychain is unlocked when the user logs in and stays unlocked during the session.

An attacker with user-level code execution can dump Keychain contents using Apple’s own security CLI:

Terminal window
# Dump all credentials from Login Keychain — prompts user for password
security dump-keychain -d ~/Library/Keychains/login.keychain-db
# Find specific credentials silently (each prompt can be suppressed per entry)
security find-generic-password -wa "Wi-Fi Password"
security find-internet-password -s "github.com" -w

The -w flag returns just the password. The -a flag specifies the account. In practice, AMOS and similar infostealers iterate through all Keychain entries programmatically and exfiltrate the results.

What defenders detect:

The security binary with arguments -wa, -ga, find-generic-password, or find-internet-password invoked by an unexpected parent process is a strong detection signal — especially if that parent process is a script, browser, or downloaded application.

Terminal window
# macOS Unified Log query for Keychain access via security binary
log show --predicate 'process == "security" AND message CONTAINS "find-generic-password"' --last 1h

Launch Agent Persistence (T1543.001)

On macOS, launchd is the init system — the equivalent of systemd on Linux. It manages background processes through property list (.plist) files placed in specific directories. Attackers abuse this to survive reboots.

Where Launch Agents live:

PathScopeTriggered By
~/Library/LaunchAgents/Current userUser login
/Library/LaunchAgents/All usersUser login (requires admin)
/Library/LaunchDaemons/System-wideSystem boot (requires root)

Malicious Launch Agent example:

~/Library/LaunchAgents/com.apple.update.plist
<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.update</string>
<key>ProgramArguments</key>
<array>
<string>/Users/victim/.hidden/backdoor.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>

RunAtLoad: true executes the payload at login. KeepAlive: true restarts it if killed. The label com.apple.update mimics a legitimate Apple service name.

Detection:

Any new .plist file in LaunchAgents directories with RunAtLoad or KeepAlive set to true warrants investigation — especially if the ProgramArguments path points to a hidden directory, temp folder, or user home directory.

Terminal window
# List all Launch Agents and their program paths
launchctl list | grep -v com.apple
find ~/Library/LaunchAgents /Library/LaunchAgents -name "*.plist" -exec plutil -p {} \;

dylib Hijacking (T1574.004)

On macOS, applications load dynamic libraries (dylibs) at runtime — similar to DLLs on Windows. When an application searches for a dylib and the path doesn’t exist, an attacker can plant a malicious dylib there.

The macOS dynamic loader (dyld) searches in a defined order: @rpath, @loader_path, @executable_path, then system paths. If any earlier path is attacker-writable, the malicious dylib loads first.

Finding vulnerable apps:

Terminal window
# Find apps that reference missing dylib paths
otool -L /Applications/SomeApp.app/Contents/MacOS/SomeApp | grep "@rpath"
# Check if that rpath directory exists and is writable
ls -la /Applications/SomeApp.app/Contents/Frameworks/

If the @rpath directory is writable and a referenced dylib doesn’t exist there, the attacker plants their own dylib with the expected filename. When the app launches, their code runs with the app’s privileges — including any TCC permissions the app has been granted.

A February 2026 blog post by cocomelonc demonstrated this technique using VLC, showing that legitimate apps with broad TCC permissions (like Full Disk Access) are high-value dylib hijacking targets.

Detection signal: Dylibs loaded from user-writable paths (user home directory, /tmp, application support folders) that weren’t present at install time.


osascript / AppleScript Abuse (T1059.002)

AppleScript is macOS’s built-in automation language. osascript is the command-line tool to execute it. Attackers use it for everything from displaying fake password prompts to controlling applications programmatically.

Fake password prompt (credential phishing):

Terminal window
# Display a convincing system dialog asking for the user's password
osascript -e 'display dialog "macOS needs your password to install a security update." default answer "" with hidden answer buttons {"Cancel", "OK"} default button "OK" with icon caution'

The user sees a dialog that looks like a legitimate macOS prompt. If they type their password, osascript captures it and returns it to the attacker.

Launching applications silently:

Terminal window
# Open and control another application via AppleEvents
osascript -e 'tell application "Finder" to open POSIX file "/tmp/payload.sh"'

Detection:

osascript spawned by unexpected parents (scripts, browser extensions, downloaded apps) is suspicious — especially with -e flags containing display dialog, do shell script, or system events. The TCC bypass CVE-2025-43530 also used AppleScript execution via the VoiceOver service.


Detection: What to Monitor

EventWhat It IndicatesWhere to Find It
New .plist in ~/Library/LaunchAgents/Persistence attemptFile system events, Unified Log
security CLI with -wa or find-*-passwordKeychain theftUnified Log, process events
osascript -e 'display dialog'Credential phishing dialogUnified Log, process args
App without quarantine attribute runningGatekeeper bypassUnified Log, xattr
dylib loaded from user-writable pathdylib hijackingEndpoint Security Framework
launchctl load on new plistLaunch Agent activationUnified Log

Unified Log queries:

Terminal window
# All osascript executions in the last hour
log show --predicate 'process == "osascript"' --last 1h
# LaunchAgent loading events
log show --predicate 'subsystem == "com.apple.launchd"' --last 24h | grep "load"
# Suspicious security binary usage
log show --predicate 'process == "security" AND message CONTAINS "password"' --last 24h

Enterprise tooling: Jamf Protect maps macOS behavioral events to MITRE ATT&CK and forwards Unified Log data to SIEM. CrowdStrike Falcon and SentinelOne both support macOS through Apple’s Endpoint Security Framework (ESF) — the official API for real-time kernel-level event monitoring.


What You Can Do Today

  1. Enable Full Disk Access for your EDR only — review System Settings → Privacy & Security → Full Disk Access. Remove any apps that shouldn’t have it.
  2. Audit Launch Agents right now:
    Terminal window
    find ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons -name "*.plist" 2>/dev/null | xargs -I{} plutil -p {} | grep -A2 "ProgramArguments"
  3. Check for unexpected dylibs — use KnockKnock (free, from Objective-See) to scan all persistent items including Launch Agents, kernel extensions, and login items.
  4. Enable macOS Audit loggingsudo launchctl load -w /System/Library/LaunchDaemons/com.apple.auditd.plist adds OpenBSM audit trails.
  5. Never dismiss Gatekeeper — if a download requires you to right-click → Open to bypass the warning, that is a red flag, not a normal installation step.
  6. Deploy osquery on macOS endpoints — the launchd and process_events tables provide excellent visibility for both red team assessment and SOC monitoring.


Sources