CloudSyncD macOS Malware Conceals Phished Credentials with Zero-Width Unicode

Summary

CloudSyncD is a two-stage macOS backdoor distributed through a fake Zoom installer disk image. The first stage steals user credentials through a fraudulent authorization prompt and hides the captured password inside a decoy configuration file using zero-width Unicode characters. The second stage deploys an embedded Mach-O implant that establishes command-and-control communication for remote task execution.

Investigation

Jamf Threat Labs discovered the malware during routine monitoring of executables submitted to VirusTotal. Researchers traced its evolution from an early development build to active deployment, observing a shift from local credential validation with dscl to communication with live C2 infrastructure. Analysts also decoded the password concealment method and recovered the implant’s configuration and C2 communication protocols.

Mitigation

Users should avoid following manual instructions that request bypassing Gatekeeper protections when installing unexpected applications. Organizations can use Jamf for Mac to enable threat prevention, advanced threat controls, and web protection to detect and block malicious activity. Keeping System Integrity Protection (SIP) enabled can also prevent certain fileless execution techniques used by the dropper.

Response

When CloudSyncD activity is detected, isolate the affected macOS host to stop further C2 communication. Investigate suspicious files within ~/.config/zoom/, ~/.local/share/cloudsync/, and the system temporary directory. Reset credentials for any user accounts that interacted with the fake authorization prompt, since their passwords may have been exposed to the attackers.

## Simulation Execution

• Attack Narrative & Commands: The attacker delivers a malicious macOS installer disguised as Zoom via a phishing email. Once the user executes the installer (User Execution), the dropper (the first stage) attempts to launch the second-stage payload. During this process, a specific error occurs in the command-line string: /dev/fd spawn failed rc=13. Alternatively, the dropper successfully launches a component named cshelper. The simulation will execute two distinct scenarios: one targeting the command-line strings and one targeting the specific process name to ensure full coverage of the rule’s logic.

• Regression Test Script:

  #!/bin/bash
  # CloudSyncD Simulation Script
  
  echo "[*] Starting CloudSyncD Simulation..."
  
  # Scenario 1: Triggering via Selection 1 and Selection 2 (The Dropper error)
  echo "[*] Simulating Stage 1 Dropper with specific error string..."
  # We use 'logger' or a dummy execution to simulate the command line telemetry if we cannot actually crash a file descriptor
  # In a real EDR test, we execute a process that carries this string in its arguments
  /usr/bin/echo "the app_installer dropper /dev/fd spawn failed rc=13" &
  
  sleep 2
  
  # Scenario 2: Triggering via Selection 3 (The cshelper process)
  echo "[*] Simulating Stage 2 'cshelper' process execution..."
  # Create a dummy file to represent the malicious binary
  touch /tmp/cshelper
  chmod +x /tmp/cshelper
  /tmp/cshelper &
  
  echo "[*] Simulation commands dispatched."

• Cleanup Commands:

  #!/bin/bash
  # Cleanup script
  echo "[*] Cleaning up simulation artifacts..."
  rm -f /tmp/cshelper
  echo "[*] Cleanup complete."