Skip to content

Security1 publisher2 min readPublished

Fake Zoom installer talks macOS users past Gatekeeper to drop CloudSyncD backdoor

Jamf Threat Labs reported CloudSyncD, a new macOS backdoor that spreads through a fake Zoom installer and beacons to its server every 8 to 16 seconds. First caught as a VirusTotal sample that looked unfinished, it now appears in builds that connect to live infrastructure in what Jamf calls an active campaign.

The Watch · Security desk

What happened

  • The installer arrives as a disk image that mounts as a volume named Zoom and walks the victim through clicking Open Anyway in security settings to override Gatekeeper by hand.
  • It then prompts for the user's password and plays a fake download progress window while the password is quietly written to disk, out of the victim's sight.
  • The implant takes its tasks from the command server as JSON objects and runs any raw Mach-O it is sent, plus gzipped tar archives that it unpacks with /usr/bin/tar.
  • CloudSyncD is not an infostealer: it ignores browser data, keychain items and cryptocurrency wallets, taking only the password to advance the attack, and does not appear to send it anywhere.

Compiled by The WatchSomething wrong?How this is made

Why it matters

  • constraint CloudSyncD installs no LaunchAgent or LaunchDaemon to survive a reboot, so endpoint tools tuned to persistence artifacts have nothing to fire on; detection has to lean on the files it drops instead.
  • exposure System Integrity Protection blocked the fileless /dev/fd execution in Jamf's tests, but the dropper falls back to writing the payload to disk and running it with sudo using the stolen password, so the chain completes anyway.
  • decision Because the whole chain depends on the user's own clicks, the control that stops it is a managed policy blocking unsigned installers backed by staff training, not Apple's default protections.
  • precedent Fake Zoom installers already have a track record with North Korean and Iranian operators in recruiter and meeting themed attacks, so any workflow that asks staff to install Zoom for a call is a standing target for this entry.

The malware validates the password with dscl, then writes it to a file at ~/.config/zoom/data.json that reads like an ordinary Zoom configuration [4][5]. The password sits inside a cache value, base64-encoded and padded with randomly generated filler before and after it [5]. To find it again, the malware records the password's length and offset in the file's version field using two invisible characters, the U+200C zero width non-joiner and the U+200B zero width space; the count of each tells the attacker where to dig the password out of the filler [6].

The dropper carries its Mach-O payload inside itself and extracts it at runtime [7]. It first tries to run the payload from /dev/fd without writing anything to disk [7]. That failed in Jamf's tests, and the researchers expect it to fail on most Macs because of System Integrity Protection [8]. The fallback writes the payload to a temporary file with mkstemp and runs it with sudo, using the password the installer captured [9].

The implant is a universal Mach-O. It pulls its command-and-control address from an encrypted configuration file, writes logs to ~/.local/share/cloudsync/.config/logs/sync.err, and sends a survey of host information to the server [10][11]. "Tasking delivers executables, not shell commands, so the observable is a newly written or fileless Mach-O rather than suspicious shell activity," the Jamf researchers wrote [13].

Jamf has not attributed CloudSyncD to any threat actor [18]. "CloudSyncD is a good reminder that although infostealers may dominate the threat landscape, attackers still have use for quieter malware that lies low until further access is needed," the researchers wrote [16].

What to watch

  • Whether Jamf attributes CloudSyncD to a specific actor as more samples surface.
  • Whether the command-and-control infrastructure stays live or rotates, which would indicate the campaign's scale.
  • Whether later samples add persistence, closing the one gap that currently keeps the implant off reboot survival.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories