OceanLotus 相關 PyPI 攻擊：ZiChatBot 如何把 Zulip API 變成 C2

Kaspersky 這次揭露的事件，重點應放在「惡意套件散布」而不是「PyPI 或 Zulip 遭入侵」。公開報導描述的是：自 2025 年 7 月起，有人將惡意 Python wheel 套件上傳到 PyPI（Python Package Index，Python 生態常用的套件索引庫），並在 Windows 與 Linux 系統上暗中投放一個先前未知的惡意軟體家族 ZiChatBot。

這起事件最不尋常的地方，不只是它利用 PyPI 作為散布管道，而是 ZiChatBot 的命令與控制（Command and Control，C2）設計。根據對 Kaspersky 分析的報導，ZiChatBot 並未連往傳統的專用 C2 伺服器，而是使用公開團隊聊天應用 Zulip 的一系列 REST API 作為 C2 基礎設施。

Kaspersky 發現了什麼

Kaspersky 在 Securelist 文章中表示，研究人員在日常威脅獵捕中發現，自 2025 年 7 月起，有一系列惡意 wheel 套件被上傳到 PyPI；Kaspersky 已將資訊分享給公開資安社群，相關惡意軟體也已從套件庫移除。

這些套件並不是單純壞掉或空殼的誘餌。Kaspersky 指出，這些 wheel 套件確實實作了其 PyPI 頁面上宣稱的功能，但真正目的，是在背後偷偷投放惡意檔案。 The Hacker News 也引用同一發現指出，這些套件表面上可正常運作，實際上設計目的是在 Windows 與 Linux 系統上隱蔽投放 ZiChatBot。

公開報導點名了這次活動中的 3 個假 PyPI 套件：

• uuid32-utils
• colorinal
• termncolor

至於歸因，措辭需要謹慎看待。Kaspersky 的 Securelist 文章說，樣本被送交 Kaspersky Threat Attribution Engine 分析，結果顯示這些套件「可能」與一份 OceanLotus 威脅情報報告中討論的惡意軟體有關。 但 Kaspersky 的威脅研究索引用語更直接，稱該公司將這起 PyPI ZiChatBot 活動歸因於 OceanLotus APT。 另有公開摘要則將此歸因描述為「中等信心」。

從惡意 wheel 到 ZiChatBot：感染鏈輪廓

目前公開資訊支持的圖像，是一條跨平台 dropper 感染鏈。Kaspersky 威脅研究索引稱，這些惡意 PyPI wheel 套件同時鎖定 Windows 與 Linux，內含 dropper，並投放被稱為 ZiChatBot 的惡意軟體。

一份公開摘要進一步描述，感染流程會從 wheel 套件中解出 DLL 或 .SO dropper，接著在 Windows 透過 Registry、在 Linux 透過 crontab 建立持久化，最後部署 ZiChatBot。

這點對資安團隊很關鍵：風險不只在正式應用伺服器，也可能落在開發者工作站、Python 虛擬環境、CI/CD 建置 runner，以及曾安裝相關套件的容器映像檔。

同時，這起事件也提醒開發團隊：套件「看起來能用」不代表安全。Kaspersky 稱，這些惡意 wheel 的確提供了頁面上宣稱的功能，但同時也投放隱藏的惡意檔案。

ZiChatBot 如何把 Zulip API 當成 C2

ZiChatBot 最突出的設計，是把合法協作平台變成控制通道。根據對 Kaspersky 發現的報導，ZiChatBot 沒有與專用 C2 伺服器通訊，而是使用 Zulip 這個公開團隊聊天應用的多個 REST API 作為命令與控制基礎設施。

從 Zulip 的公開 API 文件來看，它本來就支援聊天平台常見操作，例如傳送訊息、取得訊息、上傳檔案、編輯或刪除訊息、建立 message narrow，以及處理頻道主題等功能。 Zulip 的機器人文件也說明，bot 可以攔截、檢視並處理使用者送出的訊息，再送出新的回覆訊息。

用高層次方式理解，這代表攻擊者的指令可以被包裝成聊天訊息或特定主題下的訊息；惡意程式則可擷取相關訊息，再透過同一服務回傳執行結果。本文所依據的公開來源並未揭露 ZiChatBot 使用的確切 Zulip workspace、bot 憑證、API endpoint 順序或完整命令集，因此較安全、也較準確的說法是：ZiChatBot 濫用 Zulip 合法 REST API 功能來做 C2，而不是依賴攻擊者自有的 C2 基礎設施。

這不代表 Zulip 或 PyPI 被攻破

Zulip 這個細節容易被誤讀，但目前公開資訊並不表示 Zulip 本身遭到入侵。相關報導描述的是正常 REST API 與 bot 式訊息功能遭濫用，而不是聊天服務被攻破。

同樣地，這也不代表 PyPI 基礎設施遭入侵。Kaspersky 的描述是惡意 wheel 套件被上傳到 PyPI，且相關惡意軟體後來已自套件庫移除。

對防禦方而言，真正的啟示很務實：連往合法協作服務的流量，不一定就等於正常。若某台主機、某個程序、某個 CI job 或服務帳號平常沒有理由存取 Zulip，卻突然呼叫 Zulip API，就值得調查。只依靠封鎖攻擊者網域的黑名單，可能漏掉這種「借道合法服務」的手法；調查時應納入程序脈絡與業務使用合理性，而不只是看目的地名聲。

資安團隊應優先檢查什麼

首先做套件盤點。搜尋開發者電腦、建置 runner、Python 虛擬環境、dependency lockfile 與容器映像檔中，是否出現 uuid32-utils、colorinal、termncolor。

接著回看 2025 年 7 月以後的安裝時間線，這是 Kaspersky 指出惡意 wheel 開始被上傳的時段。 如果在記錄或成品中發現上述套件，不宜只刪除套件就結案；應先保留環境與相關證據，以便後續鑑識。

在 Windows 系統上，應檢查 Registry 中是否有非預期持久化項目；在 Linux 系統上，則要檢查可疑 crontab。這與公開感染鏈摘要中描述的持久化方式相符。

也應檢視網路與程序遙測：是否有 Python interpreter、套件安裝程序、CI worker、伺服器或服務帳號，在不符合平常使用情境下呼叫 Zulip API。重點不是 Zulip 是否為合法服務，而是「這台主機、這個程序」是否有合理理由與 Zulip API 通訊。

最後，不要把功能正常當成信任依據。這起活動中的套件據報確實提供宣稱功能，但同時也扮演投放惡意檔案的 dropper。

重點結論

這起與 OceanLotus 相關的 PyPI 活動，涉及自 2025 年 7 月起上傳的惡意 wheel 套件；公開點名的套件包括 uuid32-utils、colorinal、termncolor。 這些套件會在 Windows 與 Linux 系統上投放 ZiChatBot，而 ZiChatBot 最具辨識度的操作選擇，是使用 Zulip REST API 作為命令與控制通道，而非連往攻擊者自架的專用 C2 伺服器。