OceanLotus関連のPyPI攻撃：ZiChatBotはZulip APIをC2に悪用

公開情報で名前が挙がっている偽PyPIライブラリは次の3つだ。

• uuid32-utils
• colorinal
• termncolor

帰属については、表現の違いに注意したい。KasperskyのSecurelist記事は、サンプルをKaspersky Threat Attribution Engineに投入した結果、OceanLotusに関する脅威インテリジェンス報告で扱われたマルウェアと関連している可能性がある、と慎重に述べている。 一方、Kasperskyの脅威研究インデックスでは、同社はこのPyPI上のZiChatBot活動をOceanLotus APTに帰属させると、より直接的に記している。 公開サマリーの一つは、この帰属を「中程度の確度」と位置づけている。

感染の流れ：悪性wheelからZiChatBotへ

公開情報から見える感染チェーンは、WindowsとLinuxの両方を対象にしたクロスプラットフォームのドロッパー型だ。Kasperskyの脅威研究インデックスは、悪性PyPI wheelパッケージがWindowsとLinuxを狙い、ZiChatBotと呼ばれるマルウェアを配布するドロッパーを含んでいたとしている。

ある公開サマリーでは、次の段階として、wheelパッケージからDLLまたは.SOドロッパーを展開し、WindowsではRegistry、Linuxではcrontabを使って永続化し、その後ZiChatBotを配備すると説明されている。

この点は、調査対象を本番サーバーだけに限定してはいけない理由でもある。開発者の端末、仮想環境、ビルドランナー、CI環境、コンテナイメージなど、該当パッケージがインストールされ得る場所は広い。Pythonパッケージを「動くから安全」と見なすのは危うい。今回のパッケージは、表向きの機能を提供しながら、裏では悪性ファイルを配布していたと報告されている。

ZiChatBotはZulipをどうC2に使ったのか

ZiChatBotの目立った特徴は、正規のコラボレーション基盤をC2レイヤーとして使った点にある。Kasperskyの調査を報じた情報によれば、ZiChatBotは専用C2サーバーとは通信せず、公開チームチャットアプリZulipのREST APIをC2インフラとして利用していた。

Zulipの公開APIドキュメントを見ると、メッセージ送信、メッセージ取得、ファイルアップロード、メッセージ編集・削除、narrowの構築、チャンネルトピック関連の操作など、チャットベースのC2設計に悪用され得る機能がそろっている。 また、Zulipのボット関連ドキュメントでは、ボットがユーザーから送られたメッセージを受け取り、閲覧・処理し、その結果として新しい返信メッセージを送れることが説明されている。

高いレベルで言えば、攻撃者の指示はチャットメッセージやトピック単位のメッセージとして表現でき、マルウェアは関連メッセージを取得し、実行結果を同じサービス経由で返すことができる。今回提供されている公開情報には、ZiChatBotが使った正確なZulipワークスペース、ボット認証情報、APIエンドポイントの順序、コマンドセットまでは含まれていない。そのため、最も安全な言い方は「ZiChatBotは攻撃者所有の専用C2ではなく、Zulipの正規REST API機能をC2として悪用した」というものだ。

「Zulipが侵害された」という意味ではない

ここは誤解しやすい。今回のZulipに関するポイントは、Zulipそのものが侵害されたという意味ではない。引用されている報道が述べているのは、通常のREST APIやボット型メッセージ機能の悪用であり、チャットサービス自体の侵害ではない。

同様に、PyPIのインフラが侵害されたという意味でもない。Kasperskyの報告は、悪性wheelパッケージがPyPIにアップロードされ、その後リポジトリから削除されたという内容だ。

防御側にとって重要なのは、宛先が有名な正規サービスであっても安心材料にはならない、という点だ。あるホスト、プロセス、CIジョブ、サービスアカウントが通常Zulipに接続する理由を持たないなら、その通信は調査対象になり得る。攻撃者所有ドメインのブロックリストだけに頼る監視では、この種の手口を見落とす可能性があるため、通信先の評判だけでなく、プロセスの文脈と業務上の妥当性を見る必要がある。

セキュリティチームが確認すべきこと

まずはパッケージの棚卸しから始めたい。開発端末、ビルドランナー、仮想環境、依存関係ロックファイル、コンテナイメージを対象に、uuid32-utils、colorinal、termncolorの有無を確認する。

次に、Kasperskyが悪性wheelのアップロード開始時期として示した2025年7月以降のインストール履歴を確認する。 該当パッケージがログや成果物に現れた場合は、単にパッケージを削除して終わらせず、調査のために環境や証跡を保全するのが望ましい。

Windowsでは想定外のRegistry永続化、Linuxでは不審なcrontabエントリを確認する。これは公開サマリーで説明されている感染チェーンと一致する確認ポイントだ。

ネットワークとプロセスのテレメトリも重要になる。Pythonインタープリタ、パッケージインストール関連プロセス、CIワーカー、サーバープロセス、通常Zulipを使わないサービスアカウントからZulip APIへの通信がないかを調べたい。焦点は「Zulipが一般に正規サービスかどうか」ではなく、「そのホストとそのプロセスがZulip APIを呼ぶ正当な理由を持つかどうか」だ。

最後に、パッケージが期待どおり動くことと、信頼できることは別問題だと考える必要がある。今回のパッケージは、宣伝された機能を提供しながら、同時に悪性ファイルのドロッパーとして機能していたと報告されている。

要点

OceanLotusに関連するとされる今回のPyPIキャンペーンでは、2025年7月以降に悪性wheelパッケージがアップロードされ、公開情報ではuuid32-utils、colorinal、termncolorが名前として挙がっている。 それらのパッケージはWindowsとLinuxにZiChatBotを配布し、ZiChatBotは攻撃者専用のC2サーバーではなく、ZulipのREST APIを指令・制御に使った点が特徴だった。