XCSSET v40 marks a significant escalation in macOS-focused supply chain attacks, weaponizing poisoned Xcode projects to hijack Chrome and Trojanize Telegram while operating almost entirely from memory with aggressive polymorphism and defense evasion.
After several months of apparent inactivity, the actors behind the XCSSET malware resurfaced with version 40 (v40), a major re-architecture of the long-running macOS developer-targeting family.
The campaign, active since early April 2026, abuses compromised Xcode projects and GitHub-hosted repositories to infect developer workstations, turning legitimate apps with thousands of users into downstream infection vectors.
Once a developer builds an infected project locally, a hidden loader script executes under the developer’s own context, inheriting broad access to the system without raising conventional permission prompts.
The v40 framework hides its core logic in volatile memory space, combining fileless persistence with polymorphic payload generation.
The loader and functional modules are delivered via a dynamic, rotating C2 infrastructure and immediately delete installation artifacts once the memory-resident core (“boot”) module is active, drastically reducing forensic visibility.
That applet loads the core logic into memory, then terminates itself and removes installation files from disk.
From that point forward, the core boot module orchestrates all subsequent activity, dynamically loading task-specific modules for keylogging, clipboard hijacking, browser subversion and data exfiltration.
Unit42 said in a report shared with GBhackers, XCSSET v40’s infection chain now follows a four-phase execution pipeline before its final payload activates: An initial loader establishes C2 communication and retrieves secondary modules, which fingerprint the host and drop a temporary staging applet.
Two new operational components define v40’s impact on end-user applications. A Chrome hijacking backdoor repurposes the legitimate Chrome DevTools Protocol (CDP) to control the browser by wrapping the Google Chrome binary in a malicious persistence script.
This design aligns with XCSSET’s historic modular architecture first documented by Trend Micro in 2020 and later expanded in Microsoft’s 2025 research into its evolving persistence and obfuscation techniques.
XCSSET v40 Infects Xcode Projects
Each browser launch restarts the boot orchestrator, enables CDP on a local port via custom command-line arguments and spawns a dedicated chrome_remote backdoor that connects over WebSocket to the attacker C2.
This allows real-time injection of JavaScript into pages, interception of traffic via hooks on window.fetch and XMLHttpRequest, credential theft through autofill manipulation and covert crypto wallet interference, with the ability to escalate into a full reverse shell by tunneling local shell commands through the CDP channel.
Google has been notified of this abuse pattern and is extending protections that already exist on Windows to macOS.
The new Telegram Desktop trojanizer goes beyond historic XCSSET modules that exfiltrated Telegram data and encryption keys.
In the v40 campaign, the malware pulls down a malicious Telegram.app archive, wipes the legitimate installation, drops a C2-controlled replacement, performs ad hoc code signing and kills the original process so victims transparently relaunch the trojanized client.
Configuration for this module is delivered via AES-encrypted blobs from dedicated Telegram-focused endpoints, with local state tracked and periodically shipped back to C2 to maintain host-level awareness of Telegram artifacts.
Technically, v40’s hallmark is an overlapping obfuscation and evasion framework spanning binaries, network payloads and source code.
The loader binary is frequently recompiled on the C2 side, yielding multiple distinct hashes for the same endpoint within a single day.
Streaming modules are encrypted with AES-256-CBC per build, each transmission using a new IV so that identical modules never share ciphertext signatures.
Network communications now adopt a dual-key architecture, separating inbound and outbound encryption keys and embedding the inbound key within compiled AppleScript, frustrating attempts to reconstruct core logic from passive telemetry alone.
Internally, every string literal is encoded via a keyed Caesar cipher with randomized alphabets, and function or variable names are scrambled using server-side substitution ciphers applied before distribution.
Unit 42 reports using AI-assisted pattern matching to break these ciphers and recover original operator-assigned identifiers, enabling deep reconstruction of the malware’s execution graph.
On the host, XCSSET v40 aggressively sabotages macOS security: it disables SoftwareUpdate channels to block XProtect, MRT and TCC database updates; holds exclusive locks on XProtect’s YARA signature files to prevent new rules from being written; interferes with CloudTelemetryService to stop telemetry samples.
Anti-VM checks in early modules ensure virtualized analysis environments receive no further payloads, preserving the integrity of the actors’ toolset.
The v40 campaign’s infrastructure uses a structured URI scheme with separate endpoints for loader downloads, module retrievals, logging, file exfiltration, heartbeat beacons and dynamic configuration (including Telegram and clipboard-specific routes).
Dozens of domains were registered and “aged” in bursts across a small IP pool, mixing .ru and .in naming to mirror newly observed targeting of developers in South Asia and reduce suspicion around newly registered infrastructure.
However, the operators weakened their own OPSEC by reusing SSL certificates, SSH keys and RDP thumbprints across multiple campaigns, enabling correlation between distinct waves of activity.
Palo Alto Networks notes that customers can detect and block XCSSET v40 behaviors through platforms such as Cortex XDR and XSIAM for AI-driven behavioral analytics, along with Advanced URL Filtering and Advanced DNS Security to disrupt C2 and malicious redirections.
IOCs
| Type | Value | Notes |
|---|---|---|
| C2 | hxxps[:]//amzndev[.]in/d/zw_sfp64 | Chrome CDP helper binary C2 |
| C2 | hxxps[:]//amzndev[.]ru/d/zw_sfp64 | Chrome CDP helper binary C2 |
| C2 | hxxps[:]//googlenets[.]ru/d/zw_sfp64 | Chrome CDP helper binary C2 |
| C2 | hxxps[:]//netcdndev[.]in/d/zw_sfp64 | Chrome CDP helper binary C2 |
| C2 | hxxps[:]//whitead[.]in/d/zw_sfp64 | Chrome CDP helper binary C2 |
| C2 | hxxps[:]//whiteads[.]ru/d/zw_sfp64 | Chrome CDP helper binary C2 |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
$1M Data Breach Warranty is Genuine Protection?: Download 10 Point Free AI SOC Breach Warranty Guide
