公开报道点名了三个参与该活动的假 PyPI 库:
uuid32-utilscolorinaltermncolor归因部分需要谨慎阅读。卡巴斯基 Securelist 原文称,样本被提交至 Kaspersky Threat Attribution Engine(KTAE)分析,研究人员认为这些包可能与一份关于 OceanLotus 的威胁情报报告中讨论的恶意软件有关。 但卡巴斯基的威胁研究索引表述更直接,称该公司将 PyPI ZiChatBot 活动归因于 OceanLotus APT。 另有公开摘要把这一归因描述为中等置信度。
从公开信息看,这是一条跨平台投递链。卡巴斯基威胁研究索引称,恶意 PyPI wheel 包同时针对 Windows 和 Linux,包内包含投递器,用于投递名为 ZiChatBot 的恶意软件。
一份公开摘要进一步描述称,攻击链会从 wheel 包中提取 DLL 或 .SO 投递器,通过 Windows 注册表或 Linux crontab 建立持久化,随后部署 ZiChatBot。 这意味着排查范围不应只盯线上应用服务器,也应覆盖开发者工作站、虚拟环境、构建执行器和容器镜像等可能安装过相关依赖的位置。
这次事件还提醒开发团队:包能正常工作,并不等于可信。卡巴斯基称,这些恶意 wheel 包确实提供了页面上宣称的功能,但同时也在后台投递隐藏的恶意文件。
ZiChatBot 的特别之处在于,它把一个合法协作平台变成了 C2 层。公开报道援引卡巴斯基称,ZiChatBot 并不连接专用 C2 服务器,而是使用 Zulip 这款公共团队聊天应用的 REST API 作为命令与控制基础设施。
从 Zulip 官方 API 文档看,其消息相关接口支持发送消息、获取消息、上传文件、编辑或删除消息、构造 narrow(消息筛选条件),并处理频道话题等操作。 Zulip 的机器人文档也说明,机器人可以截获、查看并处理用户在 Zulip 中发送的消息,再发送新的回复消息。
高层来看,攻击者指令可以表现为聊天消息或特定话题下的消息,恶意软件则可以获取相关消息并通过同一服务回传执行结果。需要强调的是,当前公开来源没有披露 ZiChatBot 使用的具体 Zulip 工作区、机器人凭据、端点调用顺序或命令集。因此,最稳妥的说法是:ZiChatBot 滥用了合法的 Zulip REST API 功能进行 C2,而不是依赖攻击者自建的专用 C2 基础设施。
Zulip 出现在攻击链中,并不意味着 Zulip 平台遭到入侵。已披露的信息描述的是对正常 REST API 和机器人式消息功能的滥用,而不是聊天服务本身被攻破。
同样,这也不意味着 PyPI 基础设施被攻陷。卡巴斯基的描述是:恶意 wheel 包被上传到 PyPI,之后恶意软件从仓库中移除。
对防守方来说,真正的难点在于:流量目的地是合法协作服务,并不自动意味着这条流量合理。如果某台主机、某个进程、某个 CI 任务或某个服务账号本来没有业务理由访问 Zulip API,这类通信就值得调查。只依赖攻击者自有域名的黑名单,可能漏掉这种滥用合法平台的 C2 模式;排查时应结合进程上下文、账号用途和业务预期,而不能只看目的域名的声誉。
首先做软件包盘点。检查开发机、构建 runner、虚拟环境、依赖锁文件和容器镜像中是否出现 uuid32-utils、colorinal 或 termncolor。
其次回看安装时间线,重点关注 2025 年 7 月以后,因为卡巴斯基称相关恶意 wheel 包从这一时间开始上传。 如果日志或构建产物中出现这些包,不建议只删除依赖后就结束处理;更稳妥的做法是保留环境证据,继续做取证和影响面分析。
在 Windows 系统上,应检查是否存在异常注册表持久化;在 Linux 系统上,应查看是否有可疑 crontab 条目。这与公开摘要中描述的感染链一致。
同时,审查网络与进程遥测:是否有 Python 解释器、包安装进程、CI worker、服务器或服务账号访问 Zulip API,而这些主体平时并不使用 Zulip。判断重点不是 Zulip 是否是合法平台,而是这台机器和这个进程是否有合理原因调用 Zulip API。
最后,不要把功能正常当作安全证明。在这次活动中,相关包据称一边实现其宣称功能,一边充当恶意文件投递器。
这起与 OceanLotus 相关的 PyPI 活动涉及自 2025 年 7 月起上传的恶意 wheel 包,公开点名的包包括 uuid32-utils、colorinal 和 termncolor。 这些包在 Windows 和 Linux 上投递 ZiChatBot,而 ZiChatBot 最突出的操作选择,是使用 Zulip REST API 作为命令与控制通道,而不是传统的攻击者专用 C2 服务器。