uuid32-utilscolorinaltermncolor歸因方面要講得小心。Kaspersky 在 Securelist 的公開用語是:樣本交由 Kaspersky Threat Attribution Engine 分析後,研究員認為這批套件「可能」與一份 OceanLotus 威脅情報報告中討論過的 malware 有關。 但 Kaspersky 的威脅研究索引就較直接,寫明將這宗 PyPI ZiChatBot 活動歸因於 OceanLotus APT。
另有公開摘要形容相關歸因為「中等信心」。
目前公開資料支持的畫面,是一條跨平台 dropper chain。Kaspersky 威脅研究索引指,惡意 PyPI wheel 套件同時針對 Windows 及 Linux,內含 dropper,並會投放名為 ZiChatBot 的 malware。
有公開摘要進一步描述感染步驟:wheel 套件會抽出 DLL 或 .SO dropper,之後透過 Windows Registry 或 Linux crontab 建立持久化,再部署 ZiChatBot。 換言之,風險唔只限於正式應用伺服器;開發者工作機、virtual environment、CI/build runner,以至曾安裝相關套件的 container image,都值得納入排查範圍。
ZiChatBot 最突出的一點,是將合法協作平台變成 C2 層。根據報道引述 Kaspersky 的說法,ZiChatBot 不使用傳統專用 C2 伺服器,而是透過公開團隊聊天應用 Zulip 的一系列 REST API 作為 command-and-control 基建。
Zulip 的官方 API 文件顯示,它支援多種訊息操作,包括發送訊息、取得訊息、上載檔案、編輯或刪除訊息、建立 message narrow,以及處理 channel topic 等功能。 Zulip 的 bot 文件亦提到,bot 可以截取、查看和處理由用戶發出的訊息,再發送新訊息作回覆。
放到 C2 場景,高層次理解就是:攻擊者指令可以被包裝成聊天室訊息或按 topic 分流的訊息;malware 則可以讀取相關訊息,再經同一個服務回傳結果。不過,現有公開來源沒有披露 ZiChatBot 使用的確實 Zulip workspace、bot 憑證、API endpoint 次序或完整指令集。因此,較穩妥的講法是:ZiChatBot 濫用 Zulip 合法 REST API 功能做 C2,而不是依賴攻擊者自行營運的 C2 基建。
對防守團隊而言,實際啟示是:去到合法雲端或協作服務的流量,仍然可以可疑。重點不是「Zulip 是否正常服務」,而是某一部 host、某一個 process、某個 CI job 或 service account,平時是否有合理原因要打 Zulip API。若偵測只靠封鎖已知惡意 domain,這類借用合法平台的 C2 便較容易走漏眼。
第一步是做套件盤點。檢查開發者電腦、build runner、virtual environment、dependency lockfile,以及 container image,有沒有出現 uuid32-utils、colorinal、termncolor。
第二,翻查由 2025 年 7 月起的安裝紀錄,這是 Kaspersky 指出惡意 wheel 套件開始被上載的時段。 如果在 log 或 artifact 入面見到上述套件,應先保留環境作調查,而不是只把套件刪走就當處理完成。
第四,檢視 network 及 process telemetry,特別是由 Python interpreter、package install process、CI worker、伺服器或 service account 發出的 Zulip API 活動。判斷重點是:該 host 和 process 是否本來就應該同 Zulip 溝通。
Comments
0 comments