Breaking
SecurityDeveloping Story

Fake Zoom Installer Delivers macOS Backdoor

Researchers at Jamf say a bogus Zoom app installs CloudSyncD, a backdoor that abuses user passwords to run with root privileges.

··1 hour ago·5 min read
black and gray laptop computer
Photo by Roger Cai on Unsplash

A malicious disk image posing as a Zoom installer is slipping a backdoor onto macOS systems. According to research from Jamf, the campaign delivers a dropper that installs CloudSyncD, a persistent backdoor built to grant attackers long-term, stealthy access to infected Macs. The malware has moved from a development curiosity to active deployment in a matter of weeks.

A familiar disguise, a new payload

The infection chain starts with ordinary social engineering. Victims are persuaded to download what they believe is a Zoom installer for macOS. The file arrives as a disk image that mounts as a volume named Zoom. Inside is a dropper that carries the actual malware payload, but it will not run on its own. The victim has to activate it — a step framed as installing the legitimate video-conferencing app.

The researchers describe the dropper as unusually self-contained. It “carries a complete universal Mach-O inside itself, roughly 756 KB in the development build, and extracts it at runtime. The same payload is also present on disk inside the application bundle, so the dropper has two sources for it,” say the researchers.

That dual-source design gives the malware a fallback if one copy is removed or fails to execute. The payload is first written to an anonymous file descriptor and executed from there. On most Macs, that attempt fails because of System Integrity Protection, Apple's built-in defense against tampering with protected system files.

How the backdoor gets root

When the in-memory execution fails, the dropper takes a more direct route. It writes the payload to disk temporarily and runs it using sudo with the user's password — the same password the victim handed over during the fake installation process.

Once running, CloudSyncD installs itself as a daemon, also named CloudSyncD, and stores its configuration encrypted inside its binary. The configuration is decrypted at runtime, keeping the command-and-control details out of plain sight.

The phished password is not exfiltrated. According to the researchers, it is used locally only to grant root privileges so the backdoor can keep running. That detail separates CloudSyncD from a typical infostealer, even though its delivery looks similar at first glance. The malware contains no standard information-stealing functionality, the researchers say.

What it does instead is conduct host profiling and reconnaissance, then exfiltrate system and user details to its command-and-control server. It is built to be persistent and to allow attackers to deploy follow-up payloads later.

From debug build to live domains

Jamf first spotted the malware in mid-September, still under development. In that early build, the C2 address pointed to a private network and verbose debug logging had been left switched on — signs of a work in progress rather than a finished tool. Within days, other samples turned up, suggesting the operators had moved from testing to deployment.

The newer builds show up on two separate domains. Both use the same URI path, which masquerades as a jQuery script so that a beacon looks like an ordinary JavaScript fetch. The domains were registered in 2011 through the same registrar and sit behind Cloudflare. At the time of writing, neither domain carried any detections.

One key unlocks every build

The consistency across samples gives defenders a rare advantage. “Every build shares the same string obfuscation table, the same install paths, daemon name and process disguise, and, more tellingly, the same C2 key and initialization vector, down to the identical per-string seeds,” the researchers say. “Only the endpoint changes. Captured beacon traffic is therefore decryptable with material recovered from any build, and the on-host indicators hold across all of them.”

That means artifacts pulled from one sample apply to the others. The identical key and initialization vector, along with the same per-string seeds, allow captured traffic to be decrypted and on-host indicators to be reused across the entire family, the researchers note.

The IOCs defenders can use

Because CloudSyncD has reached the deployment stage, Jamf published a long list of indicators of compromise for defenders to monitor. The shared traits span file paths, a daemon name, and process disguise techniques, alongside network artifacts tied to the two domains.

Organizations tracking the campaign can lean on the identical string obfuscation table and install paths across builds, which give detection engineers stable signatures even as endpoints shift.

Native tricks, old-fashioned phish

The trajectory of this malware illustrates a broader pattern in macOS threats. It leans on native implementations, string protection, and execution paths designed to avoid writing payloads to disk wherever possible.

Yet the entry point remains an old one: convincing a user to hand over a password. In this case, the password unlocks root privileges through sudo, completing the chain that installs the daemon.

That combination — modern obfuscation wrapped around classic social engineering — is what makes the fake Zoom installer effective. The victim believes they are completing a normal app installation, and the steps they follow produce a working backdoor instead.

What the backdoor leaves behind

Once CloudSyncD is running as a daemon, it can profile the host and send system and user details to its C2. The researchers describe it as providing stealthy, long-term access rather than immediate theft. Follow-up payloads can be delivered through the same channel, extending an intrusion beyond the initial compromise.

The malware's configuration stays encrypted in the binary until runtime, which complicates static analysis. The process disguise and daemon name help it blend into normal macOS activity.

Why the codebase matters

The reuse of a single key, initialization vector, and per-string seeds across builds is not just a technical quirk. It means the operators changed endpoints without reworking their core obfuscation and infrastructure, leaving forensic material that carries from one sample to the next.

For incident responders, that is a practical break. Traffic captured from one infected machine can be decrypted with material from any build, and the same on-host indicators apply across the family.

The reader's takeaway

For macOS users, the campaign is a reminder that a convincing installer can be the whole attack. The safer habit is to download software only from a vendor's official site or the Mac App Store, and to treat any unexpected prompt for a system password during an install as a reason to stop. Verification of the source, not just the icon or the name on the disk image, is what breaks this chain.

For security teams, the value here is the overlap in indicators. Because the builds share keys, seeds, paths, and process names, defenders can hunt across the family with one set of signatures rather than rebuilding detection for each new domain. The two domains were registered in 2011 through the same registrar and sit behind Cloudflare, and neither carried detections at the time of writing — a gap that monitoring for the published IOCs could help close.

None of this changes the fact that the oldest step in the chain is still a person entering a password into a window they believe is Zoom.

#macos malware#cloudsyncd#backdoor#phishing#jamf

Sources

Iliyas

Founder & Editor, Xploitwire

This article was written and reviewed against the sources listed above before publication, under editorial policies set by Iliyas. Read our Editorial Policy →

← Back to all stories