這起事件最不尋常的地方,不只是它利用 PyPI 作為散布管道,而是 ZiChatBot 的命令與控制(Command and Control,C2)設計。根據對 Kaspersky 分析的報導,ZiChatBot 並未連往傳統的專用 C2 伺服器,而是使用公開團隊聊天應用 Zulip 的一系列 REST API 作為 C2 基礎設施。
Kaspersky 在 Securelist 文章中表示,研究人員在日常威脅獵捕中發現,自 2025 年 7 月起,有一系列惡意 wheel 套件被上傳到 PyPI;Kaspersky 已將資訊分享給公開資安社群,相關惡意軟體也已從套件庫移除。
這些套件並不是單純壞掉或空殼的誘餌。Kaspersky 指出,這些 wheel 套件確實實作了其 PyPI 頁面上宣稱的功能,但真正目的,是在背後偷偷投放惡意檔案。 The Hacker News 也引用同一發現指出,這些套件表面上可正常運作,實際上設計目的是在 Windows 與 Linux 系統上隱蔽投放 ZiChatBot。
公開報導點名了這次活動中的 3 個假 PyPI 套件:
uuid32-utilscolorinaltermncolor至於歸因,措辭需要謹慎看待。Kaspersky 的 Securelist 文章說,樣本被送交 Kaspersky Threat Attribution Engine 分析,結果顯示這些套件「可能」與一份 OceanLotus 威脅情報報告中討論的惡意軟體有關。 但 Kaspersky 的威脅研究索引用語更直接,稱該公司將這起 PyPI ZiChatBot 活動歸因於 OceanLotus APT。 另有公開摘要則將此歸因描述為「中等信心」。
目前公開資訊支持的圖像,是一條跨平台 dropper 感染鏈。Kaspersky 威脅研究索引稱,這些惡意 PyPI wheel 套件同時鎖定 Windows 與 Linux,內含 dropper,並投放被稱為 ZiChatBot 的惡意軟體。
一份公開摘要進一步描述,感染流程會從 wheel 套件中解出 DLL 或 .SO dropper,接著在 Windows 透過 Registry、在 Linux 透過 crontab 建立持久化,最後部署 ZiChatBot。
這點對資安團隊很關鍵:風險不只在正式應用伺服器,也可能落在開發者工作站、Python 虛擬環境、CI/CD 建置 runner,以及曾安裝相關套件的容器映像檔。
同時,這起事件也提醒開發團隊:套件「看起來能用」不代表安全。Kaspersky 稱,這些惡意 wheel 的確提供了頁面上宣稱的功能,但同時也投放隱藏的惡意檔案。
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 這個細節容易被誤讀,但目前公開資訊並不表示 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 伺服器。
這起事件最不尋常的地方,不只是它利用 PyPI 作為散布管道,而是 ZiChatBot 的命令與控制(Command and Control,C2)設計。根據對 Kaspersky 分析的報導,ZiChatBot 並未連往傳統的專用 C2 伺服器,而是使用公開團隊聊天應用 Zulip 的一系列 REST API 作為 C2 基礎設施。
Kaspersky 在 Securelist 文章中表示,研究人員在日常威脅獵捕中發現,自 2025 年 7 月起,有一系列惡意 wheel 套件被上傳到 PyPI;Kaspersky 已將資訊分享給公開資安社群,相關惡意軟體也已從套件庫移除。
這些套件並不是單純壞掉或空殼的誘餌。Kaspersky 指出,這些 wheel 套件確實實作了其 PyPI 頁面上宣稱的功能,但真正目的,是在背後偷偷投放惡意檔案。 The Hacker News 也引用同一發現指出,這些套件表面上可正常運作,實際上設計目的是在 Windows 與 Linux 系統上隱蔽投放 ZiChatBot。
公開報導點名了這次活動中的 3 個假 PyPI 套件:
uuid32-utilscolorinaltermncolor至於歸因,措辭需要謹慎看待。Kaspersky 的 Securelist 文章說,樣本被送交 Kaspersky Threat Attribution Engine 分析,結果顯示這些套件「可能」與一份 OceanLotus 威脅情報報告中討論的惡意軟體有關。 但 Kaspersky 的威脅研究索引用語更直接,稱該公司將這起 PyPI ZiChatBot 活動歸因於 OceanLotus APT。 另有公開摘要則將此歸因描述為「中等信心」。
目前公開資訊支持的圖像,是一條跨平台 dropper 感染鏈。Kaspersky 威脅研究索引稱,這些惡意 PyPI wheel 套件同時鎖定 Windows 與 Linux,內含 dropper,並投放被稱為 ZiChatBot 的惡意軟體。
一份公開摘要進一步描述,感染流程會從 wheel 套件中解出 DLL 或 .SO dropper,接著在 Windows 透過 Registry、在 Linux 透過 crontab 建立持久化,最後部署 ZiChatBot。
這點對資安團隊很關鍵:風險不只在正式應用伺服器,也可能落在開發者工作站、Python 虛擬環境、CI/CD 建置 runner,以及曾安裝相關套件的容器映像檔。
同時,這起事件也提醒開發團隊:套件「看起來能用」不代表安全。Kaspersky 稱,這些惡意 wheel 的確提供了頁面上宣稱的功能,但同時也投放隱藏的惡意檔案。
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 這個細節容易被誤讀,但目前公開資訊並不表示 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 伺服器。