Flare、TeamPCP運営者を特定 TrivyからLiteLLMへ連鎖したサプライチェーン攻撃、豪州で2人起訴|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年09月02日更新日時: 2026年09月02日

カナダの脅威インテリジェンス企業Flareは2026年8月27日、ソフトウェアサプライチェーン攻撃を繰り返してきたサイバー犯罪グループ「TeamPCP」について、運営者の特定に至った調査結果を公開しました。

Flareは、TeamPCPが使用していた「DeadCatx3」などのハンドルネームを起点に、HackerOne、Hugging Face、メールアドレス、漏えい認証情報、TikTok、Steam、Telegramなど複数の公開・侵害情報を関連付け、豪州パース在住の人物がTeamPCPの運営に関与していると高い確度で評価しました。同社は調査結果を法執行機関とも共有したとしています。

同日、オーストラリア連邦警察（AFP）は、西オーストラリア州の21歳と23歳の男性2人を、世界的なサイバー犯罪組織への関与をめぐり起訴したと発表しました。AFPとFBIなどは、両名がオープンソースソフトウェアへ悪意あるコードを挿入し、1,000を超える組織へ影響を与えた疑いがあるとしています。

TeamPCPは2026年、Aqua Securityの脆弱性スキャナー「Trivy」を起点に、LiteLLMなどの開発・配布環境へ影響が連鎖するサプライチェーン攻撃を実行しました。Flareは、1つの有効なまま残った認証トークンから、約5日間で複数のソフトウェアエコシステムへ攻撃が拡大したと分析しています。

FlareのTeamPCP調査のサマリー

Flareは2026年8月27日、TeamPCPの運営者を特定したとする調査結果を公開しました。
Flareは「DeadCatx3」というハンドルネームを起点に、複数のSNS、開発者サービス、メールアドレス、漏えい認証情報、プロフィール画像などを関連付けました。
Flareは、豪州パース在住の人物がDeadCatx3およびTeamPCPの運営に関与していたと高い確度で評価し、法執行機関とも調査結果を共有したとしています。
同日、AFPは西オーストラリア州の21歳と23歳の男性2人を、TeamPCPに関連するとされる世界的サイバー犯罪への関与で起訴しました。
TeamPCPは2026年、Aqua SecurityのTrivyを起点とするサプライチェーン攻撃を実行しました。
Aqua Securityの公式調査では、GitHub Actionsのpull_request_target設定が悪用され、組織・リポジトリのシークレットが窃取されました。
2026年3月19日には、盗まれた認証情報を使って悪意あるTrivy v0.69.4などが正規配布経路から公開されました。
LiteLLMのCI/CD環境では侵害されたTrivyが利用され、PyPI公開用認証情報が窃取されたとみられています。
3月24日にはLiteLLM 1.82.7と1.82.8の悪性バージョンがPyPIへ公開されました。
LiteLLMの月間ダウンロード数約9,500万件という数字は、実際に9,500万環境が侵害されたことを意味しません。
FBIは2026年7月2日、TeamPCPについてFLASHを公開し、Trivy、KICS、LiteLLM、Telnyx Python SDKなどの改ざんを公式に警告しました。
FlareとFBIはいずれも、GitHub ActionsのSHA固定、認証情報の完全なローテーション、最小権限、短命な公開トークン、CI/CDの外部通信監視などを対策として挙げています。

項目	内容
調査公開日	2026年8月27日
調査主体	Flare Emerging Threats Team
対象	サイバー犯罪グループTeamPCP
主な攻撃領域	OSS、GitHub Actions、CI/CD、npm、PyPI、クラウド環境
代表的な被害	Trivy、LiteLLMなどのソフトウェアサプライチェーン侵害
Flareの帰属評価	DeadCatx3を起点に運営者を高い確度で特定したと評価
法執行機関の動き	AFPが2026年8月、TeamPCP関連の疑いで西豪州の男性2人を起訴
FBIの対応	2026年7月2日にTeamPCPのTTP・IOC・対策をまとめたFLASHを公開

TeamPCPはクラウド侵害からソフトウェアサプライチェーンへ転換

Flareによると、TeamPCPは2025年後半、インターネット上に露出したDocker API、Kubernetesのコントロールプレーン、Ray Dashboard、Redisなどを探索し、侵害したサーバーをスキャンやプロキシへ転用する活動から存在感を強めました。

Flareのハニーポットでは、一つの活動フェーズだけで185件のDocker環境侵害を識別したとしています。グループは暗号資産マイニング、プロキシ提供、窃取データの販売・恐喝など複数の方法で収益化を図っていました。

