macOS开发者成活靶子！XCSSET v40借Xcode项目投毒，已有大厂中招

导语：沉寂数月之后，macOS平台上最狡猾的木马家族之一XCSSET携新版v40卷土重来。Palo Alto Networks旗下Unit 42研究人员发现，攻击者这次的手法依然是老套路——入侵Git仓库，向Xcode项目注入恶意下载器脚本，开发者一旦构建这些被污染的项目，整个系统上的所有Xcode项目都将被感染。木马新引入Chrome浏览器劫持和Telegram替换木马，十七个模块同时运作，macOS的安全防线在它面前几乎被碾压殆尽。

一、事件概述

XCSSET是一个专注于macOS系统的木马程序，自2021年起就开始活跃，曾多次利用零日漏洞发起攻击。2025年9月，微软率先警告了通过被污染Xcode项目传播的XCSSET活动。2026年4月中旬至5月初，Unit 42研究人员再次观测到两波XCSSET版本40的攻击浪潮。

攻击的核心路径：攻击者首先入侵存在漏洞的Git仓库，向Xcode项目中的正常文件注入下载器脚本。开发者从GitHub下载这些被污染的项目并在本地构建时，恶意代码自动执行，感染开发者的系统。一旦开发机被感染，XCSSET会进一步攻陷（compromise）该系统上的每一个其他Xcode项目，并通过共享源代码继续横向扩散。

Unit 42研究团队将这次攻击的感染链定性为”四阶段攻击链”，最终投放17个独立模块，实现凭证窃取、键盘记录、剪贴板操纵、浏览器劫持和数据泄露等恶意行为。

二、全新攻击环节：四阶段感染链详解

根据Unit 42的详细分析，XCSSET v40维持了一贯的多阶段攻击设计，但在每个环节都做了升级优化。

2.1 第一阶段：初始投递

攻击者通过入侵Git仓库，将恶意下载器脚本注入到Xcode项目的源文件之中。这些被污染的项目被上传至GitHub，等待开发者下载使用。由于Xcode项目本身来源多样（开源库、教程代码、第三方组件），开发者往往不会对每个项目进行深度安全审查，这就给了攻击者可乘之机。

2.2 第二阶段：构建时触发

开发者克隆并构建这些项目时，注入的恶意脚本随着正常的构建流程自动执行。与传统的恶意软件投递方式不同，这种”供应链投毒”模式利用的是开发者自己的构建工具链，不需要用户主动执行任何可疑操作——你只是按下了Build按钮。

2.3 第三阶段：系统全面感染

一旦某台开发机被感染，XCSSET会立即开始横向移动。它会扫描本地所有Xcode项目文件，并将恶意代码注入到每一个项目之中。这意味着即便开发者从干净来源重新克隆项目，只要经过这台已经被感染的开发机处理，新项目也会被污染。

2.4 第四阶段：模块化恶意载荷投放

感染成功后，XCSSET会部署包含17个模块的完整恶意负载，各模块分工明确，协同运作。

三、新增模块一：Chrome浏览器劫持

XCSSET v40引入了全新的Chrome劫持模块，这是该木马家族迄今为止最复杂的浏览器攻击组件。

木马用恶意启动器包装Chrome浏览器，并在本地端口上启用Chrome开发者工具协议（CDP），从攻击者的指令控制（C2）服务器获取JavaScript代码。这一架构使攻击者能够：

• 中间人攻击（MiTM）：拦截所有Web流量，包括明文凭据、Session Cookie
• 加密货币交易操纵：专门针对MetaMask等加密货币钱包插件，在用户发起转账时将目标地址替换为攻击者控制的钱包地址，直接截留资金
• 无文件后门：通过CDP协议执行系统命令，实现无文件（fileless） reverse shell。值得注意的是，Google已在Windows版Chrome中封堵了这一技术，并正在将该防护扩展至macOS

四、新增模块二：Telegram木马化组件

XCSSET v40还引入了一个全新的”Telegram trojanizer”组件，其功能更为隐蔽。

该模块的运作方式极其直接：删除受感染系统上原始的Telegram Desktop应用程序，用一个恶意版本替换。由于Telegram Desktop本身是开源软件，攻击者可以相对容易地制作一个功能几乎一致但包含后门的版本。

受感染的用户如果继续使用这个伪造的Telegram Desktop，攻击者就能拦截受害者的通信内容，包括文字消息、文件传输、甚至语音通话。Unit 42表示，由于无法获取该模块的加密配置，其具体功能细节尚不明确。

五、检测规避技术大升级

XCSSET v40不仅在恶意功能上做了扩展，其检测规避技术也达到了新的高度：

• 服务端动态重编译：Loader会在C2服务器上定期重新编译，每次编译使用不同的加密密钥，使静态分析更加困难
• 双向加密通信：入站和出站通信使用不同的加密密钥，防止流量分析
• 代码混淆：函数名、变量名、字符串均使用构建专属的密码进行混淆，传统的字符串搜索和特征码匹配完全失效
• 强制的杀软瘫痪：木马会主动尝试禁用macOS的多层安全机制，包括XProtect（苹果的恶意软件检测系统）、MRT（Malware Removal Tool）、TCC（Transparency, Consent and Control，隐私权限框架）以及Rapid Security Response（快速安全响应）
• 云服务劫持：木马会终止Apple的CloudTelemetryService，防止 telemetry数据上报到苹果的安全服务器
• 更新屏蔽：阻止XProtect签名库更新，确保即便苹果发布了新的检测特征，旧版本的XCSSET依然不会被识别

六、防护建议

针对XCSSET v40的攻击特点，Unit 42给出了以下防护建议：

针对开发者：

• 在构建开源Xcode项目之前，务必检查Git提交历史，识别异常的代码注入
• 使用静态代码分析工具扫描第三方依赖，防止被污染的仓库进入开发流程
• 对来源不明的Xcode项目保持高度警惕，尽量在隔离环境（虚拟机）中构建

针对企业安全团队：

• 监控异常的AppleScript活动（XCSSET大量使用AppleScript进行横向移动）
• 检测未经授权的浏览器修改，特别是Chrome的启动参数变化
• 监控可疑的macOS defaults域配置变更
• 注意绕过Gatekeeper（macOS应用签名验证）的即席签名（ad hoc-signed）应用程序
• 定期审计开发团队从GitHub拉取的代码，检测潜在的投毒行为

七、总结

XCSSET v40的这次回归，再次证明了软件供应链攻击的可怕威力。当攻击者将恶意代码注入到你信任的开发工具和开源项目中时，传统的安全防护几乎完全失效——你以为自己只是在构建一个开源项目，实际上已经在运行攻击者的恶意代码。

对于macOS开发者来说，尤其需要警惕：从GitHub下载的Xcode项目，即便是star数极高的热门项目，也可能在某个时间点被攻击者污染。构建前的安全审查、使用隔离环境构建、定期检查系统安全状态，这些习惯应当成为每一位macOS开发者的基本素养。

毕竟——在这个时代，开发者才是攻击者最想突破的那道防线。

版权声明：本文翻译自BleepingComputer，原文链接：https://www.bleepingcomputer.com/news/security/new-xcsset-variant-targets-macos-devs-via-compromised-xcode-projects/