Mini Shai-Huludサプライチェーン攻撃：このキャンペーンが防御者の信頼できるソフトウェアに対する考え方を変える理由

「Mini Shai-Hulud」によるサプライチェーン攻撃は、単なる悪意のあるパッケージの事例の一つに過ぎません。 このキャンペーンでは、信頼性の高い公開ワークフロー、出所証明付きパイプライン、開発環境など、正当なリリースインフラが悪用されました。 これらの手法は、コードがほとんどの標準的な検証や整合性チェックを通過してしまうため、悪意のある活動を正常なものに見せかけるのに特に効果的です。

のTanStack事後分析レポート（）によると、侵害されたTanStackパッケージには、プロジェクト独自のGitHub Actionsの信頼された公開パイプラインによって生成された、有効な出所証明が含まれていました。 出所の証明が有効であった場合でも、出所だけでは不十分でした。 脅威アクター「TeamPCP」によるものとされるこのキャンペーンでは、その後、盗み出された公開用認証情報を使用して、さらなるパッケージへとキャンペーンを拡大させました。

セキュリティチームが長年にわたり導入してきた制御措置の多くは、意図ではなく、真正性を確認するために設計されたものです。 このキャンペーンでは、提供されるソフトウェアが改ざんされていたとしても、真正性チェックは依然として通過してしまうことになります。

「Mini Shai-Hulud」サプライチェーン攻撃で何が起きたのか

セキュリティコミュニティ全体で広く報じられている通り、この攻撃キャンペーンはnpmおよびPyPI上の 170 を超えるパッケージに影響を及ぼし、広範な下流への波及効果を持つエコシステムにも波及しました。 この攻撃は、フロントエンドフレームワークに関連するパッケージ、AI SDK、エンタープライズ向け自動化ツール、検索インフラストラクチャなど、広く利用されている開発者向けツールやライブラリを標的としていました。

大まかに言えば、このキャンペーンは次のように展開されました：

• 攻撃者は、ビルドプロセスそのものを侵害することで、信頼された公開経路を乗っ取りました。
• 悪意のあるパッケージのバージョンは、正規のワークフローを通じて公開され、有効な出所証明が付与されていました。
• これらのパッケージがインストールされると、開発者のマシンやCI/CDランナーから認証情報を盗み出していました。
• その後、このマルウェアは盗み出した認証情報を利用して、さらに多くの悪意のあるパッケージを公開しました。
• クリーンアップの試みを乗り切り、認証情報の窃取を継続できるよう、永続化メカニズムが追加されました。

これが、このキャンペーンを「ワーム」のようなものにしたのです。 新たに侵害された各環境は、次の攻撃の拡散拠点となる可能性があります。

今回の攻撃が他と異なる理由

これは、単にパッケージの信頼性だけでなく、信頼されたリリースプロセスをも悪用したものでした

攻撃者は、単に明らかなタイポスクワットや偽のパッケージを公開するのではなく、正規のリリースパイプラインを乗っ取りました。 悪意のあるリリースには有効な出所情報が保持されていたことから、真正性の確認だけでは不十分であったことが浮き彫りになりました。

パッケージが想定されたパイプラインから送信されたかどうかを確認することだけが、あるいは主な確認手段である場合、それだけでは不十分です。 このパイプラインが攻撃の経路となっており、ミニ・シャイ・フルードは、アーティファクトを構築したパイプラインを確認・検証する一般的なチェックでは正当なものとして認識されてしまいます。これは、アーティファクトの内容が意図的なものかどうかを検証するものではありません。

それは単なるコードだけでなく、アイデンティティを通じて広まったのです

このキャンペーンは、アイデンティティを強く重視したものであり、極度に複雑に広がった秘密が絡み合う環境の中で展開されました。 The scale of exposed secrets in the ecosystem gave it room to run: GitGuardian reported 28.65 million new hardcoded secrets publicly exposed on GitHub in 2025.

単発の実行だけに頼るのではなく、開発者のマシンやCI/CDランナーから認証情報を盗み出すことに重点を置いていました。 攻撃者がそれらの身元情報を入手すると、ソフトウェアの配布そのものが拡散の手段となってしまいました。 これは、開発環境向けの永続化レイヤーとして設計されました。

