PyPIの3パッケージがZulipのREST APIを悪用し新種ZiChatBotを配信——開発環境を直撃するサプライチェーンの現在地です

今日の深掘りポイント

• ゼロからのC2ではなく、Zulipという合法的なSaaSのREST APIを「操縦桿」にした“ChatOps-as-C2”型の設計が肝です。プロキシ配下や厳格なEgress制御をくぐり抜けやすい経路選択になっています。
• WindowsはDLLドロッパー、Linuxは共有オブジェクト＋cronの持続化という二刀流。開発端末とCIビルドノードの双方に刺さる作りで、被害の「広がり方」が従来より速く・深くなり得ます。
• 見かけは地味なパッケージでも、PyPI経由なら信頼連鎖を迂回できます。依存の奥に潜む微小リスクが、環境全体の重大リスクに「昇圧」される典型です。
• 短期対応はIoC探しより「経路遮断」と「依存固定」です。中期は「私設レジストリ＋ハッシュ固定＋ビルドのオフライン化」が勝ち筋です。
• 信頼性は高く、緊急性も高い部類ですが、現場が打てる手は多いです。インフラ側でのZulip等SaaS APIの検知・制御を標準メニューに織り込むべき局面です。

はじめに

PyPIで配布された3つのパッケージが、新種のZiChatBotをWindowsとLinuxに落とし込む事案が明らかになりました。特徴はC2経路の割り切り方で、攻撃者はZulipという一般的なチームチャットのREST APIをC2に据えています。つまり、独自ドメインや怪しいVPSではなく「業務で普通に使われうる」SaaSをC2の外観に被せたわけです。供給網の入口であるPyPIを起点に、業務SaaSを出口にする——この表裏の取り合わせが、企業の検知と封じ込めを難しくします。

本稿では、確認できた事実を整理しつつ、現場に効く運用オプションに落とし込みます。数値スコアに表れない“運用の手触り”に踏み込み、次のインシデントでも役に立つ意思決定指針を提示します。

深掘り詳細

事実関係（確認できた点）

• PyPI上の3パッケージがZiChatBotの配布に用いられ、WindowsとLinuxを標的にしていました。C2はZulipの公開REST APIを活用する設計です。Kasperskyの分析に基づく報道によれば、これは計画的なPyPIサプライチェーン攻撃として実行されたとされます。
• ダウンロード数は報道時点で「uuid32-utils」が1,479回、「colorinal」が614回、「termncolor」が387回でした。Linuxでは共有オブジェクトのドロッパーが特定パスへ設置され、crontabによる持続化が行われ、Windows側はDLLドロッパーが用いられたとされています。さらに、ドロッパーが既知のOceanLotus関連ドロッパーと64%の類似性を示したとの指摘もあります（いずれも報道の引用）［出典: The Hacker Newsの報道］。
• 参考: The Hacker Newsの報道（Kaspersky分析に基づく）

上記は公開報道を基にした事実整理です。詳細の技術レポート（一次情報）は今後の公開を待つ必要があります。

編集部の視点（インサイト）

• ChatOps-as-C2の強みと弱み
  • 強みは「業務SaaSの正当性」。Zulipや類似SaaSは企業環境で許可されやすく、TLS上のRESTトラフィックはNOCやSOCのホワイトリストに滑り込みがちです。C2の立ち上げコストも安価で、テイクダウン耐性もSaaSに“間借り”できます。
  • 弱みは「検知の余地がプロセス側に寄る」こと。SaaSドメインのフルブロックは現実的でないため、プロセス起点のeBPF/EDR検知（python/pipがチャットAPIへ長時間ポーリング、cron生成、DLL/soドロップ等）と、業務フローに即したセグメント別の厳格Egress制御で勝負することになります。
• パッケージ名と「つまずきポイント」
  • colorinal/termncolorは、よく使われるcolorama/termcolorとのタイポスクワッティングを想起させます（仮説）。開発者の思い込みとオートコンプリートは、サプライチェーン攻撃の“入口”として今も強力です。現場ではIDEの補完に頼らず、社内ベースラインのrequirements/lockfileから導入する文化が重要です。
• 「64%類似」から読み解くべきはアトリビューションではない
  • コード類似は再利用・売買・リーク等、様々な経路で説明できます。ここで実践的に重要なのは、DLL/soドロッパー＋SaaS C2＋cronという「組み合わせの再現性」です。別のアクターも容易に模倣可能で、再発は高確率です。つまり検知・封じ込めの汎用性を高めるのが合理的です。
• 影響半径は「開発端末→CI→クラウド認証情報」
  • 開発端末やCIが噛むと、クラウドの長寿命トークン、アーティファクト署名鍵、内部PyPI/NPM/Nexusへの発行権限など、機微資産への踏み込みが早いです。マルウェア本体の機能に関係なく、環境がもつ“権限密度”が被害規模を決めます。ここを薄めるアーキテクチャが中長期の肝になります。

脅威シナリオと影響

以下は公開情報を踏まえた仮説ベースのシナリオとATT&CK整理です。具体的なIDはATT&CKのバージョンにより表現が変わり得ますが、検知・防御の観点で重要な軸を明示します。

