Shai-Hulud 2.0：796個のパッケージに感染した自己増殖型npmワーム
緊急セキュリティ警告 2025年11月24日、セキュリティ研究者は週間2,000万件を超えるダウンロード数を持つ796個のnpmパッケージを侵害した、高度な自己増殖型ワームを特定した。開発ワークフローでnpmパッケージを使用している場合、これをすぐに読む必要がある。
npmエコシステムは、これまでで最も高度なサプライチェーン攻撃の一つを経験した。セキュリティコミュニティによって「Shai-Hulud 2.0」と名付けられたこの自己増殖型ワームは、何百もの正規パッケージに首尾よく侵入し、認証情報を盗み、バックドアを設置し、一元管理されたコマンド・アンド・コントロール基盤なしに自己増殖している。
この攻撃が特に危険なのは、その自律的な性質だ——一度感染すると、マルウェアは自動的に他のパッケージに拡散でき、npmエコシステム全体にカスケード効果を生み出す。ここに、開発者とセキュリティチームがこの脅威について知っておくべきことすべてをまとめた。
Shai-Hulud 2.0とは何か？
Shai-Hulud 2.0は、2025年9月に最初に発見された自己増殖型npmワームの第2バージョンだ。攻撃者が制御するサーバーとの継続的な通信を必要とする従来のマルウェアとは異なり、このワームはシステムに感染した後、自律的に動作するよう設計されている。
この攻撃は、2つの悪意あるファイルを正規のnpmパッケージに注入することで機能する：
setup_bun.js- 初期感染ベクターbun_environment.js- 難読化されたペイロード
これらのファイルは、感染したパッケージを誰かがインストールするたびに実行される悪意ある preinstall スクリプトによって自動的にトリガーされる。何かがおかしいと気づいた時には、すでに被害が発生していることがある。
攻撃の規模
この攻撃の背後にある数字は驚異的だ：
感染したnpmパッケージ
影響を受けた週間ダウンロード数
侵害されたGitHubユーザー
これらの数字は、公開されているデータに基づく下限値を示している。実際の影響はおそらくかなり高く、多くの侵害された認証情報がまだ発見されていない可能性がある。この攻撃は150以上の独立したGitHub組織にわたる開発者に影響を与え、広範な企業への露出を示している。
攻撃の仕組み：技術的な内訳
攻撃メカニズムを理解することは、検知と防止の両方にとって非常に重要だ。マルウェアは5つの明確な段階で動作する：
ステージ1：Bunランタイムによる回避
マルウェアが用いる最初の巧妙な手口は、Node.jsの代わりにBun JavaScriptランタイムをインストールして使用することだ。これには2つの目的がある：
- Node.jsのプロセスを監視するよう特別に設定されたセキュリティ監視ツールを回避する
- サンドボックス化やコンテナ化の対策を回避する可能性がある、新しい実行環境を提供する
Bunがインストールされると、マルウェアはそれを使って静的に解析するのが困難な、大量に難読化されたペイロードを実行する。
ステージ2：包括的な認証情報の収集
マルウェアがその洗練さを示すのはここだ。単に明白な認証情報ファイルを探すのではなく——できるだけ多くの秘密情報を盗むための多面的なアプローチを実装している：
狙われる認証情報のソース：
- ローカルファイルシステム：
.config/gcloud/application_default_credentials.jsonや.aws/credentialsなど、既知の認証情報ファイルをスキャンする - 能動的な秘密情報の探索： Trufflehogをダウンロードして実行し、ファイルシステム全体で秘密情報を積極的に探索する -クラウドメタデータサービス： AWS、Azure、Google Cloudのインスタンスメタデータエンドポイントに問い合わせて一時的なワークロード認証情報を盗む -クラウドの秘密情報ストア： AWS Secrets Manager、Azure Key Vault、Google Cloud Secret Managerにアクセスして保存されている秘密情報を取得する
- 環境変数： APIキーやトークンをしばしば含むすべての環境変数を取得する
この包括的なアプローチは、開発者のノートPC、CI/CDパイプライン、あるいはクラウドベースのサーバーレス機能のいずれで実行していても、マルウェアがおそらく認証情報を見つけ出し、盗み出せることを意味している。
ステージ3：ひと工夫加えたGitHubベースの流出
流出のメカニズムは特に興味深い。マルウェアの主要な手法は、被害者から盗んだGitHubの認証情報を使って新しい公開GitHubリポジトリを作成することだ。このリポジトリには特徴的なマーカーがある——「Sha1-Hulud: The Second Coming」という説明文だ。
しかしここが巧妙な部分だ：マルウェアが感染したマシン上でGitHubの認証情報を見つけられなかった場合、それは諦めない。代わりに、GitHub上でその同じ特徴的な説明文を持つ他のリポジトリを検索し、それらのリポジトリから認証情報を盗んで自らの流出に利用する。
重要な含意： これは、あなたの盗まれた認証情報が、まったく別のGitHubアカウントの下で流出する可能性があることを意味し、検知を著しく難しくする。単一のGitHubユーザーのアカウントに、複数の無関係な被害者からのデータが含まれる可能性がある。
ステージ4：持続的アクセスのためのセルフホスト型GitHubランナー
侵害されたマシンへの持続的アクセスを維持するため、マルウェアはセルフホスト型のGitHub Actionsランナーを設定する。これは特に悪質だ、理由は：
- 正規のGitHubインフラを使用しているため、悪意あるトラフィックとして検知することが難しくなる
- 攻撃者がGitHubの本来のワークフロー機能を使って被害者のマシン上で任意のコードを実行できるようになる
- インバウンドのファイアウォールポートを開いたり、リバースシェルを確立する必要がない
- セキュリティチームがこれを正規のDevOps自動化として見過ごす可能性がある
ステージ5：自律的な自己拡散
これが、Shai-Hulud 2.0を単なるマルウェアではなく真のワームにしている要因だ。一度開発者のマシンを侵害し、npmの認証情報を盗んだ後、自動的に：
- その開発者が公開した最大100個のパッケージを特定する
- 感染したパッケージから自身の悪意あるコードを読み取る（C&Cサーバーは不要！）
- そのコードを被害者の他のパッケージに注入する
- これらのパッケージの新しいバージョンをnpmに公開する
この自己増殖は攻撃者の介入なしに自動的に発生し、ワームがnpmエコシステム全体で指数関数的に拡散することを可能にしている。
最終手段：データ破壊 マルウェアが自己増殖にも流出にも失敗した場合、焦土戦術のフォールバックがある：ユーザーのホームディレクトリ全体を削除しようと試みる。この破壊的な挙動は、攻撃者がアクセスを維持することよりも自らの痕跡を消すことを優先していることを示唆している。
自分が影響を受けているかを確認する方法
早期発見が極めて重要だ。ただちに確認すべき重要な侵害の指標（IOC）は以下の通りだ：
直ちに取るべき行動：
- node_modules内の悪意あるファイルを確認する： 特に疑わしいpreinstallスクリプトと組み合わされている場合、
setup_bun.jsまたはbun_environment.jsを含むパッケージを検索する。 2.流出用リポジトリをGitHubで検索する： 組織のGitHubアカウント下で「Sha1-Hulud: The Second Coming」という説明文を持つリポジトリを探す。これらにはあなたの盗まれた認証情報が含まれている。 3.予期しないGitHubランナーを確認する： 組織のセルフホスト型ランナーを確認し、意図せず設定されたものがないか確認する。 4.最近のパッケージ更新を確認する： npmパッケージをメンテナンスしている場合、特に2025年11月24日前後で、自分の知らないうちに更新されたものがないか確認する。 5.クラウドのアクセスログを確認する： AWS CloudTrail、Azureアクティビティログ、Google Cloud監査ログを確認し、秘密情報管理サービスやメタデータサービスへの異常なAPIコールがないか確認する。
侵害された場合の即時対応手順
影響を受けたことが発覚した場合、時間との勝負だ。次の手順を順番に実行する：
緊急対応チェックリスト：
- すべての認証情報を即座にローテーションする： GitHubトークン、npmトークン、AWSキー、Azure認証情報、GCPサービスアカウント、その他露出した可能性のある秘密情報がすべて含まれる。
2.侵害されたnpmトークンを取り消す： npmjs.comにログインし、すべての認証トークンを取り消してから、新しいトークンを生成する。 3.** 感染したパッケージを非公開または非推奨にする： **自分のパッケージにバックドアが仕込まれた場合、直ちに最近のバージョンを非公開にするか、セキュリティ警告付きで非推奨としてマークする。
4.セルフホスト型GitHubランナーを削除する： 組織のGitHubから、許可されていないセルフホスト型ランナーをすべて削除する。 5.流出用リポジトリを削除する：「Sha1-Hulud: The Second Coming」という説明文を持つGitHubリポジトリをすべて削除する。
6.すべてのシステムをスキャンする： 感染したパッケージをインストールした可能性のあるマシンで、包括的なマルウェアスキャンを実行する。 7.関係者に通知する： 他者が使用するパッケージをメンテナンスしている場合、侵害を公に開示し、ユーザーに更新を促す。
長期的な防止戦略
将来のサプライチェーン攻撃を防ぐには、多層的なセキュリティアプローチが必要だ：
依存関係の管理
- ロックファイルを使用し、パッケージの整合性を検証する
- CI/CDパイプラインに依存関係スキャンを実装する
- 依存関係を定期的に監査し最小化する
- 範囲指定ではなく特定のバージョンをピン留めする
ランタイムセキュリティ
- 予期しないプロセス実行（Bunなど）を監視する
- ネットワークの送信フィルタリングを実装する
- パッケージのインストールにサンドボックス化された環境を使用する
- すべてのパッケージ操作に対する監査ログを有効にする
認証情報の管理
- 認証情報を平文のファイルに保存しない
- 最小限の権限を持つ短命なトークンを使用する
- 秘密情報のローテーションポリシーを実装する
- 秘密情報ストアへの不正アクセスを監視する
モニタリングと検知
- 異常なGitHubの活動に対してアラートを設定する
- 自分のパッケージのnpm公開イベントを監視する
- クラウド環境でのメタデータサービスへのアクセスを追跡する
- 異常検知のための行動分析を実装する
大きな視点：2025年のサプライチェーンセキュリティ
Shai-Hulud 2.0の攻撃は、サプライチェーンの脅威における大きな進化を表している。タイポスクワッティングやソーシャルエンジニアリングを利用して悪意あるパッケージを公開させていた以前の攻撃とは異なり、このワームは開発者がすでに使用している正規の、信頼されているパッケージを侵害する。
特に懸念されるのは、この攻撃の自律的な性質だ。従来のマルウェアキャンペーンは攻撃者の継続的な関与を必要とするが、自己増殖型ワームは人間の介入なしに指数関数的に拡散できる。一度放たれると、完全に抑え込むことはほぼ不可能になる。
npmエコシステムの対応は迅速だった——証拠によると、npmは2025年11月24日UTC午後6時頃、さらなるパッケージ感染を防ぐための対策を実装した。しかし、すでに感染したパッケージによる被害の修復には、開発者が依存関係を更新し、侵害された認証情報をローテーションするのに数か月かかるだろう。
開発チームへの重要な教訓：
-信頼は二元的なものではない： 信頼されているメンテナーからのパッケージでも侵害される可能性がある。深層防御戦略を実装しよう。 -インストールは実行である： パッケージのインストールスクリプトは任意のコードを実行できる。npm installをセキュリティに関わる操作として扱おう。 -認証情報は最も重要な資産だ： 適切な認証情報管理は任意ではない——それは、抑え込まれたインシデントと壊滅的な侵害との違いを分ける。 -モニタリングが命を救う： この攻撃を早期に検知した組織は、強固なモニタリング体制を備えていた。可観測性への投資を行おう。
結論：進化する脅威の状況に警戒を続ける
Shai-Hulud 2.0ワームは、JavaScriptエコシステム全体への警鐘だ。796個のパッケージが侵害され、週間2,000万件を超えるダウンロードが影響を受けたことは、サプライチェーンセキュリティがもはや後回しにできないことを示している。
良いニュースは、セキュリティコミュニティが迅速に対応し、npmが拡散を抑えるための対策を講じたことだ。悪いニュースは、これがこの種の最後の攻撃にはならないということだ。パッケージエコシステムが成長し、相互に接続されるほど、高度な攻撃者にとってますます魅力的な標的になる。
レジリエンスの鍵は、すべての攻撃を防ぐことではない——それは不可能だ。代わりに、侵害を迅速に検知し、被害を効果的に抑え込み、迅速に復旧できるシステムを構築することだ。今日サプライチェーンセキュリティに投資する組織が、明日避けられない攻撃を生き延びる組織となる。
最新情報を入手する
これは継続中のインシデントだ。セキュリティ研究者は、新たに影響を受けたパッケージと侵害の指標を発見し続けている。npmのセキュリティアドバイザリを確認し、SNSでセキュリティ研究者をフォローして最新情報を得よう。