このキャンペーンでは、開発者向けツールやローカルの設定パスに永続化フックが組み込まれました。これには、 、IDE関連のディレクトリ 、およびAI支援型コーディング環境などが含まれます。 .claude/settings.json（Claude Codeのセッションごとに再実行されるSessionStartフック）および.vscode/tasks.json（フォルダを開いた際に自動実行される）に設定が保存されているため、単に「npm uninstall」を実行しただけでは削除されません。

攻撃の連鎖はどのように機能したのか

実装方法はパッケージやエコシステムによって異なりましたが、このキャンペーンは概して、 サプライチェーンの侵害、認証情報の窃取、および自己拡散を組み合わせていました。

このマルウェアが盗もうとしたもの

「Mini Shai-Hulud」のサプライチェーン攻撃に関する報告によると、その収集範囲は広範囲に及んでいることが示されています。 目標は、単一のトークンタイプだけではありませんでした。 Q3 2025年、 のSonatypeは、 において、悪意のあるオープンソースパッケージの37％がデータの持ち出しを目的としていることを突き止めましたが、今回のキャンペーンも同様のパターンをたどっていました。 これは、横方向の移動、持続的な侵入、およびその後のシステム侵害に役立つあらゆる情報を収集することを目的として設計されました。

主な標的には、次のようなものがありました：

• クラウドプロバイダーの認証情報
• パッケージレジストリトークン
• CI/CDパイプラインのシークレット
• Gitの認証情報とソース管理トークン
• Kubernetes の設定ファイル、サービスアカウントのトークン、およびシークレットマネージャーへのアクセス権を付与する認証情報またはトークン
• SSH鍵
• ローカルの開発用設定ファイル
• AI開発ツールの設定
• 一部の亜種における仮想通貨ウォレットのデータ

対応チームは、「npmトークンを切り替えて、次へ進む」という考え方で臨んではいけません。 もし、悪意のあるパッケージが機密性の高い環境で実行された場合、その影響範囲ははるかに広くなる可能性があります。

影響を受けている可能性があることを示す兆候

潜在的な情報漏洩の可能性を調査するセキュリティチームは、依存関係とエンドポイントの挙動の両方を確認する必要があります。 これは単なるソフトウェアの構成上の問題だけではありません。

依存度を示す標識

まずは以下から始めてください：

• 影響を受けるバージョンを参照しているロックファイル
• 5月11日 以降のパッケージインストールログ
• preinstall や prepare などの予期しないライフサイクルスクリプト
• 不審なオプションの依存関係、またはGitベースのパッケージ参照
• 異常に大きなtarballや、難読化されたファイルが埋め込まれている場合

エンドポイントおよび環境レベルの兆候

こちらもぜひチェックしてみてください：

• .vscode/、 、または .claude/、 ディレクトリにおける予期せぬ変更
• 許可されていないLaunchAgentsまたはユーザーレベルのsystemdサービス
• リポジトリに新しいワークフローファイルが追加されました
• パッケージのインストール中に、不審なインフラへのアウトバウンド接続が発生しました
• メンテナが認識していないパッケージの公開イベント
• 盗まれた認証情報を使用して作成された、不審なパブリックリポジトリやコミット

ネットワークおよび行動上の兆候

主要なインシデント報告では、冗長化された情報流出経路も指摘されています。 つまり、防御側は、あるドメインをブロックすればリスクが解消されると安易に考えてはなりません。 以下の点にご注意ください：

• コードホスティングプラットフォームへの通常とは異なるAPI呼び出し
• 既知の攻撃者が管理するドメイン、データ漏洩に利用される公開コードホスティングAPI、Webhookエンドポイント、Tor関連のインフラ、またはIPFSゲートウェイへのトラフィック（これらが確認された場合）
• メタデータサービス、ローカルボールト、またはトークンストアへの突発的なアクセス
• 開発者のワークステーションやCIランナー上で、環境変数、トークンストア、シェル履歴、パッケージマネージャーの認証情報、またはその他の機密情報を含むファイルを読み取るプロセスの動作

「Mini Shai-Hulud」サプライチェーン攻撃への対処方法

これは、セキュリティ部門とIT運用部門の連携が必要な事案です。 効果的な対応には、通常、厳格な手順が定められています。

直ちに行うべき措置

