XCSSET v40 represents the most significant evolution of the XCSSET malware family since its initial discovery by Trend Micro in August 2020. First documented by Palo Alto Networks' Unit 42 in their August 2026 report, this variant introduces a fundamentally re-architected execution model shifting from file-based persistence to a fully fileless, memory-resident operation.

The infection chain operates through a four-phase pipeline. In Phase 1 (Initial Compromise), a developer builds a poisoned Xcode project hosted on GitHub — the project's malicious run-script phase executes silently at build time, contacting the C2 via a curl to the /a endpoint with context p=xcode_phase. The payload generation dynamically scrambles its encoding, switching between hex and Base64 layers at compile time. In Phase 2 (Reconnaissance and Staging), the second-stage payload collects host metadata (uname -s, whoami) and transmits it to the C2. If the host profile passes anti-VM checks, the C2 returns a bash script obfuscated with a custom substitution cipher. In Phase 3 (Loader Wrappers), a main loader is downloaded to /tmp/r and an AppleScript wrapper is compiled on-the-fly as /tmp/p.app, executed in-memory via osascript, with both files deleted post-execution. In Phase 4 (Orchestrator), the boot module runs entirely in volatile memory, downloading 17 distinct module payloads from the C2 via /s/<encoded_module_name>, piping them to AppleScript for in-memory decryption and execution.

The two new operational components in v40 are the most concerning advancements. The chrome_remote module wraps the legitimate Google Chrome binary in a malicious persistence script. On each browser launch, CDP is activated on a predefined local port (port 18907), and the chrome_remote backdoor connects over a persistent WebSocket to the attacker C2. Through CDP, the module injects JavaScript before page load, hooks window.fetch and XMLHttpRequest for credential and API-token exfiltration, alters MetaMask cryptocurrency wallet addresses to manipulate dApp transactions, overrides password-manager autofill fields, and can escalate to a full fileless reverse shell by routing shell commands through browser console.log events received via the CDP WebSocket channel. Google has been notified and is extending existing Windows CDP protections to macOS. The tdesktop Telegram trojanizer module (first observed in May 2026 deployments) downloads a pre-built malicious Telegram.app ZIP from the C2, wipes the legitimate installation, drops a C2-controlled replacement signed ad hoc, kills the original Telegram process so the victim transparently relaunches the trojanized client, and manages state via AES-encrypted configuration blobs stored at ~/.tr and ~/.tr_map.

The malware deploys an unusually sophisticated defense-evasion strategy targeting multiple layers of macOS security. It disables SoftwareUpdate channels to block XProtect signature updates, MRT (Malware Removal Tool) updates, TCC database updates, and Rapid Security Response mechanisms. It spawns a Perl process that acquires and holds an exclusive file lock on XProtect's YARA rule database (XPdb), preventing signature updates from writing to disk. It runs a constant loop killing CloudTelemetryService to prevent Apple from receiving local security telemetry. When AppleEvents automation prompts are denied, it executes tccutil reset AppleEvents to clear the TCC decision database and re-presents prompts masquerading as System Settings or Xcode. The stats module performs anti-VM checks on CPU and hardware metadata, with VMs receiving no further payloads.

Polymorphism and encryption are implemented as a three-tier stack. At Layer 1 (Binary and Network Polymorphism), the loader binary is recompiled on the C2 every few hours — eight distinct hashes were observed for a single endpoint within a 24-hour window — and AES-256-CBC uses per-build keys with randomized IVs prepended to ciphertext. At Layer 2 (Network Dual-Key), inbound and outbound encryption use separate keys; the inbound key is embedded in the compiled AppleScript loader while the outbound key must be recovered from network telemetry, preventing defenders who retrieve one key from decrypting core malware logic. At Layer 3 (Source-Code Obfuscation), every string literal is encoded via a keyed Caesar cipher with randomized 52-character alphabets and variable shift values, and function/variable names are scrambled using server-side substitution ciphers applied before distribution. Unit 42 used AI-assisted pattern matching to break these ciphers and recover original identifiers.

C2 infrastructure spans over 60 registered domains across .ru and .in TLDs, aged for months before the attack wave to avoid detection flags on new registrations. The infrastructure uses a structured URI scheme with separate endpoints for loader downloads (/d/<binary_name>), module retrievals (/s/<encoded_module_name>), status logging (/l), file exfiltration (/u), heartbeat beacons (/p), and dynamic server-side configuration (/w?cbp for clipboard, /w?tr for Telegram). The operators weakened their own OPSEC by reusing SSL certificates (thumbprint 6e480d648fa1b70612f5d198a66875e28847547d), SSH keys, and RDP thumbprints across multiple campaigns, enabling infrastructure correlation. The 7 known C2 IPs span two hosting clusters: 91.108.106.229 and 95.142.35.x/95.142.37.x and 151.243.109.188 and 178.208.92.x.

Attribution remains unconfirmed. No named threat-actor group or nation-state has been formally tied to XCSSET across its six-year history (Trend Micro 2020, Microsoft 2025, Unit 42 2026). Historical indicators include a 2020 Twitter claim of authorship targeting Chinese developers and gambling businesses, along with documented ransom demands of 200 USDT from Chinese victims, suggesting primarily financially motivated cybercriminal activity rather than state-sponsored espionage. The geographic targeting has shifted in v40 toward South Asian developers (consistent with the introduction of .in TLD domains), while maintaining broader opportunistic targeting of the global macOS developer ecosystem.