Google傘下Mandiantの調査員が、サプライチェーン攻撃を繰り返したTeamPCPに潜入していた。WIREDが9月18日、Google Threat Intelligence Group（GTIG）のAustin Larsen氏への独自取材で報じた。得られた情報は、AWSやMicrosoftなどに盗まれた認証情報の失効を依頼する対応につながったという。開発ツールから奪ったアクセス権が次の侵入を生む事件では、配布されたソフトウェアを直した後も、盗まれた鍵への対応が残る。

AD

潜入情報を、盗まれた鍵の失効につなげる

潜入したのはLarsen氏本人ではなく、匿名の調査員だ。WIREDによると、Googleは被害企業への個別通知に先立ち、認証情報を受け付けるサービスの提供元へ連絡した。調査員は後に集団の内部チャットから排除されており、継続的にすべてを監視できたわけではない。WIREDの独自取材

この対応が意味を持つ理由は、TeamPCPの攻撃対象にある。Googleが7月31日に公表した分析では、同社がUNC6780として追跡するTeamPCPは、2026年2〜5月にPython向けのPyPI、JavaScript向けのnpm、コンテナを配布するDocker Hubなどを狙った。改ざんしたパッケージからSANDCLOCKなどの認証情報窃取プログラムを動かし、価値の高い秘密情報を集めていたという。

ソフトウェアのビルド、検査、配布を自動化するCI/CDには、処理を実行するためのアクセス権が渡される。攻撃者がそこで認証情報を盗めば、プログラムの不正配布を別の侵入へつなげられる。Googleは、TeamPCPが盗んだ情報の直接販売や、ランサムウェア・データ窃取による恐喝を行う集団との提携で収益化していたと説明する。Googleの分析

つまり被害対応には、不正な配布物を取り除く作業に加え、流出したアクセス権を使えなくする作業が要る。前者だけが済んでも、攻撃者の手元にある鍵は消えない。Googleによる失効依頼を、被害組織すべての復旧や攻撃の完全阻止と同一視することはできないが、次の侵入に使われる権限へ働きかけた点に意味がある。

なぜ鍵を交換しても攻撃が続いたのか

Trivyの開発チームが3月30日に公表した事後報告には、認証情報を更新する難しさが具体的に残っている。発端は2月27日、GitHub Actionsのpull_request_targetを使う脆弱な処理から秘密情報を盗まれたことだった。攻撃者は得た権限を使い、アクセス可能な別のリポジトリや組織でも窃取を続けたという。

Trivy側で3月1日に認証情報を失効させた後も別の侵入経路が残り、3月19日の不正配布に使われた。

ここでいう別の経路は、未知の脆弱性を新たに見つけたという意味ではない。事後報告の時系列では、自動処理用アカウントの認証情報を失効させた後、別の侵害済みユーザーが別のリポジトリで秘密情報を取り出していた。そして3月19日の活動には、その際に観測されたのと同じトークンが使われたとされる。

時点（2026年） 開発元が公表した出来事 認証情報と配布への影響
3月1日 Trivy側が侵害を確認した自動処理用アカウントの認証情報を失効 別ユーザーを通じた秘密情報の窃取が残った
3月19日 盗まれた認証情報でTrivyのリリース処理を実行 不正なTrivyを配布
3月24日 LiteLLMのPyPIパッケージ1.82.7と1.82.8に不正コード 同社はCI/CDで使うTrivyが侵入の起点だったと考えている

表はTrivyの事後報告の「Timeline of events」とLiteLLMの公式説明を日付順に並べたものだ。TrivyからLiteLLMへの経路はLiteLLM側の見解であり、両社で同じトークンが使われたと示すものではない。

Trivyチームは、組織をまたぐ強い権限を持つサービス用アカウントが十分に分離されていなかったことも反省点に挙げた。ある利用者の鍵を交換しても、攻撃者が別の利用者として残れば封じ込めは終わらない。どのアカウントがどの組織まで操作できるかを把握する必要が、ここに表れている。

ただし、同じツールの利用者を一括して被害者とするのも誤りだ。LiteLLMは、公式のProxy Dockerイメージについて、依存関係を固定しており問題のPyPIパッケージに依存しないため影響を受けなかったと説明している。製品名だけでなく、何をどの経路から取り込んだかが被害判定を左右する。

AD

逮捕されたのは2人、捜査は続く

豪連邦警察（AFP）は8月27日、西オーストラリア州の21歳と23歳の男を前日に逮捕し、合わせて14件の罪で訴追したと発表した。FBIと西オーストラリア州警察が関わる共同発表であり、2人はTeamPCPの主要な参加者だったと疑われている。発表は捜査段階の説明で、有罪判決を意味しない。

当局は、不正コードによって世界の1,000超の組織が侵害された可能性があり、50万件を超える認証情報の窃取と、少なくとも300GBのデータ流出につながったと推定している。「1,000社への侵入をすべて確認した」という数字ではなく、対象には企業以外の組織も含まれる。AFPの共同発表

捜査は4月、複数の民間脅威調査企業から情報を受けて始まった。AFPはその情報を捜査に不可欠だったと評価する一方、押収データの解析と捜査を続け、追加の逮捕・訴追も排除していない。Googleだけで事件を解決したとする読み方は、当局の説明よりも強すぎる。

Larsen氏も8月27日の自身の投稿で、TeamPCPを、個々に技能を持つ者が集まったコミュニティと説明した。2人への訴追と、集団が持つアクセス権や攻撃能力の消滅は、別々に確かめなければならない。

開発現場で見直す、配布経路とアクセス権

Trivyの事後報告が示した修復では、GitHubと配布先のトークンを全面的に失効させ、既存のアクセス権をすべて失効させるまで新しいトークンを発行しなかった。侵害された経路が残ったまま鍵を更新することを避ける対応だ。GitHub Actionsを特定のコミットSHAに固定し、対応する配布先でリリースを後から変更できなくする措置も取ったという。

認証情報の失効と、配布するコードの固定は、それぞれ別の箇所を守る。 前者は盗んだ鍵による操作を止め、後者は利用するコードや配布物が意図せず変わるリスクを抑える。固定したコード自体の安全性まで保証する仕組みではないため、どちらか一方で済む話ではない。

LiteLLMも3月30日の更新で、環境の隔離やリリース工程の分離を強化したCI/CD v2から、クリーンなバージョンを公開したと説明した。これは当時の復旧措置である。復旧後の設計で確かめるべきなのは、検査に使うツールへ渡した権限が、製品の公開までどこまで届くかだ。

Googleの7月の対策文書は、ソフトウェア部品表であるSBOMに加え、第三者製の開発ツールやパイプラインを把握するABOMも勧める。アプリに組み込まれる部品を把握するだけでは、ビルドや検査の途中で動く外部ツールを見落としかねない。開発環境を含めて攻撃経路を捉えるという提案である。

同文書はnpmやpnpmで、新しいパッケージの公開から少なくとも24時間待って取り込む運用も推奨する。これは不正な版の発見・削除を待つ猶予を作る措置であり、待機後の安全を保証するものではない。取り込み時の対策と、侵害後に失効させる権限の把握を組み合わせる必要がある。

次の不正パッケージが判明したとき、実行した環境と、そこからアクセスできたサービスを結び付けて追えるか。その対応範囲を日頃から把握できていれば、被害通知を受け取った後の調査と失効を、組織内のアカウントから外部サービスまで進めやすくなる。