XCSSET Malware Targets macOS Developers via Poisoned Xcode Projects

A freshly updated version of the XCSSET malware—designated version 40—has resurfaced in developer supply chain attacks, leveraging compromised Xcode projects hosted on public repositories like GitHub to infect macOS systems. First observed during attack waves in mid-April and early May by researchers at Palo Alto Networks’ Unit 42, the new campaign introduces enhanced evasion capabilities, automated persistence across local project files, and specialized post-exploitation modules targeting developer credentials, crypto wallets, and encrypted communications.

XCSSET has actively targeted Apple ecosystem developers since at least 2021, historically utilizing zero-day vulnerabilities in macOS alongside malicious project files. Microsoft previously warned of XCSSET campaigns abusing Xcode projects as a primary distribution mechanism and noted variants introducing cryptocurrency theft capabilities. By compromising open-source repositories and injecting malicious loader scripts into benign Xcode project files, the malware relies on a low-friction distribution model: developers who clone and build the compromised repository trigger execution automatically during the compilation process.

How the Xcode Build Vector Works

The core mechanics of the attack exploit a fundamental feature of Integrated Development Environments (IDEs): build-phase script execution. In Apple’s Xcode SDK, project files (.xcodeproj) allow developers to define custom shell scripts that run automatically during pre-build or post-build sequences. Attackers hijack these benign build settings by inserting malicious shell commands or AppleScript loaders into open-source repositories.

When a developer builds a poisoned project, the embedded script executes with the current user’s privileges without raising warnings. XCSSET uses this initial foothold to establish persistence and scan the local disk for other Xcode project structures. The malware recursively injects its downloader script into every .xcodeproj directory it finds on the victim’s host, effectively turning the infected developer’s machine into an unwitting propagation vector. Any project compiled or pushed back to source control (such as GitHub, GitLab, or Bitbucket) carries the malicious payload to downstream teammates and open-source contributors.

Infection Chain and New Modules in Version 40

The infection chain of XCSSET v40 progresses through four distinct stages before deploying 17 operational modules. These components handle traditional post-exploitation tasks, including keystroke logging, clipboard monitoring, data exfiltration, and harvesting stored browser credentials.

Version 40 introduces two notable functional modules designed for deep target surveillance:

1. Chrome Developer Tools Protocol (CDP) Hijacker: The malware wraps the victim’s Google Chrome executable in a malicious launcher script that launches the browser with debugging options enabled on a local port. By weaponizing the Chrome DevTools Protocol, the attacker fetches and executes remote JavaScript payloads directly inside the user’s active browser context. This allows real-time interception of web traffic, session cookies, login credentials, and web3 transactions—specifically targeting MetaMask extensions to manipulate wallet addresses on the fly. The hijacker also implements a fileless reverse shell; while Google blocks this technique on Windows builds of Chrome, protections for macOS remain in development.
2. Telegram Trojanizer: XCSSET actively locates legitimate installations of Telegram Desktop on infected systems, deletes the native application binary, and substitutes a malicious version. While the module’s encrypted configuration prevents full verification of its internal commands, the primary objective is to intercept messaging communications, session tokens, and files shared across developer communications channels.

Evasion and macOS Security Subversion

XCSSET v40 demonstrates a sophisticated defense evasion strategy aimed at neutralizing macOS security controls. To hinder signature-based detection and static analysis, the command-and-control (C2) server periodically re-compiles the initial loader binary, applying build-unique ciphers to obfuscate variable names, function calls, and string tables. Inbound and outbound C2 communications utilize separate encryption keys to prevent simple passive decryption.

Once running on a target host, XCSSET aggressively attempts to disable built-in macOS security mechanisms:

• Security Framework Interruption: The malware targets XProtect (Apple’s built-in signature detection tool), the Malware Removal Tool (MRT), and Rapid Security Response (RSR) updates, explicitly blocking XProtect signature updates.
• Telemetry Suppression: It terminates Apple’s CloudTelemetryService process and alters system default domains to suppress alert generation.
• Privacy and Integrity Bypasses: It attempts to evade Transparency, Consent, and Control (TCC) framework checks, using ad hoc-signed binaries to bypass Gatekeeper execution policies.

Blast Radius and Technical Remediation

The operational impact of an XCSSET infection extends well beyond an individual developer workstation. Because developers frequently possess elevated privileges, cloud API keys, SSH keys, and access to internal production codebases, compromising a developer workstation often leads to broader enterprise supply chain compromise.

To defend against XCSSET version 40 and similar IDE-based threats:

• Audit Build Scripts: Security teams and developers should inspect .xcodeproj build phases (specifically Run Script phases) before building third-party or newly cloned repositories.
• Scan Source Dependencies: Implement automated Software Composition Analysis (SCA) and repository scanning tools in software development pipelines to detect unauthorized script modifications prior to local developer checkouts.
• Monitor macOS Indicators: Security operations centers should flag anomalous AppleScript executions (osascript), unusual modifications to macOS defaults domains, ad hoc-signed application executions bypassing Gatekeeper, and Chrome processes launched with command-line flags enabling debugging ports (such as --remote-debugging-port).