その後、2026年初頭からTeamPCPは攻撃対象をソフトウェアサプライチェーンへ移します。

この転換が重要なのは、1台のサーバーを侵害するより、開発者やセキュリティツールを侵害した方が、そのソフトウェアを信頼して利用する多数の組織へ一度に到達できるためです。

FBIも2026年7月2日のFLASHで、TeamPCPが広く利用される開発ツールやセキュリティツールを標的にし、正規パッケージへ悪意あるコードを挿入して、クラウドアクセストークン、SSHキー、Kubernetesシークレットなどを窃取していたと説明しています。

セキュリティ対策Labでは、FBIの注意喚起を「FBI、TeamPCPのサプライチェーン攻撃に緊急警戒情報-Trivy・KICS・LiteLLM侵害の全体像とIOC・対策」で整理しています。

TrivyのGitHub Actions設定から認証情報を窃取

TeamPCPの一連の攻撃で特に重要なのが、Aqua Securityのオープンソース脆弱性スキャナー「Trivy」への侵害です。

Aqua Securityが3月30日に公開した事後調査によると、最初の侵入は2月27日に発生しました。

攻撃者はTrivyリポジトリ内のGitHub Actionsワークフローで使用されていたpull_request_targetを悪用し、組織レベルおよびリポジトリレベルのシークレットを外部へ取得しました。その後、窃取した認証情報を使い、他のリポジトリや別のGitHub Organizationへもアクセスを広げました。

Aqua Securityは初動で認証情報のローテーションを実施しましたが、すべての有効な認証情報を完全には無効化できませんでした。

この残存アクセスが後のサプライチェーン攻撃につながります。

3月19日、攻撃者は盗まれた認証情報を使って悪意あるTrivy v0.69.4を公開しました。さらにtrivy-actionの多数のタグやsetup-trivyのタグも悪意あるコミットへ差し替えました。

Aqua Securityの公式アドバイザリでは、Trivy v0.69.4、trivy-actionの0.35.0未満、setup-trivyの0.2.6未満などが影響対象として整理されています。3月22日にはDocker HubへTrivy v0.69.5、v0.69.6の悪性イメージも公開されました。

TrivyからLiteLLMへ二次侵害が連鎖

TeamPCPの攻撃で重要なのは、「直接侵害されたソフトウェア」と「そのソフトウェアを利用したことで二次侵害された環境」を分けることです。

LiteLLMは、Trivyそのものと同じ侵入経路で直接侵害されたわけではありません。

LiteLLMの開発・CI/CD環境ではセキュリティスキャンにTrivyが使われていました。悪性化されたTrivyがビルドパイプライン内で実行されたことで、LiteLLMのPyPI公開用認証情報が取得されたとみられています。

その認証情報を使い、攻撃者は2026年3月24日、LiteLLM 1.82.7と1.82.8という2つの悪性バージョンをPyPIへ公開しました。

LiteLLM公式GitHubも、1.82.7と1.82.8が侵害され、Trivyのサプライチェーン侵害を経由して公開用アカウントが侵害されたと説明しています。両バージョンはその後削除され、公開用アカウントや認証情報のローテーションが行われました。

攻撃の関係を整理すると次のようになります。

段階	状況
TrivyのGitHub Actions	直接侵害。ワークフロー設定を起点にシークレットを窃取
Trivyの正規配布経路	侵害。悪性バージョンやGitHub Actionsタグを公開・改ざん
LiteLLMのCI/CD	悪性Trivyを実行したことで二次侵害され、公開用認証情報が窃取されたとみられる
LiteLLMのPyPI	窃取された認証情報で悪性1.82.7・1.82.8を公開
LiteLLM利用環境	当該悪性バージョンを取得・実行した場合に侵害の可能性

この区別は重要です。

FlareはLiteLLMについて月間約9,500万ダウンロードの規模としていますが、「9,500万ダウンロード＝9,500万環境が侵害された」という意味ではありません。実際の侵害には、悪性バージョンを対象時間帯に取得し、対象環境で実行するなどの条件があります。

セキュリティ対策Labでも「LiteLLMへサプライチェーンサイバー攻撃、2,500組織・43万件超のCI/CDパイプラインに影響か CloudSEKが被害規模を分析」で、Trivy側の露出とLiteLLMの悪性パッケージ実行環境を分けて整理しています。

Flareは「DeadCatx3」からTeamPCP運営者を追跡

Flareの今回のレポートで新しいのは、攻撃手法そのものではなく、TeamPCP運営者の特定プロセスです。

