Artificial Intelligence (AI)
AIゲートウェイがバックドアに：LiteLLMサプライチェーン侵害の内幕
サイバー犯罪グループTeamPCPは、これまでに公表された中でも特に高度で、複数のエコシステムにまたがるサプライチェーン攻撃を実行しました。この攻撃は開発者向けツール群に連鎖的に広がり、LiteLLMを侵害しました。その結果、AIプロキシサービスがAPIキーやクラウド認証情報を集約する特性ゆえに、上流の依存関係が侵害された場合、高い価値を持つ標的となることが明らかになりました。
- 広く利用されているAIプロキシパッケージであるLiteLLMがPyPI上で侵害され、2つのバージョンに悪意のあるコードが含まれていました。これらのLiteLLMは、認証情報の収集、Kubernetes環境での横展開、リモートコード実行のための永続的なバックドアという3段階のペイロードを展開します。クラウドプラットフォーム上の機密データ、SSHキー、Kubernetesクラスタの情報が標的とされ、外部送信前に暗号化されていました。
- LiteLLMのインシデントは、サイバー犯罪グループTeamPCPによるより広範な攻撃キャンペーンの一部です。同グループはPythonの実行モデルを深く理解しており、ステルス性と持続性を高めるために攻撃手法を迅速に適応させていました。
- TeamPCPはこれまでにも、TrivyやCheckmarx KICSといったセキュリティツールを侵害し、認証情報の窃取や悪意のあるペイロードの拡散を行ってきました。攻撃者は侵害されたCI/CDパイプラインやセキュリティスキャナを悪用し、権限を昇格させた上でトロイの木馬化されたパッケージを公開しています。
- 本件は現在も進行中の事案であり、TrendAI™はモニタリングと分析から新たな情報が得られ次第、随時アップデートを行います。
3月24日、LiteLLMを稼働させていた本番システムが次々と停止し始めました。エンジニアはプロセスの暴走、CPU使用率が100%に張り付く現象、メモリ不足（OOM）エラーによるコンテナ停止といった異常を確認しました。スタックトレースを追跡した結果、複数のLLMプロバイダーへの統合ゲートウェイとして機能し、1日あたり340万回ダウンロードされている人気のPythonパッケージLiteLLMが、PyPI上で侵害されていたことが判明しました。分析の結果、バージョン1.82.7および1.82.8に、クラウド認証情報、SSHキー、Kubernetesシークレットを窃取する悪意のあるコードが含まれていることが確認されました。
これらの悪意あるバージョンは、3段階のペイロードを展開していました。50種類以上の機密情報を対象とする認証情報収集機能、クラスタ全体の侵害を可能にするKubernetes横展開ツールキット、そして継続的なリモートコード実行を可能にする永続的バックドアです。
この侵害は単発の事象ではありませんでした。攻撃者として追跡されているTeamPCPによる連鎖的なサプライチェーン攻撃の一環であり、その最新の事例です。本稿では、オープンソースの脆弱性スキャナTrivyを起点とした攻撃の連鎖をたどりつつ、LiteLLMに仕込まれたペイロードの技術的分析を提示します。
TeamPCPは、これまでに公表された中でも特に高度な、複数エコシステムにまたがるサプライチェーン攻撃を組織的に実行しました。
このキャンペーンは、PyPI、npm、Docker Hub、GitHub Actions、OpenVSXといった複数のプラットフォームにまたがり、単一の作戦として展開されました。AIインフラそのものを直接の標的としたわけではありませんが、開発者ツールチェーンを経由する形でLiteLLMも影響を受けました。その結果、APIキーやクラウド認証情報を集約するAIプロキシサービスが、上流の依存関係の侵害によって高価値の二次的標的となり得ることが明らかになりました。
本ブログでは、悪意ある多段階ペイロードの技術的分析とAI環境への影響、TeamPCPのキャンペーンに関するタイムラインおよび運用面の分析、さらにセキュリティツール自体が攻撃ベクトルへと転用された経緯について詳しく解説します。また、TrendAI™ ResearchによるLiteLLM侵害の分析では、攻撃者の特定に関する課題、公開されている脅威インテリジェンスの不足点、そして実践的な防御戦略についても取り上げています。侵害の指標（IoC）やMITRE ATT&CKとの対応付けも提示していますが、本インシデントのより包括的な理解をご希望の場合は、TrendAI™ Researchによるこちらの記事もご参照ください。
セキュリティスキャナが攻撃ベクトルとなる仕組み
Trivyは、Aqua Securityによって開発されたオープンソースの脆弱性スキャナです。コンテナイメージ、ファイルシステム、Infrastructure as Codeを対象に脆弱性をスキャンし、trivy-actionというGitHub Actionsを通じて、数千のソフトウェアプロジェクトのCI/CDパイプラインに組み込まれています。
セキュリティスキャナは、サプライチェーン攻撃において特に危険な標的となります。その設計上、スキャン対象の環境に対して広範な読み取り権限を必要とし、環境変数、設定ファイル、ランナーのメモリなどへアクセスします。ひとたびスキャナが侵害されると、正当な権限を持ったまま機密情報を収集するプラットフォームへと変貌してしまいます。
2026年2月下旬、MegaGame10418というハンドルネームで活動する攻撃者が、TrivyのCIにおけるpull_request_targetワークフローの設定ミスを悪用し、aqua-botのパーソナルアクセストークンを外部へ流出させました（T1078 ― 有効なアカウントの悪用）。Aqua Securityは3月1日にこのインシデントを公表し、認証情報のローテーションを開始しました。しかし、同社の事後分析によれば、このローテーションは「原子的に実施されておらず、攻撃者が更新後のトークンにアクセスできた可能性がある」とされています。
このギャップが決定的な影響を与えました。3月19日17時43分（UTC）、TeamPCPは依然として有効だった認証情報を用いて、trivy-actionリポジトリにおける77件中76件のリリースタグ、およびsetup-trivyの全7タグを、悪意あるコミットへ強制的に上書きしました。これらのコミットには、多段階の認証情報窃取機能（T1195.002 ― ソフトウェアサプライチェーンの侵害）が含まれていました。この不正コードは、Runner.Workerプロセスのメモリから機密情報を抽出し、ファイルシステム上のクラウド認証情報やSSHキーを収集します。その後、AES-256-CBCとRSA-4096公開鍵を用いてデータを暗号化し、タイポスクワッティングされたドメイン（scan[.]aquasecurtiy[.]org、IPアドレス 45[.]148[.]10[.]212）へ送信しました。CrowdStrikeの分析によると、正規のTrivyスキャン自体はその後も実行され、通常どおりの出力を生成していたため、侵害を示す明確な兆候は残されていませんでした。
図1は、このペイロードを成立させた攻撃チェーンを示しています。このチェーンは、侵害されたセキュリティツールから始まっています。
これはいわば「メタ攻撃」です。本来、サプライチェーン攻撃を検知するために利用されるセキュリティスキャナが、逆にサプライチェーン侵害の入口となりました。GitHub Actions上でのTrivyの侵害により、攻撃者はPyPI上でLiteLLMの任意のバージョンを公開できる権限を手に入れました。その後に起きた一連の事象は、すべてこの初期侵入点の悪用に過ぎません。
ここから得られる教訓は、不快ではありますが極めて重要です。CI/CDにおけるセキュリティツールは、デプロイメントツールと同等のアクセス権を持っています。そのため、これらが侵害されれば、下流のすべての環境が露出することになります。
2つのバージョン、2つの侵入経路：13分間のピボット
この攻撃は、.pthファイルから始まったわけではありません。その13分前に、より単純な手法から開始されていました。この短時間での急速な改良は、攻撃者の高度な運用能力を示しています。
- バージョン1.82.7（10:39 UTC）：ペイロードはproxy_server.pyに直接埋め込まれ、LiteLLMプロキシの起動時に実行されます。より限定的な攻撃が可能である一方、コードレビューで発見されやすいという特徴があります。Endor Labsは、proxy_server.py内に3つの異なるペイロードの変種を確認しており、攻撃者がほぼリアルタイムでテストと改良を行っていたことが示唆されています。
- バージョン1.82.8（10:52 UTC、13分後）：.pthファイルの仕組みが追加され、Pythonインタープリタの起動時に実行されるようになりました。インポートの有無に関係なく動作するため、よりステルス性が高く、影響範囲も広がります。LiteLLMを明示的にインポートする必要はなく、単に「pip install LiteLLM==1.82.8」を実行するだけで、その後に起動するすべてのPythonプロセスでペイロードが有効化されます。
この13分間の変化は、関数レベルでのコード注入から、インタープリタ全体への永続化へと進化したことを示しています。これは、Pythonの実行モデルを深く理解し、運用上のプレッシャーの中で配布手法を適応させた攻撃者の存在を物語っています。図2は、この短時間での改良プロセスを示しています。
悪意あるペイロードの検出
LiteLLMは、AI／機械学習エコシステムにおいて最も広く採用されているオープンソースのLLMプロキシゲートウェイの一つです。アプリケーションコードとモデルプロバイダー（OpenAI、Anthropic、Azure AIなど多数）の間に位置し、LLM APIコールのルーティング、負荷分散、ログ記録を担います。日々、数万の開発者やCI/CDパイプラインがこれに依存しています。しかし、バージョン1.82.8には異常がありました。LiteLLM_init.pthという34,628バイトのファイルが含まれており、検出されることなく取得可能なあらゆる機密情報を攻撃者の管理するサーバへ送信していました。
この悪意あるペイロードの解析が始まったきっかけは、攻撃コードに含まれていたバグでした。無限にプロセスを生成するフォークボムが暴走を引き起こし、異常として顕在化したのです。このバグがなければ、認証情報窃取コードは数日から数週間にわたり静かに動作し続けていた可能性があります。攻撃者自身の実装ミスが、結果として攻撃チェーンにおける最も弱いリンクとなりました。
あるセキュリティリサーチャーは、BerriAIのLiteLLMリポジトリに対してGitHubのIssue#24512を投稿しました。その件名は「CRITICAL: LiteLLM 1.82.8 PyPIパッケージに含まれる悪意あるLiteLLM_init.pth、認証情報窃取」と、簡潔かつ決定的なものでした。AI研究者のAndrej Karpathyも、このサプライチェーン攻撃がシステムクラッシュを引き起こすバグによって迅速に発見されたと指摘しています。
AIリサーチ機関のFutureSearchによる分析によれば、攻撃者はlitellmプロジェクトのメンテナアカウントを乗っ取り、通常のGitHubリリース手順を回避して、侵害されたバージョンを直接PyPIへ公開しました。LiteLLMは開発者とほぼすべての主要LLMエンドポイントの間に位置するため、単純なスクリプトから高度なコーディングエージェントまで、多くのシステムで依存関係として取り込まれています。
最初のコミュニティ報告から約3時間以内に、PyPIはバージョン1.82.7および1.82.8を削除しました。オープンソースコミュニティはGitHub、Twitter/X、セキュリティベンダーのチャネルを通じて迅速に連携し、対応を進めました。BerriAIはインシデント対応のためにMandiantを招集しました。この迅速な防御対応により、認証情報の流出による実害は一定程度抑えられた可能性があります。ただし、本稿執筆時点では、窃取された認証情報が実際に悪用されたかどうかについて公的な確認はありません。
- 1.82.7（10:39 UTC）：proxy_server.pyに悪意あるコードが挿入され、LiteLLMプロキシモジュールのインポート時に実行されます。
- 1.82.8（10:52 UTC、13分後）：同様のproxy_server.pyへの注入を維持しつつ、.pthファイル（LiteLLM_init.pth）を追加。Pythonインタープリタの起動時に実行されるため、トリガー範囲が拡大し、冗長な実行経路が確保されます。
TrendAI™ Researchの分析により、侵害された両バージョン（1.82.7および1.82.8）は、それぞれ異なる目的で運用される2つの攻撃者管理ドメインを使用していることが確認されています。窃取された認証情報は、RSA-4096とAES-256を組み合わせたハイブリッド方式で暗号化され、HTTPS POSTによりmodels[.]litellm[.]cloudへ送信されます。このドメインは攻撃のわずか1日前に登録されていました。
さらに、別の永続的バックドアがcheckmarx[.]zoneへ50分ごとにアクセスし、第2段階のペイロードを取得します。この際、信頼性の高いCheckmarxのブランド名を悪用することで、DNSの許可リストを回避しています。バージョン1.82.7は、同一インフラを標的とした過去のサプライチェーン攻撃とコード上の共通点を持ち、1.82.8では同様のデュアルドメイン構成を維持しつつペイロードが洗練されています。
これらの悪意あるバージョンは、セキュリティツールによってではなく、偶然によって発見されました。FutureSearchのリサーチャーであるCallum McMahonは、CursorのMCPプラグインをテスト中に、依存関係として取り込まれたLiteLLMを通じて問題を発見しました。
PyPIは公開から約3時間後に両バージョンを隔離しました。同日中に、DSPy、MLflow、OpenHands、CrewAI、Arize Phoenixといった複数の下流プロジェクトが、影響を受けたバージョンを回避するためのセキュリティ対応PRを提出しています。
アーキテクチャとエンコード層
本マルウェアは、3層のbase64エンコードされたPythonスクリプトとして構成されています。各層は実行時にデコードされて順次実行されるため、ディスク上に単独のファイルとして保存されることなく、メモリ上でペイロードが連鎖的に展開されます。
- パッケージのインストール：LiteLLM_init.pthファイルが、正規のLiteLLMファイルとともにPythonのsite-packagesディレクトリに配置されます。
- 自動実行：その後、Pythonインタープリタが起動するたびに、この.pthファイルが実行され、オーケストレーター、認証情報収集機能、永続化機構を内包した3層のマトリョーシカ構造が展開されます。
- 環境判定：ペイロードはGITHUB_ACTIONS環境変数の有無を確認します。これが設定されている場合に動作を有効化し、特に機密情報が集中するCI/CDパイプライン環境を明確に標的としています。また、ロケールやレジストリに基づくジオフェンシングを行い、特定の地域を除外する挙動も確認されています。
- 認証情報の収集：ペイロードはシステム全体を走査し、SSHキー、AWS／GCP／AzureのIAM認証情報、Kubernetes設定、Dockerレジストリトークン、npm認証トークン、HashiCorp Vaultトークン、WireGuard秘密鍵、暗号資産ウォレット（Bitcoin、Ethereum、Solana、Exodus、Electrum）、シェル履歴、データベース認証情報、CI/CDのシークレットファイルを収集します。さらにAIエコシステムにおいて重要な、環境内に設定された各種LLMプロバイダーのAPIキーも標的となります。
- 暗号化された外部送信：収集されたすべてのデータは、ランダムに生成されたAES-256-CBCセッションキーで暗号化され、そのセッションキーはハードコードされたRSA-4096-OAEP公開鍵でラップされます（これにより復号できるのは攻撃者のみとなります）。その後、データはHTTPS POSTによりmodels.*LiteLLM.cloudへ送信されます。このドメインはトロイの木馬化されたリリースと同日に登録され、通常のLiteLLM API通信に紛れるよう設計されていました。
- 永続化：CI環境以外では、ペイロードはsystemdユーザサービス（*sysmon.service*）をインストールし、50分ごとにC&Cサーバへアクセスして第2段階のペイロードを取得します。これにより、再起動後も維持される永続的なバックドアが確立されます。
図3および後続のセクションでは、この実行フローについてさらに詳しく解説します。
初期ランチャー（Layer 0）
ファイル全体は、単一のPythonコード行で構成されています。実行されると、必要なモジュールをインポートし、直ちに子プロセスを生成して、base64でデコードされたLayer 1のペイロードを実行します。
オーケストレーター（Layer 1）
Layer 1では、RSA公開鍵が定義され、base64エンコードされたペイロードが埋め込まれ、run()エントリポイントが実装されています。窃取データのハイブリッド暗号化のために、4096ビットのRSA公開鍵がハードコードされています。オーケストレーターは一時ディレクトリを作成し、コレクタースクリプト（Layer 2）をサブプロセスとして実行し、窃取されたすべてのデータをファイルに収集します。
コレクターが処理を完了し、データを書き込んだ後、オーケストレーターはそれをRSAとAESを組み合わせたハイブリッド方式で暗号化します。まず、openssl randを使用してランダムな32バイトのAESセッションキーを生成します。次に、そのセッションキーを用いてAES-256-CBCとPBKDF2による鍵導出で収集データを暗号化します。その後、セッションキーを埋め込まれたRSA-4096公開鍵でOAEPパディングを用いて暗号化し、最終的にpayload.encとsession.key.encをまとめてtpcp.tar.gzとしてパッケージ化します。この暗号化バンドルは、攻撃者が管理するドメインへHTTP POSTで送信されます。
コレクター（Layer 2）
この認証情報収集機能は、50種類以上の機密データを対象としています（T1552 ― 保護されていない認証情報）。
- システム情報の収集：hostname、uname、whoami、ip addr、printenv、実行中プロセス、認証ログ
- SSHキー：/home/および/root/配下のすべてのユーザディレクトリに存在する各種秘密鍵形式
- クラウド認証情報：AWS認証ファイル、IMDS v1およびv2トークンの取得、さらにAWS Secrets Manager（ListSecrets、GetSecretValue）およびSSM Parameter Store（DescribeParameters）への認証済みSigV4 API呼び出し。スクリプトには完全なSigV4署名処理が組み込まれています（T1552.005 ― クラウドインスタンスメタデータAPI）
- GCPおよびAzure：application_default_credentials.jsonおよび~/.azure/ディレクトリ
- Kubernetes：サービスアカウントトークン、kubeconfigファイル、全ネームスペースにわたるシークレットのAPI列挙
- アプリケーション認証情報：Git、Docker、npm、Vault、MySQL、PostgreSQL、MongoDB、Redisの設定情報
- 暗号資産ウォレット：Bitcoin、Ethereum、Solana（特にバリデータインフラに注目）およびその他7種類の通貨
- CI/CDシークレット：Terraformのステートファイル、Jenkins設定、.gitlab-ci.yml、.travis.yml、Ansible設定
- その他：TLS/SSL秘密鍵、シェル履歴、/etc/shadowファイル
システム情報収集およびSSHキーと設定情報の窃取
コレクターはまず、ファイル読み取りおよびコマンド実行のための補助関数を定義し、その後すぐにシステム識別コマンドを実行します。emit()関数は任意のファイルを読み取り、その内容をマーカーヘッダー（=== /path ===）付きで標準出力に書き出します。run()関数はシェルコマンドを10秒のタイムアウト付きで実行し、その出力を取得します。
すべての出力はバイナリとして標準出力に書き込まれ、オーケストレーターがそれを一時ファイルとして収集します。スクリプトは/homeおよび/root配下のすべてのユーザホームディレクトリを列挙し、SSH秘密鍵、authorized_keys、設定ファイルをすべて読み取ります。さらに、システムレベルのSSH設定からホストキーも対象とします。
クラウドプロバイダーの認証情報窃取
スクリプトは、すべてのユーザのAWS認証ファイルを読み取り、AWS関連の環境変数を取得し、さらにEC2 Instance Metadata Service（IMDS）に対してIAMロール認証情報を取得するためのクエリを、v1およびv2の両方のトークン方式で実行します。
環境変数内にAWS認証情報が見つかった場合、スクリプトは認証済みのAWS SigV4 APIコールを実行し、AWS Secrets ManagerおよびSSM Parameter Storeから機密情報を窃取します。スクリプトには完全なSigV4署名処理が組み込まれています。その後、PUTリクエストによりIMDS v2のセッショントークンを取得し、続いて認証情報を取得します。これらの認証情報を用いて、Secrets ManagerのListSecretsおよびGetSecretValue、さらにSSMのDescribeParametersを呼び出します。
また、Google CloudおよびMicrosoft Azureに関する認証情報も、設定ファイル、キャッシュトークン、サービスアカウントキー、関連する環境変数を含めて、システム上からすべて窃取します。
Kubernetesシークレットの外部送信
スクリプトはKubernetesの設定ファイル（kubeconfig）を読み取り、kubectlコマンドを実行します。また、既知のマウントパスからKubernetesのサービスアカウントトークンを取得し、Kubernetes APIを利用して全ネームスペースにわたるシークレットを列挙します。APIベースの列挙では、グローバルおよび各ネームスペース単位でシークレットが取得されます。
Kubernetesクラスタ全体への横展開
これは最も破壊的な挙動です。スクリプトはすべてのKubernetesノードを列挙し、各ノードに対してkube-systemネームスペース内に特権付きPodを作成し、ホストのファイルシステムをマウントします。このPodはホスト上に永続化バックドア（後述）を書き込み、systemdサービスとして有効化します。Podの仕様は最大限の権限昇格を前提とした構成となっています。
アプリケーションおよびインフラ認証情報の窃取
コレクターは、さまざまなアプリケーション固有のファイルから認証情報を収集します。これにはGit、Docker、npm、Vault、FTP、SMTP、MySQL、PostgreSQL、MongoDB、Redisなどが含まれます。また、システムレベルの設定情報も対象とされます。
暗号資産ウォレットの窃取
スクリプトは、10種類の暗号資産にわたるウォレットファイルおよび設定情報を対象としており、特にSolanaのバリデータインフラに強くフォーカスしています。
環境ファイルおよびDevOpsシークレットの収集
スクリプトは、各種環境ファイルやDevOps関連のシークレットも収集対象としています。WireGuard VPN、Helm、Terraform、CI/CD設定、APIキーやWebhook URL、さらにTLS/SSL鍵などが含まれます。
ローカル永続化のインストール（Layer 2）および永続的バックドアのC&Cループ（Layer 3）
認証情報の収集およびKubernetes横展開用Podの展開後、スクリプトは現在のマシンにローカル永続化をインストールします。この永続化は~/.config/sysmon/配下に配置され、「System Telemetry Service」という名称のサービスとして登録されます。これは正規のLinuxシステム監視ツールに紛れることを目的としています。
PERSIST_B64ペイロードとしてインストールされるsysmon.pyは、ポーリング型のリモートコード実行バックドアを実装しています。初回起動時に300秒（5分）待機した後、3,000秒（約50分）ごとにhxxps[://]checkmarx[.]zone/rawへアクセスし、レスポンス内に「http 」で始まるURLが含まれていることを期待します。このURLが/tmp/.pg_stateに保存されているものと異なり、かつ「youtube.com」を含まない場合、内容を/tmp/pglogへダウンロードし、実行権限（chmod 755）を付与した上で、独立したプロセス（start_new_session=True）として実行します。その後、再ダウンロードを防ぐためにURLを/tmp/.pg_stateに記録します。
これはリモートコード実行（RCE）型バックドアに該当します。攻撃者はC&Cサーバ上のコンテンツを更新するだけで、侵害されたすべてのマシンに対して任意の実行ファイルを配布できます。systemdサービスの設定により、このバックドアはクラッシュ時（Restart=always）やシステム再起動後も継続して動作します。
「.pth」メカニズム：既知のリスクとして受け入れられている仕組み
Pythonの.pthファイル処理は、バグではなく仕様として文書化されている機能です。site-packagesに配置された.pthファイルは、Pythonインタープリタが起動するたびに自動的に処理されます。このリスクについては、CPythonのコア開発者の間でも、Issue #113659および#78125として議論されてきましたが、.pthの実行を制限すると正当な用途に支障をきたすため、「修正しない」という判断がなされています。
Issue#113659には対応が行われ、Python 3.8から3.13では隠し.pthファイルがスキップされるようになり、一部のリスクは軽減されました。一方で、.pthによるコード実行自体を非推奨または削除するというより広範な提案（Issue #78125）は、依然として結論に至っていません。これらの部分的な対策は、CPythonコミュニティが後方互換性とセキュリティのバランスを模索し続けていることを示しています。
この手法が悪用されたのは今回が初めてではありません。Volexityは、CVE-2024-3400の悪用事例において.pthの不正利用を観測しています。
また、npm経由の攻撃（checkmarx-util-1.0.4）も同様の手法を採用しており、偽のCheckmarxユーティリティパッケージを通じてDevSecOpsエンジニアを標的としていました。このパッケージは公開npmレジストリではなく、checkmarx.zoneという攻撃者管理のインフラから直接配布され、postinstallフックによって自動実行される仕組みになっていました。内部のタイムスタンプは1985年10月26日、映画『バック・トゥ・ザ・フューチャー』で知られる日付に設定されており、西洋文化を理解したオペレーターによる意図的なアンチフォレンジック的演出と考えられます。
単一のIPから複数エコシステムにまたがる攻撃へ
GitHubのIssueは、防御側にとっての出発点となりました。今回の分析は、単一のシードIOCであるIPアドレス83.142.209.11から始まり、50分間にわたる5段階の体系的なエンリッチメントを経て拡張され、34回のVirusTotal APIコールが実行されました。その結果、単一パッケージの侵害ではなく、複数のエコシステムにまたがる協調的なサプライチェーン攻撃であることが明らかとなり、私たちはこれをTeamPCPとして追跡しています。
3つのサプライチェーン経路、単一の攻撃者
3つの攻撃経路はいずれも、同一の暗号化方式（AES-256-CBCとRSA-4096-OAEPの組み合わせ）、同一の認証情報ターゲット、同一の永続化手法、そして同一のC&Cインフラに収束しており、単一の統合されたツールチェーンによる攻撃であることが確認されました。攻撃者はコード内に独自の痕跡も残しており、ペイロード中の「TeamPCP」という文字列、外部送信アーカイブ名「tpcp.tar.gz」、さらに「ICP y u no radio? ;w;」といった英語圏インターネット文化に由来するコメントが含まれていました。これらは後のアトリビューション分析において重要な手がかりとなります。
TrivyのCI/CDランナーから窃取された認証情報は、その後の侵害における鍵として利用され、攻撃の影響範囲は段階的に拡大していきました。
- npm（3月20日）：Trivy侵害から24時間以内に、TeamPCPはnpmエコシステム全体に自己増殖型ワームを展開しました。Aikido Securityの研究者により「CanisterWorm」と名付けられたこのワームは、侵害されたランナーからnpmトークンを窃取し、それらのトークンが公開権限を持つすべてのパッケージを列挙し、自動的に悪意あるバージョンを公開しました。@EmilGroupスコープ内の28パッケージが、60秒未満で感染しました。このワームは、Internet Computer Protocol（ICP）のカニスターをコマンド＆コントロールのデッドドロップとして利用しており、Aikidoによれば、ICPがC&Cに使用された初の事例とされています。ICPカニスターは、従来のドメインレジストラやホスティング事業者による停止措置が困難です。
- Checkmarx KICS（3月23日）：侵害されたCheckmarxの認証情報を用いて、TeamPCPはインフラストラクチャコード用セキュリティスキャナであるKICS GitHub Actionの全35タグ（v1からv2.1.20）を乗っ取りました。また、2つの悪意あるVS Code拡張機能もOpenVSXマーケットプレイスに公開されました。ペイロードは新たなC&Cドメイン（checkmarx[.]zone）を使用していましたが、Trivyのペイロードと同一のRSA-4096公開鍵およびtpcp.tar.gzという外部送信ファイル名が確認されており、共通のインフラを利用していることが裏付けられています。
- Docker Hub（3月22日）：侵害された認証情報を使用し、悪意あるDockerイメージ（aquasec/trivy:0.69.5および0.69.6）がDocker Hubに直接プッシュされました。これにより、GitHubのリリースプロセスを完全に迂回しています。これらのイメージは、mirror.gcr.ioなどのサードパーティミラーにも拡散しました。
- PyPI — LiteLLM（3月24日）：この連鎖は最終的にLiteLLMへと到達しました。LiteLLMのCI/CDパイプラインがビルドプロセスの一部として侵害されたTrivyを実行したことがきっかけです。悪意あるTrivyコードは、GitHub Actionsランナー環境からPYPI_PUBLISHトークンを窃取しました。LiteLLMのメンテナも、この侵害の起点が「自社のCI/CDで使用していたTrivyに由来する」と確認しています。
インフラ：48時間の攻撃のために90日を費やした準備
TeamPCPの背後にあるインフラは、最終的な攻撃の検出までのタイムラインとは対照的に、極めて計画的な運用準備が行われていたことを示しています。
両方のC&Cノードである83.142.209.11（checkmarx[.]zone）および46.151.182.203（LiteLLM[.]cloud）は、AS205759上でホストされており、Ghosty Networks LLC／DEMENIN B.V.の名義で運営される、いわゆるバレットプルーフホスティング事業者に属しています。この事業者はオランダとウクライナの管轄上のギャップを利用し、不正利用の通報対応を困難にしています。JARM TLSフィンガープリンティングにより、両ノードで同一のサーバ構成が確認されており、一般的なnginxとは一致せず、オープンソースのGo製C&CツールキットであるAdaptixC2と整合する特徴が見られました。
AdaptixC2の開発者「RalfHacker」はロシアの犯罪地下組織との関連が指摘されています。このフレームワークは、インフラの重複を根拠に、Akiraランサムウェアの関連アフィリエイトによっても利用された可能性がありますが、この帰属の確度については慎重な評価が必要です。
キルスイッチ：YouTube URLによる全体停止メカニズム
本キャンペーンにおける運用上の特徴の一つが、その停止機構です。両方のサプライチェーン経路は、50分ごとにC&Cサーバへアクセスする永続化デーモンをインストールしていました。このデーモンは第2段階のペイロードを実行する前に、レスポンスに「youtube」という文字列が含まれているかを確認し、含まれていた場合は処理を静かにスキップします。
分析時点では、/rawエンドポイントは43バイトのYouTube URLを返しており、キルスイッチは有効化されていました。これにより、永続化デーモンが稼働しているすべての侵害ホストが、個別のC&Cコマンドを必要とせず、一括で無効化されていました。「youtube」という文字列をトリガーに選んだのは実用的な判断であり、YouTubeのURLは自然にこの文字列を含むため、ネットワーク監視においても無害な通信に見える可能性があります。
攻撃者がキルスイッチを発動した理由が、進行中の解析を察知したためなのか、収集フェーズを完了したためなのか、あるいはフォレンジックリスクを低減するためなのかは不明です。ただし、この仕組みは運用の成熟度を示しており、単一のサーバ側変更でキャンペーン全体を停止できる能力を持っていることが分かります。なお、このような手法自体は他の犯罪的C&Cフレームワークでも確認されており、本キャンペーン特有のものではありません。
ボットによる抑制キャンペーン：情報戦と脆弱性開示の交差点
GitHubのIssueが投稿されてから数分以内に、異常な現象が発生しました。大量のコメントがスレッドに流入したのです。
コミュニティの分析によると、以下の事実が確認されています：
- 開示直後に121件の侵害されたGitHubアカウントが同時に活動を開始
- StepSecurityの調査では、196件以上のボットコメントがスレッドを埋め尽くし、その大半がTrivy侵害時と同様のパターンの汎用的な称賛スパムであった
このようにGitHubのIssueをノイズで埋める行為は、トリアージやコミュニティの対応を遅延させることを目的としていたと考えられます。これは注目すべき運用上のTTPであり、従来のサプライチェーン攻撃がステルス性に依存し、検出の遅れを期待していたのに対し、TeamPCPは積極的に情報開示そのものを妨害しました。
これが「脆弱性開示に対する情報戦」と呼べるものなのか、それとも単にサービスを提供するボットネット運用者による自動スパムなのかは、攻撃者の組織構造が不明なため断定できません。しかし明らかなのは、この抑制能力が事前に準備され、迅速に発動されたという点です。
サプライチェーン攻撃におけるアトリビューション（帰属特定）は本質的に困難です。ツールやインフラの共有、意図的な偽装などが一般的に見られるためです。TeamPCPは、Shellforce、PersyPCP、X上の@pcpcatsなど複数の別名で活動しており、広範かつ組織的なオンラインプレゼンスを維持しています。複数のTelegramチャネルや.onionサイトを通じて、自らの攻撃成果を公開し、被害者を掲載しています。これらのプラットフォームでは、侵害対象の詳細を提示するとともに、交渉のための連絡先を提供し、関心のある相手に対してTelegram経由でのオファーを促しています。
今回の調査では、3つの帰属候補に対してAnalysis of Competing Hypotheses（ACH）フレームワークを適用しました。2023年10月の@pcpcatsアカウントは、自身がイスラエル拠点であると主張しつつ、南アフリカのAndroidアプリを通じた接続を示唆しています。強い帰属シグナルは文化的側面にあります。
コード内の「ICP y u no radio? ;w;」というコメント、「バック・トゥ・ザ・フューチャー」の日付を用いたタイムスタンプ操作、ペイロード内で明示された「TeamPCP」というブランディング、さらに英語のみを対象とした攻撃プロファイルは、いずれも西洋文化およびインターネット文化に精通した個人または小規模チームの存在を示唆しています。国家主体の代理組織とは考えにくい特徴です。また、ツール開発の進展（2025年12月にバージョン1、2026年2月に強化されたバージョン2、そして3月に実戦投入）は、大規模な犯罪組織ではなく、セキュリティリサーチの背景を持つ小規模で意欲的な開発チームの特徴と一致します。
一方で、イランを標的としたワイパー機能（kamikaze[.]sh）の存在が、帰属分析を複雑にしています。これはロシア系犯罪者による反イラン的動機を示す可能性もあれば、意図的な偽装、あるいは複数主体による共同作戦の可能性も考えられます。総合的に見て、TeamPCPは西洋文化に精通した小規模な犯罪グループである可能性が中程度の確度で評価されます。
被害者の分布もこの評価を裏付けています。TeamPCPの.onionサイトおよびTelegramチャネルには、米国、中国、ブラジル、フィリピン、インド、トルコ、チリ、韓国、ベトナム、ウズベキスタンなどにおける被害が記録されています。米国では通信インフラ、自動車レンタル、求人プラットフォーム、ビジネス分析企業が対象となっています。中国ではSaaS、金融取引、ECドロップシッピング分野が含まれます。ブラジル、フィリピン、トルコではフィンテックや決済処理事業者が対象です。インド、韓国、ベトナムでは求人およびECプラットフォームが被害を受けています。チリやウズベキスタンでは、デジタル決済やロイヤルティサービス、ファンタジースポーツ基盤といった特異な分野も含まれています。
これらの対象は、認証情報が豊富な商用セクター、個人情報（PII）を保有する求人プラットフォーム、決済連携を持つフィンテック、マーチャントアカウントを扱うPODサービスなどに集中しており、認証情報の転売やアクセスブローカーを目的とした犯罪的収益モデルと一致します。
この被害選定は戦略的というより機会的なものです。国家情報機関にとって価値がある対象ではなく、脆弱な対象が優先的に侵害されています。この傾向は、文化的指標やツール開発のタイムラインと合わせて考えると、西洋文化に精通し、金銭的利益を目的とする小規模な犯罪グループであるという中程度の確度の評価を支持します。詳細なACH分析については、技術レポートをご参照ください。
- 第2のインフラノード：公開レポートでは、46.151.182.203やLiteLLM[.]cloud／models[.]LiteLLM[.]cloudといった外部送信インフラは特定されていませんでした。そのため、コミュニティのIoCフィードのみに依存していた組織は、PyPI経由の外部送信エンドポイントを見逃していた可能性があります。
- npm経路の存在：checkmarx-util-1.0.4.tgzの存在、その3層構造、さらにcheckmarx[.]zoneからの直接URL配布については、外部では報告されていませんでした。
- AdaptixC2の使用：シードIPが稼働中のAdaptixC2チームサーバに関連付けられている点は、公開情報では確認されていませんでした。このC&Cフレームワークの特定はハンティングにおいて重要であり、AdaptixC2特有のJARMフィンガープリントを用いることで、ネットワーク上の検知が可能になります。
- 約3.5か月にわたる開発期間：pcpcat.py v1（初観測は2025年12月）から、この攻撃者が数か月前からツール開発を進めていたことが分かります。しかし、公開レポートは主に2026年3月の侵害期間に焦点を当てており、この準備期間は言及されていませんでした。
- JARMによるインフラ相関分析：2つの異なる/24ネットワークにまたがるノードが単一のオペレーターによって管理されていることを示すJARM相関は、公開情報には含まれていませんでした。
- 体系的な帰属分析フレームワーク：公開されている帰属分析は、北朝鮮関与を強く示唆するものから不確実性を指摘するものまで幅がありましたが、文化的・運用的・技術的証拠を体系的に評価する「競合仮説分析（ACH）」を適用した事例は確認されませんでした。
総じて、本分析の約30%にあたる知見は、公開情報ではまったくカバーされていませんでした。コミュニティによる迅速な対応は、初動の緩和策として非常に有益でしたが、キャンペーン全体の運用的な理解には、より深いインフラ分析、エコシステム横断的な相関分析、そして体系的な分析手法が不可欠であり、これらは迅速対応型のレポートでは十分に提供されていませんでした。
結論
LiteLLMの侵害は、AIインフラが次に狙われるサプライチェーン攻撃の主要ターゲットとなり得る理由を示す典型的な事例です。プロンプトインジェクション、データポイズニング、モデル反転といった高度なAI固有の脆弱性に注目が集まりがちですが、実際の攻撃者は、この10年間私たちが対処してきたのと同じインフラ上の弱点を突いています。
AIの技術スタックは、標準的で脆弱なオープンソース基盤の上に構築されています。攻撃者は常に最も重要で脆弱な部分を狙います。複雑なLLMの脱獄を試みる必要はありません。汚染されたPythonの依存関係があれば、Kubernetesクラスタを容易に掌握できてしまいます。私たちはAIをまったく新しい領域として捉えがちですが、攻撃者は従来と同じサプライチェーン攻撃の手法を用いて侵入しているに過ぎません。
本インシデントは、公開リポジトリからの無管理なアップデートのリスクと、拙速なパッチ適用における慎重さや監視の欠如が新たな脆弱性を生む可能性を浮き彫りにしています。最新リリースを隔離期間なしで自動取得するCI/CDパイプラインは、自ら脆弱性を生み出していると言えます。依存関係は暗号学的ハッシュで固定し、新しいリリースについては他の環境でサプライチェーンマルウェアの検証が行われるのを待つべきです。
集約リスクの問題
LiteLLMはAI／MLスタックにおいて特権的な位置を占めており、プロキシするすべてのモデルプロバイダーのAPIキーを取り扱います。プロキシ型のデプロイメント（LiteLLMが中央ゲートウェイとして動作する構成）では、これが侵害されると、通常のクラウド認証情報に加えて、OpenAI、Anthropic、Azure AIなど複数プロバイダーのLLM APIキーが一度に流出します。これは「リスクの集中」という典型的なパターンです。1つのパッケージに、すべての鍵が集約されています。
なお、SDKやライブラリとして利用する場合は、リクエストごとに認証情報を扱い、キーを集中管理しないため、リスクプロファイルは異なります。一方で、本番環境における主な利用形態であるプロキシ型デプロイメントは、より大きな影響範囲を持ちます。
窃取されたLLM APIキーにより、攻撃者は以下のような行為が可能になります：
- 自身の目的のために無償で計算資源を利用する（主要プロバイダーのAPIキーは月数千ドル規模のコストに相当する場合があります）
- 一部プロバイダーにおいて会話履歴へアクセスする
- 顧客向けAIプロダクトにおいて応答内容を改ざんする
- 被害組織に対して金銭的損害を与える
AIインフラが特に攻撃にさらされやすい理由
推移的依存関係の深さ：AI／機械学習プロジェクトは、非常に深い依存関係ツリーを持つ傾向があります。DSPy、MLflow、CrewAI、OpenHandsなど、多くのフレームワークがLiteLLMを推移的依存関係として取り込んでいます。Wizの報告によれば、分析対象となったクラウド環境の36%にLiteLLMが存在しており、広範に利用されていることが示されています。ただし、存在していること自体が必ずしも脆弱性を意味するわけではありません。
急速なエコシステム拡大とセキュリティ成熟度の乖離：多くのAI／機械学習パッケージは、小規模なチームや個人開発者によって維持されています。AI機能の迅速な提供への圧力が、十分に監査されていないパッケージの採用を後押ししています。OWASPのLLM Top 10でも、LLM03（サプライチェーンの脆弱性）が主要なリスクとして挙げられています。
セキュリティツール自体が攻撃面となる問題：TrivyからLiteLLMへの攻撃連鎖は、防御のために使用されるツール自体が侵入経路になり得ることを示しました。これは、SolarWinds supply chain attackと同様の教訓であり、オープンソースエコシステムにも当てはまります。
実際に確認された影響と理論上可能だった影響の違い
ペイロードが持っていた能力と、実際に確認された影響とを区別することが重要です。
この区別は重要です。ペイロード自体は高度であり、リスクも重大でしたが、責任ある報告を行うためには、実際に確認された悪用と理論上の最悪シナリオを明確に分けて考える必要があります。
このパターンは繰り返される
TeamPCPが、AI開発者向けのLiteLLM、AppSecエンジニア向けのCheckmarx／KICS、コンテナセキュリティチーム向けのTrivyを相次いで侵害した事実は、本番インフラへのアクセス権を多く持つ主体を標的とした場合に、どれほど大きな影響が生じ得るかを示しています。より大きな視点で見れば、AIインフラの侵害は、より深刻な被害を引き起こすための副次的な手段に過ぎない可能性もあり、その意味でも極めて警戒すべき状況です。
AI／機械学習ツールが企業のCI/CDパイプラインに広く普及するにつれ、攻撃対象領域も拡大しています。開発者がAIシステムと連携するために導入するツール、プロキシゲートウェイ、モデルルーター、実験トラッカー、推論サーバなどは、その設計上、高価値な機密情報を取り扱います。これらのツールに対するサプライチェーン攻撃は、そのままAIインフラが持つ信頼とアクセス権を引き継ぐことになります。
本レポートで分析した悪意あるペイロードは、Trend MicroのTrendAI™ Researchによる過去の公開記事で詳細に指摘されている、シークレット管理の構造的な問題を直接的に悪用したものです。これまでに述べられているように、開発者は.envファイルを過剰に利用するあまり、その機密性への認識が薄れ、無防備な状態で放置してしまうケースが増えています。そして攻撃者は、まさにこれらのファイルを積極的に探索しています。本稿で分析したハーベスターは、この攻撃対象領域を大規模に実用化したものです。最大6階層にわたるディレクトリ探索を行い、.env、.env.local、.env.production、.env.stagingといったファイルを網羅的に収集します。同時に、AWS認証情報、クラウドプロバイダートークン、Kubernetesサービスアカウントのシークレット、CI/CDパイプライン設定、データベース接続文字列なども抽出します。これらはすべて、TrendAI™ Researchが以前から、.envファイル内に平文で保存されがちな代表的な機密情報として指摘してきた項目に一致しています。
セキュリティ対策
本事例は、脆弱な信頼の上にエコシステム全体を構築することのリスクを浮き彫りにしています。LiteLLMの侵害は、オープンソースレジストリへの依存や不十分なシークレット管理を悪用する攻撃の最新例に過ぎません。セキュリティは、脆弱性スキャナに完全に委ねられる後付けのものではありません。スタック内にLiteLLMが存在する場合、ベンダーからの重大アラートを待つべきではありません。攻撃者はすでに必要な情報を取得している可能性があるため、既知の侵害指標（IoC）に基づき、以下の即時対応を実施し、先手を打つことが重要です。
即時対応
- Pythonのsite-packagesディレクトリ内にLiteLLM_init.pthが存在するか確認してください。存在する場合は、すべての認証情報が侵害された前提で対応してください。
- LiteLLM 1.82.7または1.82.8がインストールされていたシステム（CI/CDランナーを含む）では、環境変数や設定ファイルに含まれていたすべての認証情報をローテーションしてください。LLM APIキーも含め、すべて侵害済みとして扱う必要があります。
- 以下のドメインおよびIPアドレスをDNSおよびファイアウォールでブロックしてください：checkmarx[.]zone、LiteLLM[.]cloud、models.LiteLLM.cloud、83.142.209.11、46.151.182.203。
- npmパッケージ内にcheckmarx-utilへの参照や、GITHUB_ACTIONSを読み取るpostinstallフックが存在しないか監査してください。
- Linux環境でsysmon.serviceというsystemdユーザユニットおよび~/.config/sysmon/ディレクトリを確認してください。
- CI/CDパイプライン内のTrivyおよびすべてのセキュリティスキャナをバージョン固定してください。セキュリティツールが侵害されると、下流のすべてが影響を受けます。
構造的対策
- CI/CDパイプラインでは、postinstallスクリプトを明示的にレビューしない限り、npm install --ignore-scriptsを適用してください。
- Pythonのsite-packagesにおける予期しない.pthファイルの生成を監視してください。既知の正常状態以外での.pth書き込みは重大アラートとして扱うべきです。Elasticはこの検知ルールを公開しています。
- パッケージバージョンを固定し、SHA256ハッシュを検証してください。pip install --require-hashesまたはuv pip install --require-hashesの利用を推奨します。すべての本番デプロイメントに対してSBOM（ソフトウェア部品表）を生成・適用してください。
- 十分に検証された安定バージョンを利用してください。未検証の最新バージョンへの即時更新は、本事例のような侵害リスクを高めます。
- シグネチャベースのアンチウイルスに依存するのではなく、複数の認証情報ファイル（SSHキー、クラウド設定、暗号資産ウォレットなど）を一括で読み取る挙動を検知する振る舞いベースの検知を導入してください。
- バレットプルーフホスティングのASNに対するTLS通信について、JARMフィンガープリント監視を実装してください。
- 推移的依存関係を監査してください。LiteLLMを直接利用していなくても、DSPyやCrewAIなどを通じて取り込まれている可能性があります。pipdeptreeやuv pip treeを活用してください。
- 外向き通信（egress）のフィルタリングを実装してください。本件ではmodels.LiteLLM.cloudへの通信が行われており、AIインフラに対するドメイン許可リストがあれば検知可能でした。
- LLM APIキーを最重要資産として扱ってください。依存関係内のパッケージに侵害が確認された場合は即時ローテーションを実施し、可能であればプロバイダー固有の短期間トークンを使用してください。
- フォークボムやリソース枯渇といった異常挙動にも注意してください。本件のLiteLLM攻撃は、これらの兆候によって最初に発見されました。
TrendAI Vision Oneは、サイバーリスク露出管理、セキュリティオペレーション、そして多層的な保護を一元化する業界最先端のAIサイバーセキュリティプラットフォームです。
TrendAI Vision One™ Threat Intelligence Hub
TrendAI Vision One Threat Intelligence Hubは、新たに出現する脅威や攻撃者に関する最新の知見、TrendAI™ Researchによる独自の戦略レポート、そしてTrendAI Vision One™プラットフォーム内で利用可能なThreat Intelligence Feedを提供します。
LiteLLM GitHub Actionsに関する主な情報：
- Emerging Threats：Critical Supply Chain Attack: Malicious LiteLLM_init.pth in LiteLLM PyPI Package（v1.82.8）— Credential Stealer
- TrendAI Vision One™ Intelligence Reports（IOCスイーピング）：Critical Supply Chain Attack: Malicious LiteLLM_init.pth in LiteLLM PyPI Package（v1.82.8）— Credential Stealer
TeamPCPによるGitHub Actions侵害全体に関する情報：
- Emerging Threats：Global CI/CD Supply Chain Attack: TeamPCP Compromises GitHub Actions and Open Source Security Tools for Credential Theft
- TrendAI Vision One™ Intelligence Reports（IOCスイーピング）：Global CI/CD Supply Chain Attack: TeamPCP Compromises GitHub Actions and Open Source Security Tools for Credential Theft
CI/CDパイプラインをゼロデイ攻撃がすり抜けた場合、静的スキャナだけでは対応できません。そのため、実行時に挙動を監視するセーフティネットが不可欠です。クラウド上の露出状況とリスクスコアを可視化することで、情報漏えいが発生する前に対応することが可能になります。
TrendAI Vision One Code SecurityおよびTrendAI Vision One Container Securityは、ビルド段階でコンテナイメージをスキャンし、侵害されたライブラリを検出することで、悪意あるペイロードが実行される前に阻止します。さらに、コンテナ内の一見無害なPythonスクリプトが突如としてAzureの認証情報を取得し、Kubernetesのサービスアカウントトークンを読み取り、バックグラウンドデーモンをインストールしようとした場合、XDRエージェントがその異常な挙動を検知し、攻撃者によるデータ外部送信が行われる前にプロセスを停止します。
侵入の痕跡（IoC：Indicators of Compromise）
本キャンペーンにおける最重要のIoCは、こちらのリンクから確認できます。完全な技術レポートでは、合計19項目のIoCを含む詳細な一覧が提供されています。
参考記事
Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise
By: Peter Girnus, Fernando Tucci, Deep Patel, Simon Dulude, Ashish Verma, John Rainier Navato
本分析は、サプライチェーン脅威に関する継続的な調査の一環として、ZDI Threat Huntingチームによって実施されました。
翻訳：与那城 務（Platform Marketing, Trend Micro™ Research）