Shai-Huludワーム再来——トロイ化npm経由で“自己公開”させる新手の漏洩、3日で2.5万リポジトリ露出の恐れです

今日の深掘りポイント

• 初期侵入はトロイ化されたnpm依存関係のインストール時スクリプト実行という“開発体験”の盲点を突く手口です。
• 収集されたAWS/GitHubなどの認証情報を、被害ユーザー自身のGitHubリポジトリに公開する“自己公開”型の外部送信で、検知回避と拡散を両立しています。
• 影響は数万単位のリポジトリに及ぶ可能性があり、CI/CDランナーや開発者端末に保存・設定された長期有効なシークレットが焦点です。
• 緊急度は極めて高く、組織横断のトークン失効、CI/CD一時凍結、依存関係のロールバック・検証、監査ログの横断調査が即時アクションになります。
• 供給網攻撃の再演でありつつ、公開先を“GitHub上の自分のリポジトリ”に限定する点が新機軸で、SaaS正規トラフィックの許可ポリシーやDLP/DNS制御をすり抜けやすいです。

はじめに

Shai-Huludワームがnpmエコシステムで再び観測され、インストール時に任意コードを実行するスクリプト機能を悪用して、感染ホスト上の認証情報を収集・公開したと報じられています。報道によれば、攻撃は2025年11月21日ごろから始まり、3日間で2.5万超のGitHubリポジトリに秘密情報が露出した可能性があるとのことです。公開の手段として、被害ユーザー自身のGitHubリポジトリを利用する点が特異で、プラットフォーム側が削除対応する一方、拡散速度が対応を上回る難局となっています。

本稿は、現時点で公開されている報道と提供データに基づく分析で、一次情報が限定的である点を前提に、CISO/SOC/Threat Intel視点での含意と即応策を整理します。

参考: The Registerの報道

深掘り詳細

事実（現時点で確認できること）

• 攻撃はnpmパッケージのトロイ化を起点に、インストール時スクリプト（preinstall/install/postinstall等）で悪意コードを実行させる設計です。
• 感染ホスト上を走査し、環境変数や設定ファイルからAWSやGitHubの認証情報などを収集し、被害ユーザー自身のGitHubリポジトリへ公開します。
• GitHubは影響リポジトリの削除対応を進めていますが、拡散が速く対処が追いつきにくい状況です。
• 影響規模は短期で数万リポジトリに達した可能性があり、CI/CD実行環境を含む広範な漏洩が懸念されます。
• 報道ソース: The Register

インサイト（編集部の見立て）

• “自己公開”の妙手が検知面の難度を上げています。公開先がGitHubの正規ドメインで、かつ自アカウントのリポジトリであれば、社内プロキシの許可リストやDLPのしきいを通過しやすく、SOC側の「通常の開発活動」ノイズに埋もれます。さらに一部のシークレット保護機能はプッシュ前ブロックに依存するため、公開方法によっては回避しうる点が実務上の落とし穴になります。
• npmにおけるインストール時スクリプトは、ビルド・ネイティブ拡張・コード生成など正当用途が多く、全面禁止が難しい運用実情があります。ゆえに“インストール＝コード実行”という供給網リスクは構造的に残存し、攻撃者はメンテナアカウントの乗っ取りやサプライチェーン挿げ替えで広域伝播を狙いやすいです。
• 影響規模の大きさは、被害の「重さ」とは必ずしも一致しません。露出リポジトリ件数は、重複・無効化済み・低感度の情報を含みます。一方で、CIランナーや開発者端末に眠る“古い長寿命キー”ほど漏洩価値が高く、組織の実害はごく少数の高権限キーで決まることが多いです。したがって、単なる件数追跡ではなく「高権限・長寿命・組織横断アクセスのキー」を特定・優先ローテーションすることが重要です。
• 本件は新規性よりも“実効性と即時性”が際立つ事案です。既知の手口の再演ながら、SaaS正規チャネルを介した公開と依存関係の自動更新文化により、封じ込め前に実害が広がりやすいです。現場は、可視化と組織的な強制力（トークン・鍵の一括失効やCI停止判断）を迅速に回す体制が問われます。

脅威シナリオと影響

以下は公開情報に基づく仮説シナリオと、MITRE ATT&CKでの代表的整理です。

• シナリオ1（開発端末経由の横展開）

  • 依存パッケージ更新で悪性スクリプト実行 → 端末上の環境変数/設定からクラウド鍵・GitHubトークン収集 → 自アカウントのGitHub公開リポジトリへアップロード → 盗んだGitHubトークンで当人保有の他リポジトリへ悪意コードをコミット/PR → さらなる依存関係汚染に発展します。
  • 影響: 開発者個人の範囲を超えて組織リポジトリの改ざん、秘匿リポジトリ情報の二次漏洩、パッケージのサプライチェーン汚染が懸念されます。

• シナリオ2（CI/CDランナーでの大量漏洩）

  • CI実行ジョブ内で悪性パッケージが実行 → CI環境変数に注入されたクラウド資格情報や署名鍵が収集 → 公開用リポジトリで“自己公開” → ランナーの短期トークンは寿命制約がある一方、組織・環境シークレットの長寿命キーが狙われます。
  • 影響: 発行済みの長寿命デプロイトークンや署名鍵が流出すると、ビルド偽装や署名チェーン破壊、アーティファクト汚染に直結します。