• シナリオ（仮説）

  1. 開発者またはCIがPyPIから当該パッケージを取得（サプライチェーン経由の初期侵入）。
  2. インストール時スクリプトや実行時コードが追加ペイロードを取得してDLL/soをドロップし、Linuxではcronで持続化、Windowsではレジストリやスケジューラ、もしくはDLLロードで持続化。
  3. マルウェア本体がZulipのREST APIに接続し、コマンド受領・実行・結果送信を実施（Webプロトコル経由のC2／SaaSの悪用）。
  4. 端末内探索と秘密情報の窃取（クラウド認証情報、リポジトリアクセス、ビルド署名鍵等）。必要に応じて横展開。
  5. 継続的なC2操作、ソース改ざんやCIパイプライン汚染、クラウドへの侵入拡大。

• 想定されるMITRE ATT&CKマッピング（仮説）

  • Initial Access: ソフトウェアサプライチェーンの妥協（Supply Chain Compromise）
  • Execution: コマンド／スクリプトインタプリタ（Python等）
  • Persistence: スケジュールタスク/ジョブ（Cron）、レジストリRun/サービス登録/DLL持続化（Windows）
  • Defense Evasion: 正規ツール／正規SaaSの悪用、命名の偽装（Masquerading）
  • Command and Control: アプリケーション層プロトコル（Web/HTTPS）、正規Webサービスの悪用（Zulip REST API）
  • Exfiltration: C2チャネル上でのデータ流出（Exfiltration Over C2 Channel）
  • Discovery/Credential Access/Lateral Movement: 開発環境特有のトークン探索、リポジトリ・CI/CDへの横展開（環境依存）

• 影響評価の要点

  • ダウンロード数は現時点で限定的でも、導入の“質”が問題です。もしCIイメージや社内テンプレートに混入すれば、短時間に組織内の標準環境へ広がります。
  • C2にSaaSを使う手口は、通信での見分けがつきにくく、封じ込め初動が遅れやすいです。結果として「初動のミス」を損害規模が増幅します。
  • Linuxの持続化は開発・ビルド系で致命度が高い一方、Windows側は情報ワークステーションや管理端末を射程に入れます。両面作戦でSOCの負荷が上がります。

セキュリティ担当者のアクション

• 48時間以内の初動チェック

  • 資産棚卸し
    • 開発端末、ビルドエージェント、コンテナベースのCIイメージで以下を検索します。
      • インストール履歴/キャッシュ/lockfileに「uuid32-utils」「colorinal」「termncolor」が存在しないか。
      • pip/pipenv/poetryのログとアーティファクトレジストリの取得記録。
  • ネットワーク監視
    • 開発セグメントとCIセグメントからのチャット系SaaS（Zulip等）へのRESTアクセスを暫定的に可視化・抑制します。許可リストは業務要件起点で最小化します。
  • EDR/ログのルール化
    • python/pip実行直後の以下挙動を検知します。
      • Linux: crontab編集、/etc/cron.*配下への書き込み、未知.soの配置と実行。
      • Windows: %AppData%やTemp配下へのDLLドロップ、reg addでのRunキー、schtasks作成。
    • 「開発者端末」タグ付き資産の高優先キュー化（検知後の調査SLAを短縮）を行います。

• 中期の構造対策（推奨）

  • 依存固定とハッシュ検証
    • requirements.txt（pip）での--require-hashes運用、pip-tools/poetryでのロック運用を標準化します。CIでは“ロック外の依存”を拒否します。
  • 私設レジストリの前段化
    • PyPI直引きは禁止し、社内レジストリ（Artifactory/Nexus/devpi等）からのみ取得。社外へのパッケージ公開権限は職務分離します。
  • ビルドのオフライン化
    • CIジョブはネットワーク遮断の「再現性ゾーン」で実行し、事前に検証済みキャッシュのみを使用します。ビルド中の外部HTTPアクセスは原則拒否します。
  • Egress制御の粒度向上
    • 開発/CI/実行環境ごとに、業務で必要なSaaS APIのみを許可。チャット/ストレージ/Pastebin系はゼロベースで見直します。
  • 教育とUX
    • タイポスクワッティング対策として、IDEのテンプレ生成やスニペットを「社内ベースラインの依存セット」に誘導。個人判断でのpip installをなくす開発体験（DX）づくりが効果的です。

• 検知コンテンツのヒント（汎用）

  • 同一ホストで「pip/pip3実行」→5分以内の「cron編集/DLL作成/レジストリRun追加」を相関。
  • pythonプロセスからの長時間HTTPポーリングやチャット系SaaSへの周期通信をフラグ。
  • CIランナーのネット新規宛先数・宛先SaaSカテゴリの逸脱検知（ベースライン比較）。

• インシデント対応の注意

  • SaaSをC2に使われた場合、通信遮断は業務に影響しやすいです。資産隔離と資格情報の強制ローテーション（特にクラウド長寿命トークン、PAT、レジストリ発行鍵）を優先し、ネットワークはセグメント毎の段階的遮断で副作用を抑えます。

参考情報

• The Hacker News（Kaspersky分析に基づく報道）: PyPI packages deliver ZiChatBot malware via Zulip REST API, Windows/Linux対応のドロッパーやダウンロード数の内訳を記載しています。https://thehackernews.com/2026/05/pypi-packages-deliver-zichatbot-malware.html

編集後記: 供給網の守りは、結局のところ「人のつまずき」と「仕組みの抜け道」をどう同時に塞ぐかの仕事です。今回の件は、その二つを最短距離で突く設計でした。手はあります。焦らずに、しかし素早く、経路をつぶし、依存を固定し、ビルドを閉じる——この三点を今日から積み上げていきます。次の一手が、明日の平常運転を支えると信じています。