Do Son 
New XCSSET v40 TTPs | Image: Unit 42
At a glance
| Malware family | XCSSET (version 40) |
| Threat actor | Unattributed; tracked by Unit 42 since 2020, same developer lineage suspected but not named |
| Target | macOS software developers, with a heightened volume of attacks across South Asia |
| Delivery vector | Poisoned Xcode projects on GitHub and vulnerable Git repositories |
| Key capabilities | Browser hijacking, credential theft, clipboard monitoring, Telegram trojanizing, data exfiltration |
| Source | Palo Alto Networks Unit 42, with prior tracking from Trend Micro and Microsoft |
TL;DR: XCSSET v40 malware resurfaced in April 2026 after months of dormancy. This version hides its core logic in memory and spreads through dozens of legitimate Xcode projects with thousands of active users. Unit 42 says the update adds polymorphic payloads, a Chrome hijacking backdoor, and a Telegram trojanizer.
Why it matters
XCSSET first surfaced in 2020, and Microsoft documented two more versions in 2025. Each update expanded the malware’s reach inside the developer supply chain. Version 40 marks the biggest architectural shift yet, according to Unit 42’s technical analysis of the campaign.
The researchers describe the update bluntly: “This version’s advanced architecture hides its core logic in memory space, reducing its digital footprint.” A developer who builds an infected project locally can unknowingly hand attackers browser sessions, credentials, and messaging app data.
Delivery
The malware spreads by hiding an initial downloader script inside benign-looking Xcode project files. Attackers plant this script in legitimate GitHub repositories and vulnerable Git projects. Infection stays dormant until a developer clones the project and builds it locally, at which point the script executes with the developer’s own permissions.
Infection chain
XCSSET v40 malware runs through four conceptual stages before the final payload activates. An initial loader establishes contact with the command server. A second stage fingerprints the machine and requests further modules.
A temporary staging step then loads the core module into memory only, avoiding disk writes. Once that memory-resident core activates, the malware deletes its own installation files from disk. This step alone sharply reduces what forensic tools can later recover.
Unit 42 says it uncovered 17 distinct modules delivered this way, including two new ones: a Chrome hijacking backdoor and a Telegram trojanizer. The Chrome module abuses the Chrome DevTools Protocol to inject scripts into the browser and intercept cryptocurrency wallet activity. The Telegram module replaces the legitimate Telegram app with a trojanized copy signed locally on the victim’s machine.
The Telegram module did not appear in the initial April 2026 wave. Researchers first spotted it a month later, in May 2026. That gap suggests the operators kept refining the malware even after the campaign was already active in the wild.
Command-and-control and data exfiltration
XCSSET v40 malware separates inbound and outbound traffic with distinct encryption keys, a design change from earlier versions that used one shared key. Modules are streamed to infected machines and re-encrypted on each delivery, so identical payloads never produce the same network signature twice.
Unit 42 also found that the malware disables macOS update channels, blocks telemetry reporting to Apple, and resets permission prompts to trick users into re-approving automation access. This defense-impairing pattern is confirmed by Unit 42’s direct analysis rather than suspected. The report also confirms an anti-virtual-machine check: infected systems that appear to be sandboxes receive no further modules.
Defense and detection guidance
Unit 42 recommends behavior-based detection over signature matching, since XCSSET v40 malware rotates its binaries and encryption on a regular cycle. Specific steps include watching for abnormal AppleScript activity, unauthorized browser launcher modifications, and unexpected entries in the macOS defaults configuration system.
Development teams should also scan open-source dependencies before pulling them into build pipelines, and treat any ad hoc code-signed application with suspicion. Because the malware exploits the trust between a developer’s machine and its build tools, the strongest defense combines supply-chain scanning with runtime anomaly detection rather than relying on either alone.
Organizations should also track code signers that bypass Apple’s Gatekeeper checks and flag any binary signed outside normal developer workflows. Reviewing dependency changes before every build catches a poisoned project before it ever reaches a developer’s machine.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