調査は、TeamPCPが過去に利用していた「DeadCatx3」というハンドルネームから始まりました。

Flareはこのハンドルネームを複数のサービスで検索し、HackerOneやHugging Faceなどに同一名称を使うアカウントが存在することを確認しました。Hugging Faceのプロフィールには、TeamPCPがMini Shai-HuludでC2として利用したとFlareが確認していたドメインとの関連も残されていました。

そこからメールアドレス、漏えいした認証情報、別のメールアドレス、TikTok、Steamなどへ調査を広げています。

最終的にFlareは、TeamPCPのTelegramアカウントで使われていたプロフィール画像と、調査対象者のSteamアカウントの画像が一致していることなど、複数の独立した要素を関連付けました。

Flareは、個々の一致だけなら偶然やアカウント共有などで説明できるものの、複数のハンドルネーム、メール、プロフィール、利用インフラ、画像の再利用が一つの連続した関係を形成したとして、DeadCatx3の運営者を高い確度で特定したと評価しています。

なお、本稿ではFlareが調査に利用した漏えいパスワードや個人メールアドレスなど、運営者特定に不要な具体的認証情報は掲載しません。

豪州で21歳と23歳の男性2人を起訴

Flareが調査レポートを公開したのと同じ8月27日、オーストラリア連邦警察は、西オーストラリア州在住の21歳と23歳の男性2人を、世界的なサイバー犯罪組織への関与をめぐり起訴したと発表しました。

AFP、Western Australia Police Force、FBIによる共同捜査で、2人は合計14件の罪で起訴されています。

AFPは、当該グループがオープンソースリポジトリで配布されているソフトウェアへ悪意あるコードを挿入し、そのソフトウェアを利用した政府、学術機関、民間企業などへ侵害を広げた疑いがあると説明しています。

FBIは両名についてTeamPCPのメンバーとみており、捜査当局は1,000を超える組織が影響を受けた可能性があるとしています。

一方、2人は現時点で起訴された段階です。刑事責任が裁判で確定したわけではないため、「TeamPCPの犯人」と断定することは適切ではありません。

Flareは、自社の運営者特定結果を法執行機関と確認したとしていますが、民間調査会社による帰属評価と、刑事裁判での有罪認定も分けて扱う必要があります。

TeamPCPの特定につながったのは「高度な匿名化の破綻」ではなく情報の再利用

Flareの調査で注目すべき点は、特別なゼロデイや高度な匿名解除技術を使って運営者を特定したわけではないことです。

TeamPCPはTelegram、X、GitHubなどで積極的に活動し、被害組織を挑発したり、自らの活動について発信したりしていました。

その過程で、過去のハンドルネーム、プロフィール画像、メールアドレス、ドメイン、別サービスのアカウントなどを再利用していました。

Flareは、こうした小さな関連情報を積み重ねることで、匿名のサイバー犯罪者と現実世界の人物を結び付けました。

これは企業の脅威インテリジェンスにも共通する考え方です。一つのIPアドレスやドメインだけで攻撃者を断定するのではなく、ハンドルネーム、認証情報、インフラ、マルウェア、投稿履歴、時間帯、アカウント間のつながりなどを複数組み合わせる必要があります。

セキュリティツール自体がサプライチェーンの高価値標的に

Flareは今回のTeamPCP攻撃について、技術的な高度さ以上に「標的の選び方」が重要だったと指摘しています。

脆弱性スキャナーのようなセキュリティツールは、CI/CDパイプラインの中で動作し、多数のシークレット、クラウド認証情報、GitHubトークン、レジストリ認証情報などへアクセスできる場合があります。

つまり、セキュリティツールを侵害すると、そのツールが守っている一つの環境だけでなく、そのツールを信頼して利用している多数の開発パイプラインへ到達できます。

LiteLLMはこの構造を象徴する事例です。

LiteLLM自体の開発者アカウントへ最初から直接侵入したのではなく、CI/CD内で信頼して実行していたTrivyが悪性化したことで、次の公開用認証情報が奪われました。

Flareは「信頼の連鎖がそのまま攻撃の連鎖になる」という点をTeamPCPの重要な特徴として捉えています。

GitHub Actionsはタグではなくcommit SHAへ固定

Flareは防御側に対し、TeamPCPの攻撃チェーンを途中で切るための複数の対策を挙げています。

第一は、GitHub Actionsを可変のタグではなく完全なcommit SHAへ固定することです。

@v1や@latestのようなタグは、参照先が後から変更される可能性があります。TeamPCPはTrivy関連のGitHub Actionsタグを悪意あるコミットへ差し替えることで、利用者側がワークフローを変更していなくても、次回のCI/CD実行時に悪性コードが読み込まれる状態を作りました。

