TeamPCPの認証情報アーカイブに名前が挙がっていたある組織は、ケビン・ボーモントに対し、この情報漏洩の問題は対処済みであり、すべての認証情報が更新されたと伝えた。彼はその組織の責任ある開示方針を確認し、認証情報のテストが許可されていることを確かめた上で、実際にテストを試みた。
これは1件の投稿であり、1つの組織に関するもので、ボーモントはその組織名を明かしていません。これを単一のデータポイントとして扱ってください。しかし、これは「解決済みの是正チケット」と「資格情報の取り消し」との間の時間的間隔に関するデータポイントであり、このチェーンの最初の被害者からの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の投稿にはこれと同等の注意書きが含まれていないため、2つのリストを比較する際にはこの点を念頭に置いておく必要があります。
両社とも、照合された組織名を公表しています。ここではそれらの名称を繰り返しません。再構築された情報漏洩の照合結果は、侵害が確認されたことを意味するものではなく、その区別は、単に企業名のリストとして提示されただけでは失われてしまいます。
どちらの企業もこのアーカイブを公開していない。ハドソン・ロック社はこれを自社の「キャバリア」プラットフォームに組み込み、被害者ごとに開示手続きを行っている。一方、クラウドSEK社はパブリックドメインでの検索サービスを提供している。このコーパスがより広く出回っているかどうかは不明であり、この件に最も詳しい関係者たちの見解も分かれている：
- ハドソン・ロック社のアロン・ガル氏は『Help Net Security』に対し、「現時点ではどこにも流出しておらず、広く出回ってもいない」と語った。
- ボーモント氏はその週、「現在、テラバイト規模のクレジットがネット上で流通している」と述べた。
- SOCRadarは、Telegram上であるブローカーがLiteLLM、Trivy、CanisterWormのデータを圧縮後150 GB以上というセットで販売しているのを確認した。これは、広く流通しているというよりは、1人の販売者がこのコレクションを保有しているものと見られる。
その区別によって、認証情報がいつ頃使用されるかを見積もることができます。ただし、それらが3月にコピーされたかどうかについては変わりません。
その窓は、皆が報告していたものよりも幅が広い
これは、7月の私の投稿だけでなく、他の誰かの報道についても訂正するものです。
このキャンペーンは、「LiteLLM侵害事件」として報じられ、3月24日に悪意のあるパッケージがPyPI上に約40分間掲載されていた期間を中心に報じられた。SOCRadarは、2,188件の組織レコードのタイムスタンプを分析した結果、この情報漏洩がそれより前に発生していたことを突き止めた：
- 最も早い収集記録：3月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を対象に、認証情報を無効化しました。CloudSEKのタイムラインを、Aqua社の時系列記録およびCVE-2026-33634に関するNVDの記録と併せて読むと、その後の経緯が明らかになります。 活動は別のユーザーとトークンを通じて継続した。3月1日の期間に確認されたトークンは、3月19日の悪意ある活動において再び出現した。3月22日には、誰も侵害されたとは考えていなかったサービスアカウントが、別の組織の43のリポジトリにアクセスした。CloudSEKは、トークンのローテーション後も約20日間、自動化トークンが使用可能な状態が続いていた状況を再構築しており、この数値は検証済みのフォレンジック期間ではなく、同社独自の再構築結果であることを明記している。
Flareはさらに率直にこう述べている。「Aquaは認証情報をローテーションしたが、一部を見落としていた。残っていたアクセス権は有効なままだった。」
認証情報は同時に無効化されなかったため、代替のシークレットが発行されている間も、少なくとも1つのIDが利用可能な状態のまま残ってしまいました。CloudSEKはこれに基づき、次のような推論を提示しています。もし存続しているIDが新しくローテーションされたシークレットにアクセスできる場合、個々のトークンをローテーションしたとしても、必ずしも侵入者を排除できるとは限らない、というものです。リリースパス上のすべてのIDを対象とした単一の封じ込めイベントとしてではなく、一連のトークン置換として実行された場合、ローテーションによって攻撃者に自身の出力を渡してしまうリスクがあります。
「すべてをローテーションした」と「認証情報が機能しなくなった」というのは、異なる主張です。 検証可能なのは後者だけであり、 私が確認した限りでは、ボーモント氏による検証が唯一の公開された検証例です。
誰も手が届かない半分
2つ目の失敗のパターンは、特定の被害者によるものではなく、開示モデルに起因するものである。
Hudson Rockは、118,829件のランナーダンプを特定のドメインに紐付けましたが、解決できなかった点についても明確に述べています。それは、「極めて機密性の高い秘密情報を含むものの、組織の帰属がまったく特定できない」ファイルが多数存在するということです。これらの組織は、そのデータセット内に自社の機密情報が含まれているにもかかわらず、その事実を知る術がありません。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』の「ギャップ2」の章 『Mind Your Attack Gaps』 の「ギャップ2」の章では、Scattered Spider のヘルプデスクチェーンを通じて、認証情報が正規のものであり、サインイン自体に問題がなかったにもかかわらず発生した同様の失敗事例を取り上げています。Vectra AIでは、認証後のIDがクラウド、ID、ネットワーク全体でどのように振る舞うかをモデル化しており、そこでは有効な盗難トークンの存在が可視化されます。
そのアーカイブは3月のものです。9月になってもそれがまだ重要かどうかについては、資格情報ストアが答えを出してくれます。
---
開示事項： Vectra AIはCloudSEKのデータセットに含まれています。3月19日および20日、当社のCI/CDワークフローの一部において、改ざんされたTrivy GitHub Actionが実行され、ビルドメタデータおよびジョブごとの短期間有効な認証情報が漏洩しました。当社はこれを社内で検知し、数時間以内にツールを交換するとともに、関連する認証情報を更新しました。また、8月にはCloudSEKの調査結果と照らし合わせて記録を再確認しました。当社の声明全文は こちらをご覧ください。