• 影響を受けるパッケージのバージョンがインストールされていたかどうかを確認してください。
• 認証情報を無効化する前に、影響を受けた開発者のワークステーションおよびCI/CD環境を隔離してください。
• IR部門と連携し、トークンの失効によって、まだ接続中のホスト上で既知の破壊的なロジックが実行されないようにしてください。
• 大規模な変更を行う前に、永続化アーティファクトがないか確認してください。
• 可能な限り、鑑識証拠を保全してください。
• ご自身が管理しているパッケージのうち、予期せず再公開されたものがないか確認してください。

シーケンシングが重要な理由

このマルウェアには、デッドマンスイッチが組み込まれています。 パーシステンスデーモン（gh-token-monitor）は、 60 秒ごとにGitHubをポーリングします。 トークンの失効（HTTP 40X レスポンス）を検知すると、rm -rf ~/ を実行し、ホームディレクトリを完全に消去します。 つまり、防御担当者は、認証情報を無効化する前に、侵害された環境を隔離しなければなりません。 順序を間違えて実行すると、破壊的なペイロードが作動してしまいます。 そのため、この件に関して成熟した対応とは、単に「今すぐすべてを取り消せ」と言うことだけではありません。 それは：

• まずは隔離してください
• 永続性を確認する
• 必要に応じて画像を挿入してください
• その後、管理された手順に従って回転させ、修復を行ってください

のインシデント対応およびSecurity Operations に投資してきたチームは、エンドポイント、ID、フォレンジック・ワークフローにわたる一連のプロセスをより円滑に連携させることができます。

この事件がソフトウェアへの信頼について示唆すること

「Mini Shai-Hulud」によるサプライチェーン攻撃は、多くの組織が依然として抱えている盲点を浮き彫りにしています。それは、署名済み、公式、あるいは出所が保証されているものを、安全であると同一視してしまう傾向です。

それらは依然として貴重なシグナルです。 しかし、それだけでは不十分です。

より強力なモデルには、現在、以下のすべてが含まれています：

• ソフトウェアの出所を確認する
• 新しく公開されたバージョンの導入を遅らせる
• インストール時のスクリプトの実行を制限する
• ビルドおよびインストール中の実行時の挙動の監視
• CI/CDにおけるシークレットの露出を低減する
• サーバーと同じ厳格さで開発者のエンドポイントを監視する

チームが今すぐ実施すべき実践的なセキュリティ強化の手順

長期的な観点から見て正しい対応とは、パニックに駆られてパッケージを避けることではありません。 これは層状硬化です。

ビルドおよびパッケージングの制御

これらはすべて、信頼できるワークフローであっても悪用される可能性があるという前提に基づいた、 のソフトウェア・サプライチェーン防御戦略 の一環です。

IDおよび機密情報の管理

• 有効期間の長いパブリッシング認証情報を削減する
• CI/CDのIDを厳密に定義する
• ビルド、リリース、デプロイの権限を分離する
• ランナー上に存在するシークレットを最小限に抑える
• パッケージ公開へのアクセス権限および二要素認証のバイパス設定について、定期的に監査を行ってください

エンドポイントおよび開発環境の管理

• IDEの設定パスと起動フックを監視します
• 開発者向けツールのディレクトリは、無害なものではなく、セキュリティ上重要なものとみなしてください
• クラウドの認証情報やレジストリトークンが保存されているインベントリ
• パッケージの削除だけでなく、永続データの削除も確認してください

効果的なサプライチェーン対応には何が必要か

これは、単なるソフトウェアパッケージの脆弱性問題にとどまりません。 これは、エンドポイント、アイデンティティ、そして運用上の対応という、3つの側面を併せ持つ問題です。

結論として、 5月11日以降、組織内の開発者や自動ビルドシステムによって影響を受けるコンポーネントがインストールされていた場合は、それらの環境は侵害されているものとみなしてください。 感染の拡大は盗まれたIDに依存していたため、侵害された各環境が感染の拡散拠点となり得ました。

これは、業界標準の正当な出所証明を備えた悪意のあるパッケージを生成した、自己拡散型のサプライチェーン攻撃として初めて報告された事例です。 ソフトウェア成果物のサプライチェーン・レベル（SLSA）は、設計どおりに機能しました。 そのエコシステムは、実際よりも多くの問題を解決したと思い込んでいました。 プロヴィネンスは、どのパイプラインがアーティファクトを生成したかを確認するものであり、そのパイプラインが意図したとおりに動作していたかどうかを確認するものではありません。

