The Xcode Assassin Returns: A Deep Dive Into the Latest XCSSET Version

Executive Summary

After months of dormancy, the attackers behind the XCSSET malware released version 40 (v40), targeting the macOS ecosystem. This version’s advanced architecture hides its core logic in memory space, reducing its digital footprint.

V40 further enhances its detection evasion capabilities by combining polymorphic payload generation with fileless persistence and dynamic in-memory execution, while weakening a number of security mechanisms on the affected machine.

Since early April 2026, the malware has spread through supply chain attacks by hiding itself in the Xcode projects of dozens of legitimate applications with thousands of active users. Xcode is Apple’s integrated development environment (IDE) for building apps for its various operating systems.

XCSSET’s author enhanced the threat’s ability to spread through open-source projects on GitHub and upgraded its worming capabilities. It can now infect all existing Xcode projects on a compromised system for maximum impact.

The author used a multi-layered cipher shift to conceal the threat’s internal functions. In response, our researchers leveraged advanced AI and pattern-matching algorithms to de-obfuscate the malware's logic.

This article:

• Explores XCSSET’s updated stealth practices
• Examines the new operational modules
• Reveals findings regarding the attackers' rotating command-and-control (C2) infrastructure
• Provides mitigation strategies to detect and prevent this threat

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

• Cortex XDR and XSIAM
• Advanced URL Filtering and Advanced DNS Security

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Background

XCSSET is a modular macOS malware family that primarily targets software developers within the Apple ecosystem, spreading through Xcode projects. Threats in this family download task-specific modules from a C2 server, giving it capabilities including:

• Browser hijacking
• Credential theft
• Clipboard monitoring
• Data exfiltration

XCSSET’s initial discovery was by Trend Micro in 2020. Security researchers at Microsoft analyzed and documented two subsequent versions in March and September 2025. These updates indicate that the attackers were enhancing their codebase.

In mid-April 2026, we started tracking a new version of XCSSET. We saw a secondary wave of attacks in early May 2026 that introduced an expanded suite of operational modules.

In this new version, we observed a heightened volume of attacks targeting developers across South Asia, which is consistent with Trend Micro's initial 2020 reporting,

While the threat actor has named this latest iteration XCSSET v40, the security community has historically identified only a handful of intermediary versions, none of which featured formal version labels.

Infection Chain Analysis

In this section, we provide a high-level overview of XCSSET v40’s infection chain. The threat’s authors restructured its execution framework to be more stealthy and modular. We provide a complete step-by-step breakdown of each phase in Appendix A.

The malware injects an initial downloader script into benign project files in Xcode projects and vulnerable Git repositories. While the attack lifecycle begins with the infected codebase, the endpoint infection is triggered only when the developer builds that project locally.

The malware scrambles its payload generation at compile time, switching between nested layers of different encryption mechanisms. Figure 1 shows a benign infected Xcode project on GitHub with two separate XCSSET payloads.

The XCSSET v40 infection chain consists of four distinct stages prior to final payload execution:

• The initial loader script establishes C2 communication
• The second stage collects basic fingerprinting information on the system and downloads further modules
• The third stage includes a temporary staging applet that is dropped onto the system to load the final stage into volatile memory space
• The fourth stage is the core module logic

The moment this memory-resident core module loop becomes active, the malware terminates its staging processes and deletes all installation files from the disk. The goal of the core-module (internally called boot) is to execute and load additional, specialized modules into memory, such as keyloggers, clipboard hijackers or browser hijackers.

Figure 2 describes XCSSET v40’s infection chain.

New Module Breakdown

Our analysis of XCSSET v40 uncovered 17 distinct modules, each designed for a different goal. The modules were delivered via a dynamic C2 infrastructure and executed in memory.

We found that the operators have enhanced several of its legacy modules while introducing two new components. These include a Chrome hijacking backdoor and a Telegram trojanizer.

We provide the full list of XCSSET v40 modules in Appendix B.

Chrome Hijacking Backdoor via Chrome DevTools Protocol (CDP) Protocol

The Chrome hijacking module controls the browser by misusing a legitimate Chromium feature, the CDP.

For the CDP-based hijacking to work, the malware must redirect how the user interacts with the browser. It does this by wrapping the benign Google Chrome binary in a malicious persistence script. When a victim launches Google Chrome, the wrapper executes a three-step chain:

• The orchestrator check: First, it restarts the main XCSSET orchestrator module (boot) every time Google Chrome is initialized, ensuring the malware's core process remains active
• CDP execution: It then launches the legitimate Google Chrome application with specific command-line arguments that activate the CDP on a pre-defined local port, exposing the browser's internal engine
• chrome_remote backdoor: Finally, it drops and launches a specialized Chrome hijacking binary (chrome_remote). This binary connects to the opened CDP port, allowing the attackers to execute arbitrary JavaScript, manipulate active browser sessions and extract cookie tokens invisibly.

Figure 3 illustrates the module’s infection and execution chain.