XCSSET v40 Malware Steals Cookies, Runs Commands via Chrome DevTools Protocol
Key Takeaways XCSSET v40 is a macOS malware variant specifically targeting developers through poisoned Xcode projects. The malware employs sophisticated stealth techniques, including memory-based...
Key Takeaways
- XCSSET v40 is a macOS malware variant specifically targeting developers through poisoned Xcode projects.
- The malware employs sophisticated stealth techniques, including memory-based execution and polymorphous payloads, to evade detection.
- A new Chrome-hijacking backdoor abuses the legitimate Chrome DevTools Protocol (CDP) to steal cookies, monitor web traffic, capture autofill data, and execute remote commands.
- Infected Xcode projects have been found in open-source repositories, posing a supply chain risk to developers and organizations.
- Mitigation requires vigilance in development environments, thorough inspection of Xcode project settings, and continuous monitoring for unusual activity.
The XCSSET malware family has resurfaced with a new iteration, v40, specifically designed to compromise macOS developers. This latest version embeds itself within malicious Xcode projects, transforming a seemingly innocuous local build into a potent supply-chain attack vector. This sophisticated malware, first identified in 2020, demonstrates an evolution towards heightened stealth and broader impact, posing significant risks to developers and any organization utilizing their code.
Table Of Content
Upon activation, XCSSET v40 possesses the capability to propagate across other development projects. This self-replicating nature amplifies the danger, potentially compromising a wide array of software and the entities that rely on it. The malware’s operational methodology prioritizes evasion, leveraging memory-based execution, dynamic payloads, and ephemeral files to minimize its footprint and avoid detection by traditional security measures.
Researchers observed increased targeting of developers in South Asia, with infected projects infiltrating open-source repositories and development workflows. According to a Palo Alto Networks report, shared with Cyber Security News (CSN), Unit 42 analysts first detected XCSSET v40 activity in mid-April 2026, followed by a second, more operationally advanced wave in early May. The report highlighted that XCSSET had been embedded in Xcode projects linked to numerous applications with active user bases.
The inherent danger lies in the assumed trustworthiness of development tools. A compromised project can appear legitimate until the moment it is built. At this critical juncture, a concealed script initiates communication with attackers, fetching additional malicious code. This scenario underscores the imperative of scrutinizing project settings with the same rigor applied to source code review, a lesson previously emphasized in discussions of XCSSET project infections.
Chrome DevTools Protocol Hijack Steals Cookies
A significant new feature in XCSSET v40 is a Chrome-hijacking backdoor that exploits the legitimate Chrome DevTools Protocol (CDP), an interface typically used for browser automation and debugging.
The malware achieves this by enveloping the authentic Chrome application in a malicious launcher. Consequently, each time Chrome is opened, the launcher re-executes XCSSET, activates CDP on a local port, and initiates a helper binary named chrome_remote.
This helper binary then connects to the exposed local CDP service, gaining the ability to execute arbitrary JavaScript within active browser sessions. This access allows the malware to harvest cookie tokens, intercept web-request traffic, extract autofill data from password managers, and even tamper with cryptocurrency wallet transactions. This technique leverages a standard browser feature rather than exploiting a vulnerability, highlighting the importance of understanding recent Chrome DevTools security updates.
The same browser channel also facilitates remote command execution. Attackers can send a specially formatted console event, which chrome_remote extracts, passes to the macOS shell, and then relays the output back through the CDP WebSocket connection. This creates a fileless reverse shell operating within a trusted Chrome process, rendering traditional file-based detection methods significantly less effective.
The intricate “Chrome-hijacking backdoor’s execution chain” illustrates the interconnectedness of the boot orchestrator, browser hijacker, chrome_remote process, and the localhost:18907 port. Google has been informed of this behavior, and while protections are already in place for Windows, efforts to extend these safeguards to macOS were reportedly underway at the time of the report.
Stealth, Persistence, and Defense Steps
Beyond its browser-hijacking capabilities, the XCSSET framework incorporates 17 distinct modules and a new Telegram Desktop trojanizer. This trojanizer can uninstall the legitimate Telegram application, install a malicious replacement provided by the attacker, sign it ad hoc, and then prompt the user to relaunch it. This tactic reflects a growing trend where malicious actors exploit common developer workflows, echoing concerns previously raised about weaponized Git hooks.
XCSSET further enhances its stealth and persistence through frequent code and encrypted payload modifications, extensive use of memory for its operations, and the storage of re-infection data within macOS preferences.
The malware actively attempts to hinder system updates and security telemetry, lock the XProtect database, and reset automation-permission decisions. These actions can lead to users encountering misleading prompts that appear to originate from Xcode or system settings, further obscuring the malicious activity.
What You Should Do
- Monitor for Anomalous Activity: Watch for unusual AppleScript executions, unexpected browser launch paths, unauthorized file writes, and the creation of abnormal preference domains using the
defaultsutility. - Isolate Ad-Hoc Signed Binaries: Scrutinize and isolate any binaries signed ad hoc, as these can bypass standard trust mechanisms.
- Vet Dependencies: Rigorously scan all project dependencies before integrating them into your development environment.
- Inspect Xcode Projects: Thoroughly examine Xcode projects for any unfamiliar build phases or suspicious scripts.
- Beware of Fake Tools: Exercise extreme caution with developer tools from unofficial sources, especially before executing any setup commands.
- Update Systems Regularly: Keep macOS and Chrome browsers updated to their latest versions to benefit from the most recent security patches.
- Validate Project Provenance: Always verify the origin and integrity of any Xcode project before compiling or running it.
- Limit Automation Permissions: Restrict automation permissions to only essential applications and services.
The fundamental takeaway for defenders is to never assume a build environment is inherently secure. Comprehensive monitoring across repositories, endpoints, browsers, and network connections is crucial. Any unexplained Chrome launches with debugging enabled should be immediately investigated. By implementing regular updates, validating project sources, and carefully managing automation permissions, organizations can significantly reduce their exposure to threats like XCSSET v40.
Indicators of Compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| C2 Domain | accapple[.]ru adschecks[.]ru adsmobi[.]ru adsmorein[.]in adsmoreme[.]in amdcdn[.]ru amzndev[.]in amzndev[.]ru amznprod[.]in applecdn[.]ru appledisk[.]ru appledns[.]ru applehosts[.]ru appletime[.]in bulksec[.]ru cdnamz[.]in |
XCSSET v40 command-and-control domains |
| C2 Domain | cdnamz[.]ru cdnapple[.]in cdnatapple[.]ru cdnroute[.]ru checkcdn[.]ru chromeads[.]ru cnmag[.]ru devnetaps[.]ru dnsapple[.]ru dnsrelays[.]ru explorecdn[.]ru fiddlejoy[.]ru figmacat[.]ru figmanets[.]in funchats[.]ru gironetcdn[.]ru |
XCSSET v40 command-and-control domains |
| C2 Domain | goalmate[.]ru googlenets[.]ru greencn[.]ru icloudsnet[.]ru imails[.]ru legalads[.]in littleads[.]in littledns[.]ru maganet[.]ru mindelgate[.]ru netapsdev[.]ru netcdnads[.]in netcdnamz[.]ru netcdndev[.]in netcorps[.]ru netsprot[.]in |
XCSSET v40 command-and-control domains |
| C2 Domain | netsproto[.]in networkads[.]in rigacdn[.]in rigmajoys[.]in rigmanet[.]ru rigmanets[.]in sahusuzuki[.]in stuffdns[.]in testjoys[.]ru timewebnet[.]in vigmanet[.]ru whitead[.]in whiteads[.]ru wincdn[.]ru windsecure[.]ru |
XCSSET v40 command-and-control domains |
| C2 URL | hxxps[:]//amzndev[.]in/d/zw_sfp64 hxxps[:]//amzndev[.]ru/d/zw_sfp64 hxxps[:]//googlenets[.]ru/d/zw_sfp64< hxxps[:]//netcdndev[.]in/d/zw_sfp64 hxxps[:]//whitead[.]in/d/zw_sfp64 hxxps[:]//whiteads[.]ru/d/zw_sfp64 |
Chrome CDP helper-binary download locations |
| C2 IP Address | 91.108.106[.]229 95.142.35[.]34 95.142.35[.]206 95.142.37[.]159 151.243.109[.]188 178.208.92[.]129 178.208.92[.]168 |
XCSSET v40 command-and-control infrastructure |
| SSL Thumbprint | 6e480d648fa1b70612f5d198a66875e28847547d | Shared SSL certificate thumbprint associated with operator infrastructure |
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.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.