ZCyberNews
中文
MalwareHigh5 min readXCSSET

XCSSET v40 Returns: macOS Malware Hits Xcode Developers

XCSSET v40, a macOS malware targeting Xcode developers, has resurfaced with 17 modules, including a Chrome hijacking backdoor and Telegram trojanizer, after months of dormancy.

TopicMalware
Diagram of XCSSET v40 infection chain showing stages from malicious Xcode project to in-memory execution.

Executive Summary

After months of dormancy, the operators behind the XCSSET macOS malware have released version 40 (v40), a modular threat that targets software developers by hiding inside Xcode projects. According to Palo Alto Networks' Unit 42, the malware has been spreading since early April 2026 through supply chain attacks, infecting the Xcode projects of dozens of legitimate applications with thousands of active users. The new version introduces advanced evasion techniques, including polymorphic payload generation, fileless persistence, and dynamic in-memory execution, while also weakening security mechanisms on affected machines.

Defenders should be aware that XCSSET v40 is not just a rehash of previous versions. It now includes 17 distinct modules, with two new components: a Chrome hijacking backdoor that abuses the Chrome DevTools Protocol (CDP), and a Telegram trojanizer. The malware's ability to infect all existing Xcode projects on a compromised system amplifies its spread, especially through open-source repositories on GitHub. Unit 42's analysis, published July 31, 2026, highlights a heightened volume of attacks targeting developers in South Asia, consistent with Trend Micro's initial 2020 reporting on the family.

Technical Analysis

XCSSET v40's infection chain is designed for stealth and modularity. The malware injects an initial downloader script into benign Xcode project files and vulnerable Git repositories. The endpoint infection triggers only when a developer builds the project locally, making it difficult to detect before execution. The payload generation is scrambled at compile time, switching between nested layers of encryption mechanisms.

The infection chain consists of four stages before final payload execution:

  1. Initial loader script establishes C2 communication.
  2. Second stage collects basic fingerprinting information and downloads further modules.
  3. Third stage drops a temporary staging applet to load the final stage into volatile memory.
  4. Fourth stage is the core module logic, which executes additional specialized modules in memory.

Once the memory-resident core module (internally called "boot") becomes active, the malware terminates its staging processes and deletes all installation files from the disk, reducing its digital footprint. This fileless approach complicates forensic analysis and traditional endpoint detection.

Unit 42 identified 17 distinct modules, each designed for a specific purpose, including keyloggers, clipboard hijackers, and browser hijackers. The new Chrome hijacking backdoor wraps the benign Google Chrome binary in a malicious persistence script. When a victim launches Chrome, the wrapper executes, redirecting browser interactions via the CDP, a legitimate Chromium feature. This allows the attackers to control the browser, potentially stealing credentials, injecting content, or exfiltrating data.

The second new module, a Telegram trojanizer, likely abuses the Telegram API for C2 communications or data exfiltration, though Unit 42's analysis does not detail its full functionality. The operators also enhanced legacy modules, improving their ability to evade detection and expand their reach.

Indicators of Compromise

Unit 42's report does not provide specific IOCs such as hashes, IPs, or domains in the public summary. However, defenders should monitor for suspicious Xcode project files that contain embedded scripts or unusual build phases. The malware's C2 infrastructure is described as rotating, so network defenders should look for anomalous outbound connections from developer workstations, especially those using non-standard ports or protocols.

Tactics, Techniques & Procedures

XCSSET v40 employs a range of MITRE ATT&CK techniques. The initial access vector is supply chain compromise (T1195.001), leveraging malicious Xcode projects. Execution occurs via the build process, often using AppleScript or shell scripts (T1059.002). For defense evasion, the malware uses in-memory execution (T1055) and deletes installation files (T1070.004) to avoid disk forensics. Command and control is established over web protocols (T1071.001) with rotating infrastructure. Credential access is achieved through keyloggers and clipboard hijackers (T1555). The use of the Chrome DevTools Protocol is a novel technique for browser hijacking, falling under T1555 or T1185 (browser session hijacking).

Threat Actor Context

XCSSET is a macOS malware family first discovered by Trend Micro in 2020. Microsoft researchers analyzed two subsequent versions in March and September 2025, indicating ongoing development. The latest version, v40, is named by the threat actor, though the security community has historically identified only a handful of intermediary versions without formal version labels. The targeting of developers in South Asia aligns with Trend Micro's initial reporting, suggesting a consistent regional focus. The operators remain unidentified, but their sophistication and sustained investment in the malware's capabilities indicate a well-resourced actor.

Mitigations & Recommendations

Given the supply chain nature of XCSSET v40, developers and organizations should take the following steps:

  • Audit Xcode projects: Review all Xcode projects, especially those cloned from public repositories, for suspicious build scripts or embedded binaries. Look for unusual files in the project directory that are not part of the standard Xcode structure.
  • Verify repository integrity: Before building any project from a third-party source, verify the repository's integrity using checksums or signed commits. Be cautious of projects that have recently changed ownership or have suspicious commit history.
  • Monitor developer endpoints: Deploy endpoint detection and response (EDR) solutions that can detect in-memory execution and fileless malware. Monitor for unusual outbound connections from developer workstations, particularly to unknown domains.
  • Restrict browser permissions: Since the malware abuses the Chrome DevTools Protocol, consider disabling remote debugging features in Chrome or restricting access to the CDP port (typically 9222) via firewall rules.
  • Use network segmentation: Isolate development environments from production networks to limit the blast radius of a compromised developer machine.
  • Stay informed: Follow updates from security vendors like Unit 42 and Microsoft for new IOCs and detection rules as the campaign evolves.

Stay Updated

Get the latest cybersecurity news delivered to your inbox.

Related Articles