犯人は偽の領収書を作成しませんでした。 彼らは台所に押し入り、そのレストランのコンロを使って毒入りの料理を作りました。 その領収書は、形式的には正確でした。

TeamPCP（ DeadCatx3、PCPcat、ShellForce、CipherForceとしても追跡されています）は、信頼チェーンそのものを組織的に標的にしてきました：

• 3月 2026：オープンソースのセキュリティスキャナー「Trivy」――セキュリティ担当者が使用するツール（マイクロソフト）
• 4月 2026：パスワードマネージャー「Bitwarden CLI」――認証情報の保存
• 5月 2026：npm／PyPIエコシステムにおけるワーム――ソフトウェア・サプライチェーン全体への影響

同グループは、ランサムウェア・アズ・ア・サービス（RaaS）を運営する「Vect」（Unit 42）との提携を発表しました。 帰属の指標には、ロシア語ロケールのキルスイッチ（Microsoft）が含まれます。 1人のオペレーターが関与している場合でも、複数の関連組織が関与している場合でも、この傾向からは、ランサムウェア関連のネットワーク内で、サプライチェーン攻撃用のツールが成熟しつつあることがうかがえます。

サプライチェーン攻撃は、単なる認証情報の盗難事件というよりも、ランサムウェアなど、より大規模な攻撃の前兆となることがよくあります。 、Notepad++、 といった信頼されているソフトウェアブランドや、ダウンロードチャネルを悪用した最近の攻撃は、ソフトウェアの配布経路が依然として重要な標的であることを改めて浮き彫りにしています。

防御側にとっては、これは3つのフェーズとそのタイムラインに分けられます：

1. 優先して行うべき直ちの対応（時間単位）

• 5月11日以降にインストールされたパッケージのバージョンに問題がないか、ロックファイルとCIログを確認してください。
• 感染が確認された場合は、トークンを無効化する前に、その環境を隔離してください
• 、com.user.gh-token-monitor.plist、 、、gh-token-monitor.service、 などの既知のサンプルの残存名を確認するとともに、機能的に同等の不正な LaunchAgents、ユーザーサービス、cron ジョブ、シェル起動時の変更、および IDE/ツール起動時のフックについても調査してください。
• .claude/ および .vscode/ ディレクトリに、注入された永続化ペイロードがないか確認してください
• npmトークンだけでなく、外部からアクセス可能なすべての認証情報をローテーションしてください

2。 短期的な対策（数日）

• 影響を受けるパッケージおよびバージョンについて、依存関係マニフェスト、ロックファイル、CIログ、キャッシュ、ランナーイメージ、および生成されたSBOMをすべて監査します。これには、フロントエンド、エンタープライズ自動化、検索、AIツールに関連するパッケージも含まれます。
• CI/CDランナーが、侵害されたnpmパッケージを実行している際にPyPIへの公開用認証情報を保持している場合は、それらもローテーションしてください
• `pull_request_target` を使用する GitHub Actions ワークフローについて、信頼できないコードのチェックアウト、書き込みスコープの ` ` `GITHUB_TOKEN`、公開されたシークレット、または信頼境界を越えたキャッシュの再利用と組み合わせて使用されている場合は、それらを再確認してください。これらの組み合わせにより、ワークフローが侵害される可能性があるためです。

3。 戦略的な取り組み（今週および今後）

• 情報公開の最低遅延期間：たとえ3日間の遅延であっても、このキャンペーンに対する防御的な余裕となり、急速に広がるサプライチェーン攻撃を軽減するためのCISAの指針に沿ったものとなったでしょう。 pnpmの「min-release-age」機能を利用して実装するか、あるいは、ネイティブでこの機能をサポートしていないパッケージマネージャーについては、プロキシレジストリやアーティファクトポリシーエンジンを通じて適用してください。
• 依存関係を正確なバージョンに固定し、記録された整合性ハッシュを含むロックファイルを適用します
• CI環境では、 .npmrc 内の に `ignore-scripts=true` を設定し、 を設定してください。
• サプライチェーン攻撃を、企業全体への侵害につながる前兆として捉えるべきです

セキュリティチームが今、問うべき質問

5月11日以降、影響を受けるバージョンをインストールした開発者やCI環境はありましたか？

もし答えが「はい」であれば、反証されるまでは侵害があったとみなしてください。

実行時に、それらの環境にはどのような秘密が存在していたのでしょうか？

