OceanLotus 相关 PyPI 攻击：ZiChatBot 如何把 Zulip API 变成 C2 通道

先把边界说清楚：这起事件更像是针对 Python 生态用户的软件供应链投毒，而不是 PyPI 或 Zulip 平台本身被攻破。卡巴斯基在 Securelist 中称，研究人员发现自 2025 年 7 月起，有一批恶意 wheel 包被上传到 Python Package Index（PyPI），相关信息已与公共安全社区共享，恶意软件随后从仓库中移除。

对不熟悉 Python 生态的读者来说，PyPI 是 Python 包的公共索引，开发者常通过 pip 等工具在项目、虚拟环境或构建流水线中安装依赖；wheel 则是 Python 常见的包分发格式。这也解释了为什么一个看似普通的依赖包，可能成为进入开发机、CI/CD runner、服务器或容器镜像的入口。

最值得关注的不是攻击者使用了 PyPI，而是 ZiChatBot 的通信方式。公开报道援引卡巴斯基分析称，ZiChatBot 没有与传统的专用命令与控制（C2）服务器通信，而是使用公开团队聊天应用 Zulip 的一系列 REST API 作为 C2 基础设施。

卡巴斯基发现了什么

卡巴斯基称，这批恶意 wheel 包并不是空壳或明显损坏的诱饵。它们确实实现了 PyPI 页面上描述的功能，但真实目的却是悄悄投递恶意文件。 The Hacker News 对同一发现的报道也称，这些包表面上可用，实则用于在 Windows 和 Linux 系统上隐蔽投递此前未知的恶意软件家族 ZiChatBot。

公开报道点名了三个参与该活动的假 PyPI 库：

• uuid32-utils
• colorinal
• termncolor

归因部分需要谨慎阅读。卡巴斯基 Securelist 原文称，样本被提交至 Kaspersky Threat Attribution Engine（KTAE）分析，研究人员认为这些包可能与一份关于 OceanLotus 的威胁情报报告中讨论的恶意软件有关。 但卡巴斯基的威胁研究索引表述更直接，称该公司将 PyPI ZiChatBot 活动归因于 OceanLotus APT。 另有公开摘要把这一归因描述为中等置信度。

攻击链：从恶意 wheel 到 ZiChatBot

从公开信息看，这是一条跨平台投递链。卡巴斯基威胁研究索引称，恶意 PyPI wheel 包同时针对 Windows 和 Linux，包内包含投递器，用于投递名为 ZiChatBot 的恶意软件。

一份公开摘要进一步描述称，攻击链会从 wheel 包中提取 DLL 或 .SO 投递器，通过 Windows 注册表或 Linux crontab 建立持久化，随后部署 ZiChatBot。 这意味着排查范围不应只盯线上应用服务器，也应覆盖开发者工作站、虚拟环境、构建执行器和容器镜像等可能安装过相关依赖的位置。

这次事件还提醒开发团队：包能正常工作，并不等于可信。卡巴斯基称，这些恶意 wheel 包确实提供了页面上宣称的功能，但同时也在后台投递隐藏的恶意文件。

ZiChatBot 如何借用 Zulip 做 C2

ZiChatBot 的特别之处在于，它把一个合法协作平台变成了 C2 层。公开报道援引卡巴斯基称，ZiChatBot 并不连接专用 C2 服务器，而是使用 Zulip 这款公共团队聊天应用的 REST API 作为命令与控制基础设施。

从 Zulip 官方 API 文档看，其消息相关接口支持发送消息、获取消息、上传文件、编辑或删除消息、构造 narrow（消息筛选条件），并处理频道话题等操作。 Zulip 的机器人文档也说明，机器人可以截获、查看并处理用户在 Zulip 中发送的消息，再发送新的回复消息。

高层来看，攻击者指令可以表现为聊天消息或特定话题下的消息，恶意软件则可以获取相关消息并通过同一服务回传执行结果。需要强调的是，当前公开来源没有披露 ZiChatBot 使用的具体 Zulip 工作区、机器人凭据、端点调用顺序或命令集。因此，最稳妥的说法是：ZiChatBot 滥用了合法的 Zulip REST API 功能进行 C2，而不是依赖攻击者自建的专用 C2 基础设施。

这不代表 Zulip 或 PyPI 被攻破

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 服务器。