TeamPCPの認証情報アーカイブに名前が含まれていたある組織は、Kevin Beaumontに対し、すでに対応済みであり、すべての認証情報をローテーションしたと説明しました。そこで同氏は、その組織の責任ある開示ポリシーを確認し、認証情報のテストが許可されていることを確かめたうえで、実際に試してみました。
これは1つの投稿、1つの組織に関するものであり、Beaumontはその組織名を明かしていません。これを単一のデータポイントとして扱うべきでしょう。しかし、これは「是正対応のチケットがクローズされた時点」と「認証情報が無効化された時点」との間の時間的隔たりを示すデータポイントであり、連鎖の最初の被害者に関する2つ目のデータポイントも存在します。
8月の情報開示で明らかになったこと
7月、私はTeamPCPの認証情報アーカイブについて記事を書きましたが、その際、VECTランサムウェアの連携による被害を受けるかどうかは、自分のクラウドトークンがそのアーカイブに含まれているかどうかにかかっていると論じました。8月、そのアーカイブには具体的な規模と被害者リストが明らかになりました。
- CloudSEK、8月11日：2,500を超える組織と、約434,000のCI/CDパイプライン。
- ハドソン・ロック、8月12日：433,909個のファイルからなる153 GBのアーカイブを入手・分析した結果、2,488の企業ドメインに帰属する118,829件のCIランナー・ダンプが確認された。
見出しを読む前に、CloudSEKによる注記を確認してください。同社の提示する数値は「再構築された（潜在的な）侵害リスク」を示すものであり、「リストに掲載されたすべての組織が実際に侵害された、あるいはすべての認証情報が盗まれたことの証拠として解釈すべきではない」とされています。つまり、データセットに掲載されていることは調査のきっかけにはなりますが、侵害が確定したことを意味するわけではありません。一方、Hudson Rockの投稿にはこうした留保条件が示されていません。両社のリストを比較する際には、この点を知っておく必要があります。
両社とも、照合された組織名を公表しています。ここではそれらの名称を繰り返しません。再構築された情報漏洩の照合結果は、侵害が確認されたことを意味するものではなく、その区別は、単に企業名のリストとして提示されただけでは失われてしまいます。
両社ともそのアーカイブを公開してはいません。Hudson Rockはそれを自社の「Cavalier」プラットフォームに統合し、被害者ごとに情報を開示するプロセスを運用しています。一方、CloudSEKはパブリックドメインの検索機能を提供しています。このデータ群がさらに広く出回っているかどうかは不明であり、この件に最も近い立場にある人々の間でも意見が分かれています。
- Hudson Rock社のアAlon Gal氏は『Help Net Security』に対し、「現時点ではどこにも流出しておらず、広く出回ってもいない」と語った。
- Beaumont氏はその週、「現在、テラバイト規模のクレジットがネット上で流通している」と述べた。
- SOCRadarは、Telegram上であるブローカーがLiteLLM、Trivy、CanisterWormのデータを圧縮後150 GB以上というセットで販売しているのを確認した。これは、広く流通しているというよりは、1人の販売者がこのコレクションを保有しているものと見られる。
その区別によって、認証情報がいつ頃使用されるかを見積もることができます。ただし、それらが3月にコピーされたかどうかについては変わりません。
影響が及んでいた期間は、報じられていたものよりも長期間である
この事実は、他社による報道と同様に、私自身が7月に投稿した内容を修正するものです。
LiteLLMの侵害として報告されたこのキャンペーンは、悪意あるパッケージがPyPI上に存在していた3月24日の約40分間を軸に展開されていました。しかし、SOCRadarが2,188件の組織レコードのタイムスタンプを分析したところ、情報漏洩はそれよりも早い段階で発生していたことが判明しました。
- Earliest collection record: March 19, 18:05 UTC
- 最新情報：3月24日 20:09（UTC）
- LiteLLMパッケージが公開される前の3月24日以前の回収活動を示す記録：2,188件中2,085件、つまり95パーセント
SOCRadarは、そのタイミングをLiteLLMのインストール期間ではなく、上流のTrivyにおける侵害を示唆するものと捉えており、SecurityWeekも8月14日に同様の見解を示しています。SOCRadarの表現こそ採用すべきものです。すなわち、その40分間は劇の「終幕」に過ぎず、劇のすべてではなかったということです。
そのため、3 月 24 日までのログ検索の範囲は狭すぎました。 有害なリリースをインストールした場合、その日付は依然として重要ですが、暴露のほとんどはそれより前に行われています。
Trivy独自の是正措置がケーススタディとなっている
ローテーションが失敗する理由の一つは、最初の犠牲者の事例に記録されています。
Aquaは3月1日、侵害されたことが判明していた自動化用IDの認証情報を無効化しました。その後の経緯については、Aqua側の時系列情報やCVE-2026-33634に関するNVD（全米脆弱性データベース）の記録と照らし合わせながら、CloudSEKがまとめたタイムラインで確認できます。無効化後も、別のユーザーやトークンを使用した活動が継続していました。3月1日当時に確認されたトークンが、3月19日の悪意ある活動の中で再び使用されたのです。さらに3月22日には、侵害の疑いを持たれていなかったサービスアカウントが、別の組織にある43個のリポジトリにアクセスしました。CloudSEKは、ローテーション（更新）後も自動化用トークンが使用可能な状態にあった期間を約20日間と推定・再構築していますが、この数値は確定したフォレンジック調査結果ではなく、同社による独自の分析・再構築に基づくものであると明記しています。
Flareはより率直にこう述べています。「Aquaは認証情報を更新しましたが、一部更新漏れがありました。その結果、古いアクセス権が残ってしまったのです。」
認証情報が同時に無効化されなかったため、代替のシークレットが発行される間も、少なくとも1つのIDが使用可能な状態のままでした。ここからCloudSEKが導き出した推論は以下の通りです。もし有効なままのIDで、新たにローテーションされたシークレットにアクセスできてしまう場合、個々のトークンをローテーションしただけでは、侵入者を排除できない可能性があります。リリースパス上のすべてのIDを対象とした単一の封じ込めイベントとしてではなく、一連のトークン置き換えとして実施する場合、ローテーションを行うことで、かえって攻撃者にそのローテーションの成果物（新しいシークレット）を渡してしまうリスクがあります。
「すべてをローテーション（更新）した」という主張と、「その認証情報はもはや機能しない」という主張は別物です。検証可能なのは後者のみであり、私が目にした限り、それに関する公開された検証はBeaumontによるものだけです。
誰も到達できない「半分」
2つ目の失敗の要因は、被害者側ではなく、情報開示のモデルにあります。
Hudson Rockは118,829件の「ランナー・ダンプ（CIランナーの実行ログや環境変数などのデータ）」を特定のドメインに紐付けましたが、解決できなかったものについても明言しています。それは、多数のファイルが「極めて機密性の高い情報を含んでいるにもかかわらず、どの組織のものかを示す情報が全く欠落している」というケースです。つまり、それらの組織の有効な機密情報がデータセット内に存在しているにもかかわらず、組織側はそれを知る術がないのです。GitGuardianは8月14日、その結果が意味するところを端的に指摘しました。すなわち、企業名を特定できなければ通知を行うことは不可能であり、責任ある情報開示には連絡先が必要ですが、汎用的な設定のCIランナーではそうした情報が残らない、ということです。
したがって、検索ツールが存在しないことは弱い証拠です。 影響を受ける Trivy アクションや LiteLLM 1.82.7 または 1.82.8 をウィンドウで実行した場合、研究者がランナーをドメインに解決できるかどうかではなく、独自のパイプライン レコードが暴露の疑問に答えます。
なぜこれがギャップ2なのか
盗用されたAWSキー、リポジトリトークン、Kubernetesサービスアカウント、あるいはモデルプロバイダーのキーが、パイプラインと同じインターフェースを介して認証を行います。その際、自動化処理のように見えるインフラストラクチャから、当該IDに許可された操作が実行されます。クラウドプロバイダーは、認識されたプリンシパルによるAPI呼び出しの成功を記録します。認証は成功します。その後の活動において、エクスプロイト（脆弱性攻撃）が関与することはありません。
認証情報が依然として有効な場合、認証結果自体からは何も読み取れません（結果は「成功」となるためです）。しかし、サインインの際には「見慣れないネットワーク」や「通常とは異なるクライアント」といったシグナルが残っており、これらはアラートの対象とする価値があります。特に注目すべきは振る舞いに関するシグナルです。例えば、サービスアカウントがこれまで一度もアクセスしたことのないリソースにアクセスしようとしたり、無効化されたはずのトークンが提示され、かつ受け入れられたりするケースが挙げられます。個々の事象はそれぞれ説明がつくものかもしれませんが、それらが一連の流れとして発生した場合には、単純な説明では不十分となります。
今週の実施事項
チケットではなく、ローテーション（更新）が正しく行われたかを確認してください。対象のプロセスがアクセス可能な各認証情報について、古い値が拒否されることを確認します。
- クラウドキー、およびインスタンスメタデータサービスから読み取れるあらゆる情報
- リポジトリ、レジストリ、およびパッケージ公開トークン
- SSH キーと Kubernetes サービスアカウント
.envコンテンツ、データベースのURL、およびAIプロバイダーのキー
是正措置の検討において採用すべきなのは、Flareが提示するアプローチです。つまり、ローテーションを単なるインシデント対応タスクではなく、インベントリ（資産）管理の一環として捉えるのです。この手法が有効なのは、対象となる認証情報の全容を把握している場合に限られます。また、CloudSEKが指摘するように、ログに動きがないからといって、認証情報がコピーされなかったことの証明にはなりません。
そこで、検索範囲を2月27日から3月下旬まで広げると：
- 本番環境に対して認証を行うパイプラインサービスアカウント
- ご自身の組織内にある、
docs-tpcpまたはtpcp-docsという名前のリポジトリ - 2026年4月より前に発行され、現在も使用されているトークン
『Mind Your Attack Gaps』の「Gap 2」の章では、Scattered Spiderによるヘルプデスクを悪用した手口を例に、同様の障害（セキュリティ侵害）のパターンを解説しています。このケースでは、認証情報自体は正当なものであり、サインインのプロセスも正常に行われていました。Vectra AIでは、認証後のIDの振る舞いをクラウド、ID、ネットワークの各領域にわたってモデル化しており、こうした「盗用された有効なトークン」の存在を可視化しています。
そのアーカイブは3月の日付のものです。9月になった今でもそれが重要かどうかは、クレデンシャルストアが答えを教えてくれるでしょう。