まずは、クラウド、パッケージの公開、ソース管理、およびデプロイメントの識別情報に焦点を当ててください。

ご担当のレポジトリやパッケージのうち、予期せず変更されたり再公開されたりしたものはありませんか？

このキャンペーンは、自発的に広がっていったものです。 お客様の環境は、被害を受けた側であると同時に、感染源でもあった可能性があります。 その場合、お客様の公開用認証情報が、他者のアカウントを乗っ取るために悪用された可能性があります。

エンドポイントからパーシステンスが削除されたことを確認していただけますか？

node_modulesの削除やlockファイルの復元だけで終わらせないでください。

Taniumを活用して、サプライチェーンのリスクを具体的な対応策へと転換する

「Tanium Guardian」（ ）および「」の「Mini Shai-Hulud Supply Chain Compromise」ダッシュボード（ ）は、セキュリティおよびIT運用チームに対し、開発者の攻撃対象領域全体にわたるエンドポイントの状態を、共有されたリアルタイムのビューとして提供します：

• 利用可能な場合はSBOMデータを活用し、影響を受けたnpmおよびPyPIパッケージが実行されている可能性のあるエンドポイントの特定にご協力ください
• Node.js、Python、およびClaude CodeなどのAIツールがインストールされたScopeのエクスポージャー・サーフェシング・マシンを対象とします
• ライブエンドポイントのテレメトリに対して実行される、あらかじめ作成されたクエリを使用して、永続性の指標（LaunchAgents、ユーザーレベルのサービス、IDEやツールの起動フックなど）を探します。
• パッケージレジストリだけでなく、CI/CDランナーの設定や認証情報の露出箇所全体にわたって、クリーンアップの状態を確認してください

Taniumエージェントがすでに導入されている組織では、追加でエージェントを導入することなく、既存のGuardianコンテンツを利用することができます。

対応は、レジストリやリポジトリの審査だけで終わらせてはなりません。 開発者向けエンドポイントやCI/CDランナーも、攻撃経路の一部となっています。 Tanium を利用することで、セキュリティおよび IT 運用担当者は、静的なビルド成果物や遅延を伴う手動チェックに頼ることなく、同じ「現在の状態」ビューから、脆弱性の有無を確認し、残存の除去を検証し、是正措置を調整することができます。

「Mini Shai-Hulud」サプライチェーン攻撃に関するよくある質問

「Mini Shai-Hulud」のようなサプライチェーン攻撃は、 の標準的なインシデント対応マニュアルの枠をはるかに超える疑問を投げかけています。。

以下に、このキャンペーンについてセキュリティチームから寄せられているよくある質問と、それが今後のソフトウェアへの信頼にどのような意味を持つかについてご紹介します。

有効なパッケージの出所情報は、依然として信頼できるのでしょうか？

それでも有用な場合もありますが、完全な安全指標として扱うべきではありません。 出所は、そのものがどこから来たのかを示します。 それは、そのパイプラインが不正に使用されなかったことを証明するものではありません。

チームは盗まれたトークンを直ちに無効にするべきでしょうか？

やみくもにではありません。 破壊的な失効ロジックが関与するインシデントにおいては、対応措置によってさらなる被害を招かないよう、まず隔離と調査を優先すべきです。

多くのチームが依然として見落としている、最も実用的な予防措置とは何でしょうか？

新しくリリースされたパッケージバージョンを導入する前に待機期間を設けることは、特に変化の激しいサプライチェーンの状況に対処する上で、依然として最も簡単かつ効果的な対策の一つです。

このキャンペーンは、開発者以外にもなぜ重要なのでしょうか？

開発者のワークステーションやCI/CDランナーには、クラウドの認証情報、デプロイ権限、パッケージ公開用のIDなどが保存されていることが多いためです。 これらが侵害されると、すぐに組織全体にわたるインシデントへと発展する恐れがあります。

Taniumは、パッケージの露出状況、エンドポイントの状態、永続性の検証、および対応の確認を連携させることで、既存の サプライチェーンセキュリティ への取り組みや管理を補完するように設計されています。これにより、セキュリティ部門とIT運用部門は、同じリアルタイムの状況把握に基づいて対応を行うことが可能になります。
今すぐデモをご予約ください 。TaniumがエンドポイントとID全体にわたってサプライチェーンへの対応をどのように調整するかをご確認ください。