Threat Research Center Threat Research Malware Malware The Xcode Assassin Returns: A Deep Dive Into the Latest XCSSET Version 16 min read Related Products Advanced DNS Security Advanced URL Filtering Cloud-Delivered Security Services Cortex Cortex XDR Cortex XSIAM Unit 42 Incident Response By: Adva Gabay Noa Dekel Published: July 31, 2026 Categories: Malware Threat Research Tags: Browser hijacking Credential theft Data exfiltration Infection chain Malware Obfuscation XCSSET malware Share 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 . Related Unit 42 Topics Supply Chain , Backdoor , macOS 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. Figure 1. Infected Xcode project on GitHub. 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. Figure 2. XCSSET v40 full 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. Figure 3. Chrome-hijacking backdoor’s execution chain. Inside the chrome_remote Binary The chrome_remote binary dropped by the browser hijacking module establishes a persistent WebSocket connection to the C2 server to pull down real-time JavaScript payloads. Leveraging CDP's ability to inject code before a page even loads allows the malware to force the browser to evaluate and execute these remote scripts on every new tab or document the user opens. Once injected into a webpage, the malware’s dynamic scripts override critical browser APIs to manipulate the user's active session for the following goals: Traffic interception: Hooks placed on window.fetch and XMLHttpRequest monitor to exfiltrate sensitive data streams, credentials and API tokens Crypto wallet manipulation: Intercepting MetaMask's Ethereum provider allows the malware to alter cryptocurrency wallet addresses or manipulate decentralized application (dApp) transactions Credential theft: Overriding password-manager autofill fields captures credentials This module is able to pivot from a browser hijack to full host-level compromise, operating within the context of the legitimate Google Chrome process. The binary monitors active tabs for specific browser console logging events. If the operator wants to run a local system command on the infected machine, they execute a standardized string such as a console.log prefixed with a specific delimiter. The chrome_remote binary intercepts this console event, strips the delimiter and passes the remaining payload to the host's underlying shell handler ( exec.Command ). The resulting shell output is then packaged and routed back through the active CDP WebSocket to the C2 server, establishing a stealthy, fileless reverse shell. We reported the information about this threat to Google. This behavior is protected against in Windows, and Google is currently working on expanding the same protections to macOS. Telegram Trojanizer We identified a new Telegram Desktop trojanizer module in May 2026 that was absent from the April 2026 deployment. The delayed introduction of this module demonstrates that the threat actor was actively refining XCSSET v40 after it was already deployed in the wild. This new module performs the following activities: Downloading a pre-built malicious Telegram.app ZIP Wiping the legitimate copy Dropping the C2-supplied replacement in its place Ad hoc code-signing the fake Telegram app Issuing a kill command to the original Telegram process so the victim relaunches the trojanized copy This module was updated with a custom AES-encrypted configuration from a dedicated endpoint ( /w?tr ). We have observed this security mechanism in other modules in earlier iterations of the XCSSET malware family. The decrypted configuration is written to ~/.tr , and a companion ~/.tr_map file tracks state. Whenever the SHA-1 of .tr changes, .tr_map is cleared. Both files are then uploaded back to the C2 as base_tr_file.txt and base_tr_map.txt . Because the configuration blob itself was not captured during our collection window, we could not verify its exact contents. However we assess that this is how XCSSET’s operators kept server-side track of which Telegram-related markers existed on each infected host. T