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 Layer | What It Does |
|---|---|
| Gatekeeper | Blocks 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 |
| Keychain | Encrypted credential store for passwords, certificates, keys |
| Sandbox | Isolates apps from each other and from sensitive system resources |
| XProtect | Apple’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:
# 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:
# Dump all credentials from Login Keychain — prompts user for passwordsecurity 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" -wThe -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.
# macOS Unified Log query for Keychain access via security binarylog show --predicate 'process == "security" AND message CONTAINS "find-generic-password"' --last 1hLaunch 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:
| Path | Scope | Triggered By |
|---|---|---|
~/Library/LaunchAgents/ | Current user | User login |
/Library/LaunchAgents/ | All users | User login (requires admin) |
/Library/LaunchDaemons/ | System-wide | System boot (requires root) |
Malicious Launch Agent example:
<?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.
# List all Launch Agents and their program pathslaunchctl list | grep -v com.applefind ~/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:
# Find apps that reference missing dylib pathsotool -L /Applications/SomeApp.app/Contents/MacOS/SomeApp | grep "@rpath"
# Check if that rpath directory exists and is writablels -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):
# Display a convincing system dialog asking for the user's passwordosascript -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:
# Open and control another application via AppleEventsosascript -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
| Event | What It Indicates | Where to Find It |
|---|---|---|
New .plist in ~/Library/LaunchAgents/ | Persistence attempt | File system events, Unified Log |
security CLI with -wa or find-*-password | Keychain theft | Unified Log, process events |
osascript -e 'display dialog' | Credential phishing dialog | Unified Log, process args |
| App without quarantine attribute running | Gatekeeper bypass | Unified Log, xattr |
| dylib loaded from user-writable path | dylib hijacking | Endpoint Security Framework |
launchctl load on new plist | Launch Agent activation | Unified Log |
Unified Log queries:
# All osascript executions in the last hourlog show --predicate 'process == "osascript"' --last 1h
# LaunchAgent loading eventslog show --predicate 'subsystem == "com.apple.launchd"' --last 24h | grep "load"
# Suspicious security binary usagelog show --predicate 'process == "security" AND message CONTAINS "password"' --last 24hEnterprise 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
- Enable Full Disk Access for your EDR only — review System Settings → Privacy & Security → Full Disk Access. Remove any apps that shouldn’t have it.
- 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" - Check for unexpected dylibs — use
KnockKnock(free, from Objective-See) to scan all persistent items including Launch Agents, kernel extensions, and login items. - Enable macOS Audit logging —
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.auditd.plistadds OpenBSM audit trails. - 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.
- Deploy osquery on macOS endpoints — the
launchdandprocess_eventstables provide excellent visibility for both red team assessment and SOC monitoring.
Related Posts
- Mobile Pentesting: Android and iOS Complete Guide — iOS shares Apple’s security architecture concepts with macOS
- Memory Forensics with Volatility 3 — Volatility 3 supports macOS memory dumps with the same workflow
- Linux Privilege Escalation: Attack and Detect 2026 — Linux techniques that have direct macOS equivalents (SUID, cron vs launchd)
- LSASS Dumping Techniques — Windows credential theft that parallels macOS Keychain attacks
- DFIR: Incident Response Complete Guide 2026 — IR workflow when you find macOS compromise evidence
Sources
- Hunting Infostealers: macOS Threats — Microsoft Defender Experts, 2026
- Infostealers Without Borders: macOS, Python Stealers and Platform Abuse — Microsoft Security Blog, February 2026
- New macOS TCC Bypass Vulnerability Allows Attackers to Access Sensitive User Data — CyberSecurityNews
- New MacSync macOS Stealer Uses Signed App to Bypass Apple Gatekeeper — The Hacker News
- macOS Malware Persistence via Dylib Hijacking — cocomelonc, February 2026
- Keychain Password Retrieval via Command Line — Detection.FYI / Elastic
- macOS Security Testing — Jamf Protect Evaluation Guide
- MITRE ATT&CK T1555.001 — Credentials from Password Stores: Keychain
- MITRE ATT&CK T1543.001 — Create or Modify System Process: Launch Agent
- MITRE ATT&CK T1574.004 — Hijack Execution Flow: Dylib Hijacking
- MITRE ATT&CK T1059.002 — Command and Scripting Interpreter: AppleScript