• シナリオ3（クラウド資源の悪用）

  • 漏洩したAWSキーを用いてクラウドへ不正アクセス → データ窃取や暗号資産マイニング、ログ消去などの活動に移行します。
  • 影響: 短期間でのコスト爆発、データ漏洩インシデント、規制報告義務が発生します。

MITRE ATT&CK（仮説マッピング）

• 初期アクセス: T1195.002（Compromise Software Dependencies and Development Tools）
• 実行: T1059（Command and Scripting Interpreter/Node.js等）, T1204（User Execution）
• 資格情報アクセス: T1552.001（Credentials in Files）, T1552.004（Credentials in Environment Variables）
• 発見: T1082（System Information Discovery）, T1083（File and Directory Discovery）
• 防御回避/コマンド&制御: 正規SaaS（GitHub）経由の通信に偽装
• 流出: T1567（Exfiltration to Cloud Storage or Web Services）, T1041（Exfiltration Over Web Services）
• 横移動/権限濫用: T1078（Valid Accounts）によるリポジトリ改ざんやパッケージ再配布

リスクの実務的重み

• “件数の大きさ”より“キーの質”が被害規模を左右します。長寿命・広権限・組織横断アクセスの鍵を最優先で無効化・再発行すべきです。
• GitHub側の削除が進んでも、外部クローン・ミラー・キャッシュに残存する可能性があり、完全な抹消は期待できません。公開されたものは既に失効前提で扱うべきです。
• SaaS正規先への通信はネットワーク監視の盲点になりやすく、EDR/プロセス相関・SaaS監査ログを合わせた多層検知が必要です。

セキュリティ担当者のアクション

即時（24〜72時間）

• 依存関係の凍結・見直し
  • 直近の依存更新を停止し、ロックファイルを攻撃開始前の安全な時点までロールバックします。
  • CIでは一時的に“インストール時スクリプト無効化”（例: npm系は --ignore-scripts 相当）を有効にしてビルド可否を確認します。
• トークン・鍵の緊急ローテーション
  • GitHub: 個人アクセストークン（特にclassic型）とデプロイトークンを一括棚卸し・失効し、Fine-grained PATへ置換します。組織シークレットもローテーションします。
  • クラウド（AWS等）: 長寿命アクセスキーを失効・最小権限で再発行し、未使用キーを削除します。重要ロールの一時停止も検討します。
  • npm: メンテナアカウントのセッション失効とトークン再発行、二段階認証の強制を実施します。
• 監査ログ・秘匿情報の横断調査
  • GitHub監査ログで「新規公開リポジトリ作成」「短時間での大量push」「見慣れない端末/ASNからの認証」を時系列で確認します。
  • 公開リポジトリの履歴にシークレット文字列（例: プレフィックス、鍵フォーマット、PATパターン）が含まれていないかスキャンし、見つかれば即時失効します。
  • CIランナー実行ログから、npm install直後に対外通信（api.github.com等）が発生していないかを相関分析します。
• エンドポイント封じ込め
  • 攻撃期間中にnpmインストールを実行した開発端末・ランナーを優先隔離し、EDRでNode/npm子プロセスのネットワーク通信痕跡をハンティングします。

短期（1〜2週間）

• 供給網ガードレール
  • 社内レジストリ/プロキシ（隔離・検疫）経由でのみ外部パッケージを取得するフローに切替え、インストール時スクリプトをサンドボックス評価後に許可します。
  • 依存更新の承認制・差分レビュー（依存グラフ差分、スクリプト有無、メンテナ変化、リポジトリ移管の検知）をパイプライン化します。
• 検知強化
  • SIEMで「npm|node実行直後のapi.github.com通信」「新規public repo作成イベント」「短期間の大量コミット」をルール化します。
  • EDRで“npmの子プロセスによるシェル実行/外部通信”を行動検知します。
• 認証の衛生
  • 長寿命静的キーを段階的に廃止し、OIDC/短期STSへの移行を加速します。GitHubではclassic PATの全面ブロックを検討します。

中期（四半期）

• アーキテクチャ・ガバナンス
  • “インストール＝コード実行”の設計リスクを前提に、最小権限の開発環境、使い捨てランナー/端末、リソース分離（組織/環境/権限）をデフォルトにします。
  • 依存パッケージのセキュリティ評価（メンテナ信頼、更新頻度、スクリプト使用、OpenSSF Scorecard等）をゲートに組み込みます。
• 演習と緊急停止手順
  • サプライチェーン汚染を想定したレッドチーム演習を実施し、組織横断の“依存停止・トークン一括失効・CI凍結”のプレイブックを検証・短縮します。

メトリクスに対する総合的見立て

• 本件は緊急性・実行可能性・発生確度が高く、意思決定を遅らせる理由が乏しいです。一方で、技術的な新規性は限定的で、既存のサプライチェーン対策を“組織的強制力”でどこまで徹底できるかが成否を分けます。特に、トークン衛生（短期化・最小権限・集中失効）と、依存関係の検疫・可視化を“恒常運用”に落とし込めるかが勝負どころです。

参考情報

• The Register: Shai-Hulud npm worm resurfaces, secrets published to GitHub (2025-11-24)