TeamPCPによるソフトウェアサプライチェーン攻撃は段階的にエスカレートし、最終的にGitHubの内部リポジトリ約3,800件の窃取に至りました。きっかけは、従業員のデバイスが汚染されたVS Code拡張機能によって侵害されたことです。
GitHubは、攻撃者が主張するリポジトリ数は調査結果と「おおむね一致する」としています。一方で、顧客が所有するリポジトリが影響を受けた形跡は確認されていないと説明しています。
このインシデントでは、自動化されたビルドパイプラインと開発者のワークステーションという2つの攻撃対象が結びつけられました。
TeamPCPは2026年3月、侵害したセキュリティツールを起点に認証情報を収集しました。この認証情報によって次々と新たな侵害を重ね、5月にはNx Console拡張機能に到達しました。
Aqua Securityは、Trivyの侵害は2月下旬に発生した、設定に不備のあるGitHub Actions環境への侵入に端を発すると突き止めました。
Cyber security news
認証情報のローテーションが不完全だったため、アクセス権が一部残存していました。攻撃者はTrivyのスキャン機能の脆弱性を突いたのではなく、リリースの自動化プロセスを侵害したのです。
その後、これらの可変タグを参照するワークフローは、設定を変更しなくても悪意あるコードを実行する状態になりました。
ペイロードは、Runner.Workerのプロセスメモリからシークレットを直接抜き取りました。これにより、ワークフローログのマスク処理による保護を回避しています。
さらに、ファイルシステム上の50か所以上を探索し、SSHキー、クラウドの認証情報、Kubernetesトークン、Docker設定、環境ファイルなどの機密情報を探しました。
収集したデータは暗号化され、Aqua Securityになりすましたドメインであるscan.aquasecurtiy.orgに送信されました。
適切なGitHub権限が利用できる場合には、代替手段として、盗んだアーカイブをtpcp-docsという名前のリポジトリに配置することもできました。正規のGitHubインフラが、データ持ち出しの経路として悪用されたことになります。
盗まれたトークンは、その後Checkmarx KICSなどのソフトウェア配布チャネルへの攻撃に使われました。LiteLLMのバージョン1.82.7と1.82.8も侵害されています。
後者では悪意ある.pthファイルが仕込まれており、LiteLLMを明示的にインポートしなくても、Pythonの起動時にペイロードが実行される仕組みでした。
5月18日、攻撃者は盗み出した拡張機能の公開用認証情報を使い、Nx Consoleのバージョン18.95.0を公開しました。
Blackfogの研究者によると、攻撃者は悪意あるTrivyバージョン0.69.4を公開し、trivy-actionの77個のバージョンタグのうち76個を付け替え、setup-trivyの7個のタグをすべて置き換えました。
TeamPCPのサプライチェーン攻撃
この拡張機能は、全バージョンの累計インストール数が220万を超えていました。仕込まれた多段階のペイロードは、アプリケーションの脆弱性ではなく、開発者のシークレットを狙うものでした。
Study Security
TeamPCPは2025年末に登場した、金銭目的のグループです。新しい集団ではなく、名称を変更しただけだと主張しています。主な連絡手段はTelegramです。
研究者は、GitHub、npm、AWS、HashiCorp Vault、Kubernetes、1Passwordを対象とした収集機能を確認しました。
データの持ち出しには、HTTPS、GitHub API、DNSトンネリングが使われました。攻撃者は、侵害したシステムから認証情報を抜き出す経路を複数確保していたことになります。
GitHubによると、従業員端末の侵害は5月18日に検知して封じ込めました。悪意ある拡張機能のバージョンを削除し、該当デバイスを隔離したうえで、重要なシークレットをローテーションしています。
GitHubの開示では、内部リポジトリの窃取と、顧客自身のエンタープライズ、組織、リポジトリへのアクセスとを区別しています。
ただしGitHubは、一部の内部リポジトリにサポートでのやり取りの抜粋など、顧客に関する情報が含まれていたと注意を促しています。
同社はその後、GitHub Enterprise Serverの署名鍵をローテーションすると発表しました。管理者は今後のリリースをインストールする前に、信頼する公開鍵を更新する必要があります。
今回の攻撃は、汚染されたパッケージを削除するだけでは対処として不十分であることを示しています。盗まれたトークンは失効させるまで使用でき、侵害された公開用認証情報があれば、信頼されたチャネルを通じて新たな悪意あるリリースを配布できてしまうためです。
防御側は、影響を受けた実行を特定し、露出した認証情報を失効させ、その後の認証アクティビティを調査する必要があります。侵害されたランナーやエンドポイントは再構築してください。
GitHub Actionsを検証済みの完全なコミットハッシュに固定すれば、可変タグによるリスクを減らせます。トークンの権限を制限し、公開用の認証情報を分離することも、被害の拡大を抑えるうえで有効です。
根本的な失敗は、単に悪意あるソフトウェアを信頼したことではありません。再利用可能な認証情報が、ビルドシステム、パッケージレジストリ、クラウド環境、開発者のマシンをつないでしまったことにあります。
窃取が成功するたびに次の攻撃の到達範囲が広がり、個別の侵害が連鎖的な配布問題へと変わっていきました。
MTTRを21分短縮し、被害が出る前にサイバー脅威を阻止。ANYRUNのSandboxをSOCに統合。
Audit Security
翻訳元: https://gbhackers.com/teampcp-supply-chain/
