2026年9月1日更新：8月に発表された3件の研究報告により、以下で説明する認証情報アーカイブに関する具体的な名称と数値が明らかになりました。そのうち1件は、本記事の一部を訂正する内容となっています。
CloudSEKは2026年8月11日、再構築された被害者データセットを公開しました。これには2,500以上の組織と、約434,000件の漏洩の可能性があるCI/CDパイプラインが含まれており、レポートには組織レベルの照合結果が記載されています。ここではそれらの名称については繰り返しません。 再構築された情報漏洩の一致は、侵害が確認されたことを意味するものではなく、その区別は企業名のリストとして提示される過程で失われてしまいます。Hudson Rockは8月12日、433,909ファイルからなる153 GBのアーカイブを入手・分析したことを公表し、118,829件のCIランナーのダンプを2,488の企業ドメインに帰属させました。
CloudSEKは、その数値が再構築された情報漏洩状況を表すものであり、侵害の証拠ではないことを明確にしています。一方、Hudson Rockの投稿には、これと同等の注意書きは記載されていません。両社ともドメイン検索を実施しており（CloudSEKはこちら）、いずれの企業もアーカイブ自体を公開していません。 また、CloudSEKの434,000件のパイプラインと、後述するFBI FLASHの数値（10,000件以上のパイプラインから得られた500,000件以上の認証情報）は、それぞれ異なる対象を計上している点にも留意が必要である。いずれの数値も、他方を上回るものではない。
範囲に関する訂正：本記事では、このキャンペーンをLiteLLMを中心に取り上げていました。SOCRadarが8月13日に2,188件の組織レコードのタイムスタンプを分析したところ、最も早いものは3月19日18:05（UTC）、最も遅いものは3月24日20:09（UTC）であることが判明しました。 そのうち2,085件（95％）の記録では、3月24日に悪意のあるLiteLLMパッケージがPyPIに公開される前に、収集活動が行われていたことが確認されています。 SOCRadarは、このタイミングから、LiteLLMのインストール期間ではなく、上流のTrivyが侵害されたことを示唆していると解釈しており、SecurityWeekも8月14日に同様の見解を示した。ログを検索する場合は、3月24日の40分間だけでなく、2月27日から3月下旬までの期間を対象にすべきである。この期間も、改ざんされたLiteLLMリリースをインストールしていた場合には重要だが、SOCRadarの分析によれば、感染の割合としてはごく一部に過ぎない。
バージョンに関する訂正： 2つの悪意のあるLiteLLMのリリースが公開され、 1.82.7 および 1.82.8、1つではなく。1.82.7では、ペイロードは litellm/proxy/proxy_server.py また、そのモジュールのインポートが必要でした。1.82.8 ではそのペイロードが維持され、さらに litellm_init.pth、これはPythonインタプリタの起動時に実行され、インポートは不要です。以下の「今すぐ確認すべきこと」のセクションは、これら両方を網羅するように更新されました。
CVEに関する訂正： この投稿によると、TeamPCPはCVE-2026-33634を悪用して、Trivyのワークフローのバージョンを上書きしたとのことです。Trivyは、最初の認証情報の盗難の原因を、この脆弱性のある pull_request_target 2月27日にワークフローの悪用が発生しましたが、CVE-2026-33634に関するNVDの記録には、3月1日のローテーションで侵入が阻止されなかった理由が説明されており、侵入がどのように始まったかについては触れられていません。
捜査・摘発について：オーストラリア連邦警察（AFP）は、AFP、FBI、西オーストラリア州警察による合同捜査の結果、2026年8月27日、西オーストラリア州の男性2名を起訴した。これらの容疑はあくまで告発であり、法廷での審理を経ていない。いずれにせよ、アーカイブ内の認証情報には影響はない。
8月のデータから資格情報のローテーションについて読み解いた新しい記事が公開されました：「認証情報はローテーションされたが、まだ使えた」
--
（本ブログ記事は自動翻訳です）
2026年4月28日、Check Point ResearchはVECT2.0の暗号化に関する技術分析（CPR-2026-0428）を公開しました。その調査結果は明快です。VECTの暗号化は特定の方法で破られているということです。 128 KBを超えるファイルの場合、各ファイルチャンクに対して一意の暗号化キーを生成すべきプロセスが、代わりに単一の値を再利用しており、その最終的な値のみが保存される。その結果、大容量ファイルの最初の4分の3は永久に乱され、被害者による復元は不可能となる。VECT側でも復元は不可能である。
身代金を支払っても、大容量のファイルは復元されません。復号鍵は本物です。データの損失は、その鍵が関係してくる前にすでに発生しています。
その発見は、それ自体として重要な意味を持ちます。また、それは、これまでかなり注目されてこなかった、より構造的な問題の帰結でもあります。
ターゲットの選定方法
ほとんどのランサムウェア攻撃は、同じ標的選定の手順を踏んでいます。攻撃グループは組織を特定し、アクセス権を構築または購入した後、攻撃を実行します。標的の選定は、アクセス権が確立される前に行われます。特定のランサムウェアグループによる攻撃のリスクは、そのグループが貴社のような組織を標的にすることを決定したかどうかに左右されます。
VECTはこのような仕組みではありません。そのサプライチェーンパートナーであるTeamPCPも同様です。
2026年7月2日に公開されたFBIのIC3 FLASH-20260702-01は、特定の標的を絞るのではなく、規模の拡大を重視した攻撃キャンペーンについて記録している。2026年2月から3月にかけて、TeamPCPは、組織が開発やセキュリティスキャンに依存している、広く利用されている4つのオープンソースソフトウェアパッケージを改ざんした：
- コンテナのセキュリティ脆弱性をスキャンするためのツール「Trivy」について：TeamPCPは、コードリポジトリへの書き込み権限を持つ開発者の認証情報を盗み出し、その脆弱性（CVE-2026-33634）を悪用して、Trivyの自動ワークフローの77バージョンのうち76バージョンに悪意のあるコピーを上書きした。
- Checkmarx KICS、 インフラストラクチャのコードをスキャンして設定ミスを検出するツール：TeamPCPも同様に35のバージョンを上書きした。また、各被害組織独自の自動化用認証情報を利用して、
docs-tpcp被害者のGitHubアカウント内。 - LiteLLM v1.82.8、月間ダウンロード数が約9,500万回に上るソフトウェアライブラリ：TeamPCPは、
litellm_init.pthインストール先へ。以下の拡張子を持つファイルは.pthこの拡張機能は、実際にどのソフトウェアを実行しているかに関係なく、Pythonが起動するたびに自動的に読み込まれ、実行されます。これにより、TeamPCPは そのパッケージがインストールされていた任意のマシン上で、コードが継続的に実行される. - Telnyx Python SDK バージョン 4.87.1 および 4.87.2：3段階のリモートアクセストロイの木馬。これは、攻撃者が感染したマシンを密かに制御できるようにするソフトウェアを指す。
TeamPCPは、Shai-Huludworm背後にいるグループと同じであり、このワームは侵害されたパッケージを利用して、開発環境やCI/CDパイプラインを通じて自動的に拡散する。 2026年2月から3月にかけてTrivyおよびLiteLLMを標的としたキャンペーンでも、信頼されたパッケージ、自動実行、認証情報の収集という同じ基本メカニズムが使用されました。『Shai-Hulud Part 2』では、2026年5月のTanStackキャンペーンについて取り上げており、このキャンペーンworm さらにworm 、パッケージの検証チェックを通過するために有効な暗号署名証明書を生成していました。
その結果、ソフトウェアの構築、テスト、デプロイを行う自動化システムである1万以上のCI/CD（継続的インテグレーションおよびデプロイ）パイプラインから、50万件以上の認証情報が盗み出されました。AWS、Azure、GCPのトークン。Kubernetesのシークレット。コンテナレジストリの認証情報。GitHubおよびGitLabのアクセストークン。
TeamPCPは標的を選定したのではなく、パッケージを選定した。2026年3月までに、認証情報アーカイブが作成されていた。VECTはそのアーカイブを精査し、リストの中からランサムウェアの被害者を選定した。
ターゲットの選択は、アクセス後に行われ、その前ではなかった。
「我々は力を合わせ、これらの攻撃の被害を受けたすべての企業に対してランサムウェアを展開する準備ができており、それだけに留まるつもりはない。」
「我々は、こうした妥協を連鎖させ、壊滅的な影響をもたらす一連のランサムウェア攻撃を展開していく。」
ランサムウェアへの曝露に関して、この変更がもたらす影響
従来のランサムウェア対策の計画策定では、「攻撃者が当社の環境に侵入するには、どのような行動を取る必要があるか」という問いが投げかけられます。この問いは、攻撃者がまだ具体的な手段を決めていないことを前提としています。TeamPCPモデルによれば、その問いに対する答えは、数ヶ月前に、チームがすでに忘れてしまった開発パイプラインにおける日常的なパッケージのインストールによって、すでに導き出されていた可能性があるのです。
ソフォスのカウンター・スレット・ユニット（CTU）は、TeamPCPから流出した認証情報を使用したVECTの展開が少なくとも1件確認されたと発表しました。FBIは、盗まれた認証情報が「最初の侵害からかなり経った後も悪用されることになる」と警告しています。VECTによる攻撃のリスクは、同グループが貴社の業界を標的としているかどうかによって決まるわけではありません。そのアーカイブに貴社のクラウドトークンが含まれているかどうかによって決まるのです。
ログに表示されない理由
これがギャップ3です：動きが見えない。
について litellm_init.pth パーシステンスファイルは、対象となる環境においてPythonが起動するたびに自動的に実行されます。ソフトウェアパッケージマネージャーはインストールを記録します。CI/CDパイプラインは、既知のサービスアカウントに帰属するワークフローの実行を記録します。クラウドプロバイダーは、認識されたIDからの認証済みAPI呼び出しを記録します。 3件の監査ログ、3件のセキュリティオペレーションセンター（SOC）チケット、1件の情報漏洩。
侵害されたパッケージから本番クラウド環境に至る経路を示す単一のログは存在しません。その経緯を突き止めるには、インストール日時、ワークフローの実行、およびアウトバウンドAPI呼び出しを、影響を受けたパッケージバージョンのリストと照合する必要があります。しかし、ほとんどの組織はこのようなリストを管理しておらず、ほとんどのセキュリティ監視システムも自動的に照合を行っていません。2026年4月に発生したAnodot/Snowflakeのサプライチェーンインシデントでも、同様のログの断片化という問題が見られました。この事件では、SaaS統合プロバイダーから盗まれたトークンが複数の顧客環境で再利用され、各システムは自身の担当範囲内のアクティビティのみを検証していたものの、それらを結びつけるものは何もありませんでした。VECT/TeamPCPの事例では、SaaS統合層ではなくCI/CD層を通じて、同様のパターンが繰り返されています。
Checkmarx KICSベクターは、さらに別の層を追加します。TeamPCPは、被害者自身の自動化用認証情報を使用して、 docs-tpcp 被害者のGitHub組織内。リポジトリ作成イベントは、被害者のサービスアカウントに帰属するものとして、GitHubの監査ログに記録される。 一見、何もおかしいところはないように見えた。これがギャップ1だ。
業務内部における能力のギャップ
チェック・ポイントがVECT 2.0のコードを分析したところ、素人による開発の明らかな兆候が見られた。具体的には、記述されているものの実際には実行されないセキュリティ回避コード、自らを無効にしてしまう難読化レイヤー、柔軟に見えるが実際にはハードコードされている設定フラグ、そしてプログラム内に含まれる不完全な装飾テキストなどである。VECTが被害者のファイルを永久に破壊してしまう原因となる暗号化の欠陥も、同様のパターンに当てはまる。malware 素人のmalware 。
しかし、それを支えるインフラはそうではありません。VECTのアフィリエイトプログラムには、モネロ（プライバシー重視の暗号資産）のエスクロー口座、BreachForumsとの連携、段階的な手数料体系、そして身代金交渉を担当する専任の交渉担当者が含まれています。 2026年4月16日に正式に導入されたBreachForumsの「大規模アフィリエイト」モデルにより、オペレーターは独自のインフラを構築することなく、このインフラを利用できるようになります。TeamPCPの認証情報アーカイブは、技術的な攻撃スキルの代わりとなります。つまり、標的の防御システムに脆弱性がなくても、そのクラウドトークンをすでに保有していれば攻撃が可能になるのです。
これは防衛計画において重要な点です。正常に動作しているエンドポイントセキュリティソフトウェアであれば、malware検知します。ソフトウェアのサプライチェーンや自動化されたパイプラインを経由して配信されても、検知機能は作動しません。検知機能が機能していないわけではありません。不完全なだけなのです。
今確認すべきこと
2026年4月以前に、お使いの環境でこれらのパッケージのいずれかが実行されていた場合は、その事実が確認できるまで、パイプラインのクラウド認証情報を漏洩したとみなしてください：
- LiteLLM、具体的にはv1.82.8。また、以下も検索してください。
litellm_init.pth2026年2月および3月にLiteLLMを実行したすべてのマシンのPythonインストールディレクトリ内。 - Trivy GitHub Action。その期間中に 0.76.x または 0.77.x のタグに固定されたすべてのバージョン。
- Checkmarx KICS GitHub Action、影響を受ける 35 のタグのいずれか。
- Telnyx Python SDK 4.87.1 または 4.87.2。
GitHub 組織のリポジトリ一覧から、以下を検索してください docs-tpcp. これが存在するということは、TeamPCPがユーザーの自動化用認証情報を使用してこれを作成したことを意味します。影響を受ける環境において、2026年4月以前に発行されたクラウド認証情報（AWS、Azure、GCPのサービスアカウント、コンテナレジストリトークン、GitHubおよびGitLabのアクセストークン）を更新してください。2026年2月から4月にかけて、パイプラインのサービスアカウントから本番環境へのAPI呼び出しについて、AWS CloudTrail、Azure Monitor、およびGCP Cloud Audit Logsを確認してください。特に、既知のデプロイより前の日付の呼び出しに注意してください。
『Mind Your Attack Gaps』の「ギャップ3」の章 『Mind Your Attack Gaps』 の「ギャップ3」の章では、ハイブリッドクラウドにおける侵害事例が取り上げられており、そこでは別の攻撃チェーンにおいても同様のログの断片化という問題が横断的に発生しています。Vectra AIでは、3つの別々の監査システム間の相関関係に依存することなく、ID、クラウド、SaaSを横断する環境間の移動をモデル化しています。TeamPCP/VECTキャンペーンは、単一環境の可視化だけではこの種の攻撃をカバーできない理由を如実に示す好例です。
認証情報のアーカイブは存在します。2026年4月以前にパイプラインで影響を受けるパッケージを実行していた場合、今問うべきは「標的になる可能性があるか」ではなく、「トークンがすでにそこに記録されているか」ということです。