A new wave of the XCSSET macOS threat is making the rounds again, and this time it focuses on the development pipeline. Researchers report that the malware has resurfaced after a period of inactivity, now using compromised Xcode projects and public code hosting to reach thousands of macOS users.
What makes this campaign especially concerning is the way it turns “legitimate” work into the delivery mechanism. If developers download a tainted project and build it, the infection can trigger automatically—then continue spreading through shared source code.
How XCSSET gets into macOS development workflows
Xcode is Apple’s official software development kit (SDK) for building, testing, and publishing software across Apple platforms. In the reported infection chain, XCSSET relies on a common path: vulnerable or compromised repositories and project files.
According to Unit 42 (Palo Alto Networks), the threat actor compromises Git repositories and injects a downloader script into otherwise normal files inside Xcode projects. This approach is designed to look like regular project content, even though it contains steps that lead to malware execution.
Once an infected project is built by the developer, XCSSET can compromise other Xcode projects on the same system. From there, it can propagate further through shared code—meaning the damage can extend beyond the initial infected repository.
XCSSET version 40: new modules and stronger evasion
Researchers analyzed an updated variant of the malware, labeled v40. They observed it in two separate attack waves, one in mid-April and another in early May, following months of inactivity.
Unit 42 also notes that XCSSET has targeted macOS systems since at least 2021. In some incidents, it has been linked to zero-day exploitation as part of its attack approach.
In the attacks Unit 42 reviewed, XCSSET uses a four-stage infection chain before deploying 17 modules. These modules support a range of harmful behaviors such as credential theft, keystroke logging, clipboard manipulation, browser hijacking, and data exfiltration.
For the newest version, the researchers highlight two additional components that expand the malware’s reach:
- A Chrome hijacker that redirects browser activity through a malicious launcher and interacts with Chrome’s DevTools mechanisms.
- A Telegram trojanizer that replaces the legitimate Telegram Desktop app with a malicious version on infected systems.
Chrome hijacking: intercepting traffic and manipulating transactions
The Chrome hijacker is designed to wrap the Chrome browser in a malicious launcher. It also enables the Chrome DevTools Protocol (CDP) on a local port, allowing the attacker’s infrastructure to request JavaScript from the attacker’s command-and-control (C2).
With this setup, the attackers can intercept sensitive web activity. Unit 42 reports that the interception can include credentials, cookies, and even MetaMask transactions.
More importantly, the code allows attackers to manipulate payments in real time—redirecting funds while the user believes the transaction is normal.
Command execution via a fileless reverse shell
The same hijacker module also supports system command execution using a fileless reverse shell. While Chrome on Windows blocks this behavior, Unit 42 indicates the attacker was able to use it in this campaign and is attempting to extend protections toward macOS.
Telegram trojanizer: replacing a real app to reach communications
The Telegram trojanizer takes a destructive-but-effective approach. On infected machines, it deletes the legitimate Telegram Desktop application and replaces it with a malicious version.
While Unit 42 could not recover the malware’s encrypted configuration—so exact capabilities remain unclear—the intended goal appears to be intercepting and influencing communications by operating through a trusted, user-facing application.
What XCSSET does after it lands
Across the analyzed attacks, XCSSET exhibits a broad feature set. The reported modules support actions that can affect both identity and user activity:
- Credential theft from harvested session data and intercepted traffic.
- Keystroke logging to capture user input.
- Clipboard manipulation to alter or steal copied data.
- Browser hijacking to control web sessions and redirect actions.
- Data exfiltration to move collected information to the attackers.
Beyond what it steals, the malware also aims to reduce the chances of detection on macOS.
Disabling macOS security and breaking defensive updates
Unit 42 reports that the malware aggressively attempts to interfere with macOS security controls. The campaign includes efforts to disable or disrupt:
- XProtect
- MRT
- TCC
- Rapid Security Response
It also terminates Apple’s CloudTelemetryService and prevents XProtect signature updates. Disrupting both protection and updates can create a larger window for the attackers to operate undetected.
New evasion techniques aimed at staying hidden
Unit 42 highlights multiple detection-evasion changes in the v40 variant. These include measures designed to complicate analysis and signatures:
- Re-compiling the loader periodically on the C2 server.
- Using separate encryption keys for inbound versus outbound communications.
- Obfuscating function names, variables, and strings, including build-unique ciphers.
These techniques make the malware harder to recognize consistently across builds, even when defenders have some samples.
Practical ways to defend against the latest XCSSET activity
Because this campaign targets development assets, defense needs to focus on both code supply chain hygiene and endpoint monitoring. Unit 42 provides several recommendations for detection and prevention.
Monitor behavior that doesn’t match normal development use
Security teams should look for suspicious indicators such as:
- Anomalous AppleScript activity
- Unauthorized browser modifications
- Suspicious macOS defaults domains
- Ad hoc-signed applications that bypass Gatekeeper
These signals can help catch malware that tries to blend into post-build activity rather than only during installation.
Secure dependencies and repositories before they enter pipelines
A key prevention step is to reduce the chance that compromised repositories enter your development process. Unit 42 recommends scanning open-source dependencies and verifying that repositories have not been tampered with before they feed into software development pipelines.
In practice, this means treating external code as potentially hostile until it passes review, integrity checks, and appropriate policy controls.
Why testing the whole chain matters
Even with strong tooling, many attacks can move through environments without triggering alerts. Unit 42’s broader observation is that successful incidents are not always met with adequate detection—implying defenders need testing that covers the full attack path, not just isolated tactics.
The goal is to validate that security monitoring, detection logic, and response workflows actually catch the behaviors attackers produce at each stage, from initial build-time compromise to module deployment and follow-on actions.
Conclusion
The XCSSET macOS threat is not just another malware update—it’s an evolution in how attackers leverage developer tooling. By compromising Git repositories and injecting malicious scripts into Xcode projects, the campaign can infect systems at build time and then spread through connected source code.
With new modules for Chrome hijacking and Telegram replacement, plus aggressive attempts to disable security features and evade detection, the campaign underscores the need for supply-chain safeguards, endpoint monitoring, and thorough validation of detection coverage.