FBIも2026年7月のFLASHで、すべてのGitHub Actionsワークフローを検証済みのcommit SHAへ固定することを推奨しています。

認証情報ローテーションは「確認できたものだけ」で終わらせない

第二の教訓は、インシデント後の認証情報ローテーションです。

Aqua Securityは最初の侵害後に認証情報を変更しましたが、後の事後調査で、別のGitHub Organizationやサービスアカウントを含め、攻撃者が利用可能な認証情報を完全には把握できていなかったことが分かりました。

そのため、Flareは認証情報ローテーションを単なる「侵害されたトークンの変更」ではなく、環境内に存在する全認証情報の棚卸しとして実施すべきだとしています。

CI/CDサービスアカウント、GitHub PAT、npm・PyPI公開トークン、クラウドキー、SSHキーなど、侵害されたパイプラインから参照可能だった認証情報を洗い出し、一括して失効・再発行する必要があります。

FBIも、攻撃期間中にアクセス可能だったCI/CDシークレット、公開トークン、クラウド認証情報をすべてローテーションするよう求めています。

公開トークンは短命・最小権限にする

第三は、パッケージレジストリの公開権限を最小化することです。

長期間有効で、複数パッケージを公開できるトークンがCI/CDから窃取されると、一つのビルド環境侵害がそのまま多数の利用者へ影響するサプライチェーン攻撃へ変わります。

可能な場合はOIDCなどを使った短命な認証へ移行し、特定リポジトリ、特定ワークフロー、特定ブランチなど必要な範囲に公開権限を限定することが重要です。

ただし、TeamPCP関連のMini Shai-Huludでは、設定が緩いOIDC構成を悪用した事例も確認されています。OIDCへ移行するだけで安全になるわけではなく、発行条件やワークフローの制約まで確認する必要があります。

CI/CDからの不審な外部通信を監視

FlareとFBIが共通して挙げるもう一つのポイントが、CI/CDランナーからの外向き通信の監視です。

脆弱性スキャナーやビルドツールは通常、一定の外部通信を行いますが、突然未知のドメインへシークレットや環境情報を送信し始めた場合は重要な兆候になります。

TeamPCPのTrivyやLiteLLM関連の悪性コードも、CI/CD環境から取得した認証情報を外部へ送信する必要がありました。

そのため、CI/CD環境を「一時的なビルド環境だから監視対象外」とせず、DNS、HTTPS、プロセス、ワークフロー実行、アーティファクト公開などのログを取得し、通常とは異なる通信や操作を検知できるようにする必要があります。

情報システム・開発部門への示唆

TeamPCPの一連の攻撃は、ソフトウェアサプライチェーン対策を「依存パッケージに既知脆弱性がないか確認すること」だけで考えてはいけないことを示しています。

今回の起点は、正規のOSSプロジェクトで使われていたCI/CDワークフローと認証情報でした。利用者は偽物のTrivyを探して導入したわけではなく、普段から信頼していた正規の配布経路やGitHub Actionsを利用した結果、悪性コードへ到達する可能性がありました。

企業では、SBOMや依存関係の把握に加えて、GitHub Actions、CI/CDプラグイン、VS Code拡張、パッケージレジストリ、セキュリティスキャナーなど「開発環境で自動実行される第三者コンポーネント」もサプライチェーン資産として管理する必要があります。

また、ExposureとCompromiseを分けて調査することも重要です。影響期間中のTrivyやLiteLLMを依存関係に含んでいたからといって、直ちに認証情報窃取が確定するわけではありません。実際に対象バージョンやActionを取得・実行したか、その実行環境からどのシークレットへアクセスできたか、外部通信が発生したかを確認する必要があります。

一方、悪性コンポーネントをCI/CD上で実行したことが確認された場合は、マルウェアファイルの削除だけで終わらせず、そのランナーから参照可能だった認証情報を侵害された可能性があるものとして扱い、ローテーションと二次侵害調査を行う必要があります。

TeamPCPの攻撃全体とFBIのIOC・推奨対策については「FBI、TeamPCPのサプライチェーン攻撃に緊急警戒情報-Trivy・KICS・LiteLLM侵害の全体像とIOC・対策」、Mini Shai-Huludによるnpm・PyPIへの展開については「TanStack・Mistral AI・UiPath・npm・PyPIを狙うサイバー攻撃-Mini Shai-Huludが開発者の認証情報を狙うサプライチェーン攻撃キャンペーン」で整理しています。