Shai-Huludによるnpmサプライチェーン攻撃とは何か？その全貌と最新動向を徹底解説【警戒必須】

Shai-Huludによるnpmサプライチェーン攻撃とは何か？その全貌と最新動向を徹底解説【警戒必須】

2025年9月中旬、JavaScriptのパッケージ管理システムnpmを舞台に、新種のサプライチェーン攻撃が発生しました。攻撃者が仕掛けたマルウェアは「Shai-Hulud」（シャイ・フルード）と名付けられ、瞬く間に多数のパッケージに感染して大きな被害を及ぼしました。Shai-Huludは自己増殖型のワームのように振る舞い、被害を拡大させるという点で、従来の攻撃とは一線を画しています。この記事では、Shai-Hulud攻撃の概要から技術的な詳細、被害状況とリスク、さらに対策方法に至るまで、最新情報を網羅的に解説します。

本攻撃は、多くの開発者や企業が信頼するnpmエコシステムを直撃しました。そのため、ソフトウェア開発に関わる組織にとって警戒必須の重大インシデントと位置付けられています。以下では、攻撃の名称の由来や背景に触れつつ、Shai-Huludがもたらす脅威について詳しく見ていきます。

攻撃名「Shai-Hulud」の意味: 巨大ワームに由来する命名と狙いから読み解く攻撃者の意図

「Shai-Hulud」という名称は、SF小説『デューン』に登場する巨大な砂漠のワームに由来しています。攻撃者はこの名前をGitHub上でデータを保存するリポジトリ名として使用しており、セキュリティ研究者の間でも本マルウェアの呼称として定着しました。巨大なワームになぞらえた命名は、このマルウェアが蠕虫（ワーム）型で自己増殖する性質を持つことを示唆していると考えられます。実際、Shai-Huludは一度侵入するとまるで砂漠の巨神のように開発環境内を動き回り、得た資源を用いて次々と新たな標的に広がっていきます。

攻撃者がこの名前を敢えて付けた背景には、自身のマルウェアのワーム的な威力を誇示するとともに、検知を遅らせる狙いもあったのではないかと推察されます。一般に「ワーム」という言葉は脅威の深刻さを連想させますが、開発者が当初これを見落としてしまえば、攻撃者にとって有利に働きます。結果としてShai-Huludは、その名が示す通りnpmエコシステムに潜み広がる厄介な“砂漠の巨虫”となったのです。

前例との比較: Shai-Hulud攻撃が示すソフトウェアサプライチェーンの新たな脅威レベル

Shai-Hulud攻撃は、直前に発生していたいくつかのnpm関連インシデントを上回る深刻な脅威と評価されています。たとえば、2025年8月末には「Nx」フレームワークのパッケージが1件侵害され、トークンが盗まれる事件（通称S1ngularity攻撃）が発生しました。また9月上旬には有名ライブラリ「chalk」「debug」など18のパッケージが改ざんされて仮想通貨を狙うマルウェアが仕込まれる事件も起きています。しかし、これらはいずれも単発的または限定的な攻撃でした。

それに対しShai-Huludは、過去の事例と比べ規模・手口の両面で段違いです。一度の攻撃キャンペーンで180以上ものパッケージを連鎖的に汚染し、自動的に次の標的へと感染を広げる自己増殖能力を備えていました。これは従来の「一度侵入すれば終わり」タイプのサプライチェーン攻撃を大きく進化させたものです。セキュリティ専門家は、Shai-Huludを「npm史上初の本格的なワーム攻撃」と位置づけており、オープンソースソフトウェア供給網の脆弱性が改めて浮き彫りになりました。

さらに、攻撃手法にAIの利用が示唆される点（後述）や、被害規模の大きさから、本件はソフトウェアサプライチェーン全体に警鐘を鳴らす出来事となっています。これまでの対策では不十分である可能性があり、新たな防御モデル（ゼロトラストなど）の重要性が強調されています。

Shai-Hulud攻撃の概要: npmエコシステムへの影響と発覚の経緯、そして攻撃手法の全体像を解説

それでは、Shai-Hulud攻撃の具体的な概要について見ていきましょう。本節では、攻撃がどのように発覚したのか、npmエコシステムにどんな影響を与えたのか、そして攻撃全体の流れを概観します。

初期の発覚状況: @ctrl/tinycolor改ざんにより浮上した攻撃の兆候とコミュニティの初期対応

攻撃の兆候が最初に明るみに出たのは、2025年9月15日前後のことでした。npmで広く使われている人気パッケージ「@ctrl/tinycolor」に、不審な新バージョンが公開されているのが発見されたのです。開発コミュニティのユーザーが、このパッケージをアップデートした際に挙動のおかしさに気付き、SNSやIssueトラッカー上で報告したことがきっかけでした。

具体的には、@ctrl/tinycolorの改ざん版では、インストール時に不審なスクリプトが実行され、環境変数などにアクセスしようとする動きが確認されました。これを受けてnpmの管理者およびセキュリティ研究者が調査を開始。攻撃の第一報から間もなく、問題のバージョンはnpmレジストリから取り下げられるなど、初期対応が取られました。しかし、当初は単一のパッケージの問題と見られていたものが、実はより大規模な攻撃キャンペーンの氷山の一角であることが徐々に判明していきます。

被害範囲の拡大: 短期間で180以上のパッケージに感染し急速に広がった経緯とそのインパクトを検証・分析（数日で急拡大）

@ctrl/tinycolorの事件を糸口に調査を進めた結果、攻撃の被害範囲が想像以上に広いことが明らかになりました。最初は数十個程度と推測されていた改ざんパッケージが、その後の解析で次々と追加で見つかり、最終的には180以上のパッケージが感染していたことが確認されたのです。僅か数日のうちに被害パッケージ数が雪だるま式に増えていった様子から、セキュリティ研究者らは当初から「これは通常のマルウェア感染ではなくワーム的な自己増殖が起きている」と警鐘を鳴らしました。

この短期間での急拡大により、npmエコシステム全体へのインパクトも甚大でした。汚染されたパッケージの中には開発者に広く利用されているライブラリも多く含まれていたため、直接的な被害を受けた開発者・組織はもちろん、その依存関係にある無数のプロジェクトにも潜在的な危険が及びました。幸い、コミュニティによる迅速な情報共有とnpm側の対処によって多くの悪意あるバージョンは公開停止となりましたが、攻撃開始から対策までの短い間にも相当数の開発環境が一時的に侵害された可能性があります。今回のように被害範囲が瞬く間に広がるケースは前例が少なく、オープンソースコミュニティに大きな衝撃を与えました。

攻撃の全体像: 認証情報窃取と自己増殖が組み合わさった多段階ワーム攻撃の全容【多段階攻撃】

Shai-Hulud攻撃は、単純なデータ窃取に留まらず、複数の段階を経て被害を拡大する巧妙なサプライチェーン攻撃です。その全体像をまとめると次のようになります。まず、開発者が汚染されたnpmパッケージをインストールすると、仕込まれたマルウェアが発動し、開発環境からトークンやAPIキーなどの秘密情報をこっそり収集します。次に、それら窃取した認証情報を攻撃者が管理する外部へと送信・公開します。その過程で、GitHubリポジトリを利用した巧妙なデータ送信（後述）や、被害者のGitHub権限を悪用した裏工作（悪性ワークフローの追加など）が行われます。

そして極めつけは、盗んだnpm発行権限（トークン）を用いて新たなパッケージへ自己増殖する段階です。つまり、一人の開発者が侵害されると、その開発者が管理する他のnpmパッケージにもマルウェアが自動的に注入・公開され、被害が伝播します。このようにShai-Huludは、「侵入→窃取→拡散」というサイクルを自律的に回す初の事例であり、まさに多段階にわたるワーム攻撃として成立しています。以下では、この攻撃フローの各段階を技術的に詳しく見ていきましょう。

侵害の流れと拡大ロジック: 自己増殖ワームの技術的な仕組みと感染経路を徹底解明、被害拡大のメカニズムを分析

Shai-Huludマルウェアがどのように侵入し、情報を盗み、さらに次の犠牲者へ広がっていくのか、その詳しい流れを順を追って解説します。複雑に見える攻撃ですが、いくつかのステップに分解して考えると理解しやすくなります。

感染の初動: 悪質なnpmパッケージをインストールした際に起こること（初期侵入ベクターの分析）

Shai-Hulud攻撃の第一段階は、開発者が悪意あるnpmパッケージをインストールしてしまう瞬間に始まります。攻撃者は予め複数の正規パッケージのバージョンを乗っ取って改ざんしており、開発者がそれらをアップデートまたは新規インストールすると、npmのインストールスクリプト（postinstallなど）を通じてマルウェアが仕掛けられます。具体的には、改ざんパッケージ内に組み込まれた悪性のJavaScriptコード（後述するbundle.js）が自動実行され、開発マシン上で攻撃の準備を開始します。

初動でまず行われるのは、環境調査と攻撃に必要な外部ツールの用意です。Shai-Huludのコードは、感染先の環境がLinux系かWindows系かをチェックし（Linux/Unix環境でのみフル機能を実行）、必要に応じて悪用するユーティリティ（例: シークレットスキャンツール）をロードします。この段階は攻撃全体の「初期侵入ベクター」にあたり、開発者に気付かれずにマルウェアの活動基盤を確立する重要なフェーズです。例えば、何も表示せず静かに進行するためユーザーは異常に気付かないことがほとんどで、この間に攻撃者は次の窃取ステップに備えます。

秘密情報の収集ステップ: TruffleHogによるトークン・鍵のスキャン【秘密情報収集】

感染直後、Shai-Huludはターゲット環境内のあらゆる機密情報を探し出す動作に入ります。ここで鍵となるのが、攻撃コードに組み込まれたTruffleHogというオープンソースのシークレット検出ツールです。マルウェアはTruffleHogの機能を活用し、システム内をスキャンして秘密鍵やトークン、パスワードといった文字列を効率的に抽出します。

具体的には、ユーザーのホームディレクトリやプロジェクトディレクトリ配下に保存された設定ファイル（.npmrcファイルに含まれるnpmアクセストークン、.envファイルの環境変数、構成ファイル中のAPIキーなど）を幅広くチェックします。また、SSHキーやクラウドサービスの認証情報が保存されている既知のパスも調査対象です。TruffleHogにより数多くの種類のシークレットが一斉に洗い出され、攻撃者は開発環境から取得しうる最大限の認証情報を手中に収めようとします。

さらにShai-Huludは、クラウド環境ならではの情報源にもアクセスします。後述するようにクラウドメタデータサービスへの問い合わせを行い、AWSやGCPの一時認証キーやトークンを取得することもできます。つまり、このステップで開発マシンおよびその実行環境に存在するあらゆる秘密情報が漏洩の対象となるのです。

データの外部送信: 公開GitHubリポジトリ『Shai-Hulud』への機密データのアップロード【データ漏洩】

収集した認証情報は、次に攻撃者の手元に送られます。Shai-Huludがユニークなのは、そのデータ送信にGitHubを悪用する点です。マルウェアはまず被害者（開発者）のGitHubアカウント上に、新たに「Shai-Hulud」という名前の公開リポジトリを自動作成します。次に、収集した全てのシークレット類をひとまとめにしたJSON形式のファイル（例: data.json）をこのリポジトリにコミットし、誰もが閲覧可能な状態で公開してしまいます。

この手口により、攻撃者は情報を自分のサーバーに直接送信することなくGitHub上で受け取ることができます。GitHubは多くの企業で信頼された通信先であり、社内のセキュリティ監視にも引っかかりにくいという利点があります。ただし、ファイルとして公開されたシークレットは第三者にも見られてしまうため、早期に発覚しやすい側面もあります。実際に今回の攻撃でも、複数の開発者アカウントに「Shai-Hulud」という見慣れないリポジトリが現れ、そこに意味不明なデータ（base64で二重にエンコードされたJSON）が置かれていたことがコミュニティによって検知されています。

なお、Shai-HuludはGitHubリポジトリへの公開以外にも、Webhookサイトへの送信でデータを外部流出させる仕組みを持っていました。攻撃コード中には特定のWebhook URL（https://webhook.site/～）が含まれており、GitHub Actionsワークフロー経由でそこにシークレットをPOSTする処理が仕込まれていたのです。ただし、このWebhookサービスは無料プランの制限で送信回数に上限があり、攻撃途中で無効化されていたことが確認されています。いずれにせよ、この段階で被害者のあらゆる機密情報が攻撃者側に漏洩したことになります。

GitHub Actionsを使った継続的な情報流出: 悪意あるワークフローの仕組み【ワークフロー悪用】

Shai-Huludは、一度きりの情報窃取に留まらず、継続的かつ自動的に秘密情報を抜き取り続けるための罠をしかけます。それが、被害者のGitHubリポジトリに追加される悪意あるGitHub Actionsワークフローです。

攻撃コードは、被害者がアクセス可能なGitHub上のすべてのリポジトリを取得し、それらに対して一つずつ新規ブランチshai-huludを作成していきます。そして各ブランチに、悪性のワークフローファイル（.github/workflows/shai-hulud-workflow.yml）を追加します。このYAML定義には、リポジトリ内のシークレット（GitHubがリポジトリ単位で保持する各種秘密情報）を取得してWebhookに送信する処理や、取得したデータをActionsのログにエンコードして書き出す処理などが書かれています。さらに攻撃コードは、自動でプルリクエストを発行し、この悪性ワークフローをリポジトリのデフォルトブランチにマージさせようと試みます。

このワークフローがマージされ有効化されてしまうと、そのリポジトリでは次に何らかのプッシュ（コミット）イベントが発生した際に、攻撃者の仕込んだシークレット収集処理が実行されてしまいます。つまり、被害者の組織内リポジトリに持続的な「バックドア」が設置されるようなものです。今回の攻撃では実際に複数のGitHubリポジトリが不正なワークフローを取り込んでしまい、その結果これらのリポジトリからもシークレットが漏洩したことが確認されています。GitHub Actionsを悪用するこの手法は、被害者自身のCI環境を使って情報を抜き続けるという点で極めて巧妙です。

自己増殖の段階: 被害者のnpmトークンを悪用したパッケージ汚染の拡散【ワーム拡散】

Shai-Hulud攻撃の最大の特徴が、この自己増殖（ワーム）機能です。攻撃コードは、被害者から盗んだnpmのアクセストークン（publishing token）を利用して、その被害者が保守している他のnpmパッケージに不正なコードを注入し、新たな悪意あるバージョンをリリースします。

例えば、ある開発者AがパッケージXとYのメンテナー権限を持っていたとします。開発者Aの環境がShai-Huludに侵害されると、盗まれたAのnpmトークンを使ってパッケージXおよびYに攻撃者が勝手に改変を加えた新バージョンが公開されてしまう恐れがあります。こうして汚染パッケージの数がドミノ式に増えていき、攻撃開始から数日で180以上ものパッケージが連鎖感染する結果を招きました。まさにワームウイルスの如く、被害者を次の加害者（感染元）に仕立てて広がる恐るべきロジックです。

なお、攻撃者はこうした自動リリースの中でパッケージ名やバージョン番号をさりげなく更新しつつ、悪性コードを埋め込んでいます。多くの場合、改ざんはバージョンのマイナーアップデートやパッチアップデートに偽装されており、利用者が普段と変わらず依存関係を更新すると侵入を許してしまう構図です。この自己増殖段階によって、当初一人の開発者を狙った攻撃が、npm全体に大規模なサプライチェーンリスクを及ぼす事態となりました。

プライベートリポジトリの公開: 攻撃者によるリポジトリ乗っ取りと情報曝露【リポジトリ強制公開】

Shai-Hulud攻撃では、被害者のGitHub資産に対してもう一つ、悪質な操作が行われました。それは、プライベートリポジトリの強制的な公開です。攻撃コードは、被害者が所属する組織のプライベートリポジトリにアクセスできる場合、それらを攻撃者の個人アカウント配下にクローンし、新規リポジトリとして復元する動きを見せます。

具体的には、先のワークフロー設置の過程で、攻撃者は「リポジトリ移行用」のシェルスクリプトも一緒にドロップしています。このスクリプトを実行すると、組織のプライベートリポジトリを攻撃者側の新規リポジトリにプライベート状態で複製し、直後にその可視性をpublic（公開）に切り替えます。結果、もともと非公開であったソースコードやプロジェクトデータが、攻撃者の公開リポジトリ上で丸見えになってしまうのです。実行ログにはリポジトリのCreateEvent（新規作成）とPublicEvent（公開化）の2つのイベントが短時間のうちに連続して記録されるため、外部からもこの異常な公開操作を検知できます。

現時点で確認されている限り、数名の被害者開発者が所属する組織で、実際にこのプライベート→パブリック化が行われてしまいました。結果として、これらの組織は内部コードを一時的に流出させられる被害を受けています。攻撃者の意図は、おそらく内部情報の暴露と同時に、公開されたリポジトリに残るシークレットなども引き出すことにあったと考えられます。このようにShai-Huludは、個人の開発環境だけでなく組織の知的財産にも損害を与える厄介な手口を盛り込んでいました。

主要な侵害パッケージと被害規模: npm上の180以上のパッケージに及ぶ影響範囲と被害状況の徹底分析と考察

Shai-Hulud攻撃によって侵害されたパッケージの種類や数、その影響範囲について分析します。ここでは、被害に遭った主なパッケージの例、全体のパッケージ数とスケール、流出した情報量、そしてそれらがユーザーや組織にもたらす影響について考察します。

感染が確認された主なパッケージ: @ctrl/tinycolorを含む有力ライブラリの被害【例】

今回の攻撃では、オープンソースから企業製まで様々なパッケージが標的となりました。前述の@ctrl/tinycolor（色操作ライブラリ）は週あたり数百万回以上ダウンロードされる人気パッケージであり、その改ざんは大きな波紋を呼びました。他にも、攻撃初期に明らかになった約40個のパッケージには、フロントエンド開発で広く使われるツールや、一部著名企業が公開しているパッケージも含まれていました。

さらに続報で判明した残りのパッケージ群には、特定個人のユーティリティ的な小規模パッケージから、組織が管理する内部向けモジュールまで多岐にわたります。中にはセキュリティ企業CrowdStrikeのnpmパッケージも含まれていたとの報告があり、攻撃者が狙いを定めた範囲が非常に広いことが窺えます。要するに、著名・無名を問わず「公開されていて攻撃者がアクセス権を得られたnpmパッケージ」は軒並み悪用された可能性が高いのです。これら有力ライブラリへの被害は、それを利用する開発者へ波及するため、攻撃の影響力を格段に高めることになりました。

被害パッケージ数と範囲: 180以上に及ぶ汚染されたパッケージ群の全容と影響範囲を詳細分析【統計データ】

最終的に明らかになった汚染パッケージの総数は180を優に超えました。これは、オープンソースのサプライチェーン攻撃として過去最大級の規模です。攻撃キャンペーンの初動で約40、そこから数日でさらに140以上が次々と判明し、合計180+という数字に達しました。このうちには前述のように様々な種類のパッケージが含まれますが、興味深い点として「波及元」となったいくつかの初期感染パッケージが特定されています。

攻撃者が最初にターゲットとしたのは、8月末に起きたNxプロジェクトのトークン流出事件（S1ngularity攻撃）の被害者パッケージだった可能性が指摘されています。それらの管理者権限を悪用してShai-Hulud攻撃の第一波が仕掛けられ、そこから二次・三次感染へと広がったと推測されています。この点からも、攻撃者が事前に前哨戦とも言える別の攻撃で足がかりを作っていたことが示唆されます。

180以上もの汚染パッケージは、npm全体から見れば割合として大きくはないものの、ダウンロード数ベースで見ると非常に幅広いユーザー層に影響しました。例えば上位のchalkやdebugのような人気パッケージが仮に含まれていれば、その利用プロジェクトは数百万以上にもなります（今回はchalk等の事件は別件でしたが、Shai-Huludも複数の広く使われるライブラリに及びました）。つまり、180のパッケージの背後には無数のエンドプロジェクトが存在し、その全てが攻撃の潜在的な被害者となり得たのです。この範囲の広さが、本攻撃の深刻さを物語っています。

公開された機密情報の規模: 漏洩したシークレット件数とGitHub上の痕跡の分析結果【流出量】

Shai-Hulud攻撃によって外部に漏洩した機密情報の量も驚くべきものでした。攻撃者が作成した各開発者アカウント上の「Shai-Hulud」リポジトリには、少なくとも数十人規模の開発者から収集したシークレットが格納されていたと報告されています。具体的には、Wizの調査によれば36人のGitHubユーザーの機密情報が「data.json」に含まれて公開されていたとのことです。また8人のユーザーではプライベートリポジトリが強制公開され、そこにもシークレットが含まれていました。

加えて、GitHub Actionsの悪性ワークフローによって各リポジトリのシークレットも漏洩しましたが、これらはWebhookサイトが停止した後はGitHub上のActionsログに残留する形となりました。研究者はそうした痕跡を追跡し、少なくとも64のリポジトリにshai-huludブランチと悪性ワークフローのコミットを発見しています。そこからさらに各種トークン（GitHub PAT、npm資格情報、Atlassian社のキー、Datadog APIキーなど）が露出していたことも突き止めました。これらログ上に露出したシークレットも放置すれば第三者に見られる恐れがあり、実質的な漏洩と言えます。

全体として、攻撃者は数日の活動で数百件以上の認証情報を窃取・公開したと推定されます。GitHub上には攻撃者の痕跡として複数の新規リポジトリやコミットログが残り、情報流出の証拠となっています。幸いWebhook経由の外部送信が途中で遮断されたため、それ以上のデータ流出は抑制された可能性があります。しかし一度公開リポジトリやログに載ってしまった情報は完全な回収が困難であり、被害の甚大さは否めません。

ユーザー・組織への波及: パッケージ利用者が受ける潜在的影響の広がりを考察【二次被害】

攻撃されたパッケージ群の利用者もまた、潜在的な被害者です。npmで公開されているライブラリは、世界中の開発者や企業のプロジェクトに組み込まれています。そのため、Shai-Huludに汚染されたパッケージを依存関係として取り込んでしまったユーザーは、知らぬ間に自分の開発環境にマルウェアを招き入れた可能性があります。

現実に、Shai-Hulud攻撃発覚直後には「自分のプロジェクトで当該バージョンを使っていたが影響はあるか」「インストール後に何をすべきか」といった問い合わせが相次ぎました。開発者個人であればPCやプロジェクトのクリーンアップで済む話かもしれませんが、組織単位では社内ネットワーク全体にセキュリティリスクが広がる懸念もあります。また、依存元パッケージの不正により自社製品の安全性に疑義が生じるなど、信頼性の低下という二次的被害も考えられます。

さらに、パッケージ利用者が受ける影響は技術的損害だけではありません。例えば、自社サービスが攻撃者により一時的にでも情報を抜き取られたとなれば、顧客からの信頼失墜や法的義務（個人情報漏洩通知など）も発生し得ます。オープンソースのサプライチェーンに潜むリスクが顕在化した今回の事件は、利用者側にも依存ライブラリの監査やロックダウンなど新たな対策の必要性を認識させる結果となりました。

ワーム型マルウェア「Shai-Hulud」の機能と特徴: データ窃取から自己伝播まで多層的な手口を徹底解剖

Shai-Huludの内部に目を向け、そのマルウェアとしての機能や特徴を探ってみましょう。データ窃取、自己伝播といった多段階の攻撃を可能にした秘密は、マルウェア自体の高度な設計にあります。本節ではコードの性質や動作環境、攻撃者の工夫などを解剖し、このマルウェアが如何に巧妙かを明らかにします。

高機能なマルウェアの正体: 一つのスクリプトに盛り込まれた多段階攻撃の概要と分析【マルウェア】

Shai-Huludの正体は、npmパッケージ内に仕込まれた1つの巨大なJavaScriptスクリプトです。そのサイズは数MBにも達し、内部に今回解説している一連の攻撃ロジックがすべて組み込まれている点が特徴です。一般にマルウェアは機能ごとに外部プログラムを呼び出したりすることも多いですが、Shai-Huludの場合はほぼ単一のスクリプト（例: bundle.js）で完結しています。

この「オールインワン」な設計により、攻撃は非常にスムーズかつ自律的に進行します。インストール直後の初期処理から、シークレット探索、データ送信、ワークフロー設置、自己増殖に至るまで、ほぼ連続的に一気通貫で実行されます。そのため外部から見れば、ごく短時間のうちに一連の被害が成立してしまうのです。これは防御側にとっては検知と封じ込めの難易度を上げる要因となりました。

また、このスクリプトは非常に高機能で、エラーハンドリングや環境差異への対応などもしっかり実装されています。例えば実行中に一部の処理が失敗しても、他の部分は継続するようになっているなど、攻撃の信頼性を高める工夫が随所に見られました。全体として、Shai-Huludは単純なマルウェアではなく、多段階攻撃を実現するために練り上げられた高度な攻撃ツールであると言えます。

環境依存の挙動: Linux/MacOSで作動しWindowsを回避する設計の詳細【OS別挙動】

Shai-Huludの動作を詳しく見ると、OS環境によって挙動を変えるよう設計されていることが分かりました。具体的には、攻撃コード内でos.platform()などを用いて実行環境を判別し、Linux系またはMacOS環境でのみ主要な攻撃ステップを実行するようになっていたのです。一方、Windows環境では一部の処理がスキップされ、マルウェアとしての活動が抑制される傾向が確認されました。

これはなぜでしょうか。考えられる理由の一つは、攻撃コードがLinux/Mac環境のシェルやコマンドツール（bashや各種ユーティリティ）に依存しているためです。実際、GitHub Actionsワークフロー設置やリポジトリ公開のシェルスクリプトなど、UNIX系コマンドで書かれている部分があります。そのため、Windows上では互換性がなくエラーになる処理があり、結果として動作しない機能が出てくるのです。

もう一つの見方として、攻撃者は主な標的をLinuxサーバやMac開発機に絞っていた可能性があります。実際、プロフェッショナルな開発環境ではLinuxやMacが多用される一方で、Windowsでnpmパッケージを発行するケースは相対的に少ない傾向があります。攻撃者は効率良く成果を上げるために、敢えてWindowsを回避して目立たないようにしていたのかもしれません。このようにOS依存の挙動を持つ点もShai-Huludの興味深い特徴です。

コメントや絵文字を含むコード: AI生成の可能性が示唆するものを考察【AI痕跡】

Shai-Huludのコード内部を解析した研究者たちは、そこに異様なスタイルのコメントや絵文字が含まれていることを報告しています。例えば、コードの一部には攻撃内容に似つかわしくない陽気なコメント行や、😅のような絵文字が散見されました。これは通常のマルウェア開発者の手法としては珍しく、攻撃コードの一部が大規模言語モデル（LLM）によって生成された可能性があると指摘されています。

近年、GitHubのCopilotなどAIアシスタントを使ってコードを書く開発者も増えており、攻撃者も例外ではないようです。LLMでコードを生成すると、人間らしくない独特のスタイルのコメントや無意味な装飾（絵文字など）が混入することがあります。Shai-Huludのコードで見られた不自然なコメント群はまさにその典型で、開発効率を上げるためにAIを利用した痕跡と解釈できます。

仮にAIで一部が生成されていたとして、それ自体は攻撃の成功率に直接影響するものではありません。しかし、攻撃者が最新技術を積極的に活用している点は注目に値します。LLMを用いることで、複雑なワーム機能を短期間でコーディングできたのかもしれません。攻撃コードからは、攻撃者の技術的先進性と大胆さが垣間見えます。

持続性の確保: リポジトリの改変やWorkflowsによる潜伏手法の詳細【持続的潜伏】

マルウェア開発者にとって、ターゲット環境でいかに長く潜伏し続けるかは重要な課題です。Shai-Huludは、この持続性（永続化）確保にも巧妙な手段を取り入れていました。特に効果的だったのが、先述のGitHub Actionsワークフローの改変とプライベートリポジトリの公開です。これらの手口により、攻撃者は被害者のクラウド上に持続的なバックドアと情報漏洩ルートを仕掛けることに成功しています。

ワークフローの改変によって、一度攻撃を受けたリポジトリは、開発者がそれに気付いて悪性ファイルを削除しない限り、以後の更新時にもまた機密情報を漏洩し続けてしまいます。これは言わば「感染の持続化」であり、攻撃者は何度でも新鮮なシークレットを得られるわけです。同様に、プライベートリポジトリの公開も、組織がそれに気付くまで内部情報を晒し続けるという持続的被害をもたらしました。

また、攻撃コード自身にも持続性を高める工夫が見られます。/tmpディレクトリに落とされるスクリプト（後述）や、定期実行される可能性のある仕掛けなど、完全に駆除しない限り断続的に活動を継続する要素が含まれていました。これらはシステム再起動や一時的な対処では根治できず、開発環境に長く潜伏し得るものです。総じてShai-Huludは、単発の攻撃にとどまらず粘り強く食い下がる設計となっており、防御側にとって厄介な存在でした。

従来のサプライチェーン攻撃からの進化: 自己増殖機能がもたらす新たな脅威への発展を分析する【脅威レベル】

Shai-Hulud攻撃は、オープンソースを狙った従来のマルウェアから一段階進化した脅威だといえます。以前からnpm等のリポジトリで悪意あるパッケージが発見されるケースはありましたが、多くは「利用者の情報を盗むだけ」か「一度動いて終わり」のものでした。しかしShai-Huludは、自身を次々と広める自己複製能力を備えることで、これまでにないインパクトを生みました。

この進化の背景には、攻撃者がソフトウェアサプライチェーンの「最も弱い部分」を狙い撃ちし始めたことがあります。すなわち、開発者アカウントやトークンの乗っ取りから始まり、そこから芋づる式に広がるという戦術です。一連の攻撃は、人間の手による個別の操作ではなくプログラムによる自動化で行われ、従来なら人的リソースの制約で不可能だった規模の攻撃を実現しました。これはソフトウェア供給網における脅威レベルが新段階に達したことを意味します。

セキュリティ界では以前から「オープンソースマルウェアのワーム化」の可能性が議論されてきましたが、Shai-Huludはそれを具現化した最初の大規模例となりました。この新たな脅威により、防御側も対策をアップデートする必要に迫られています。具体的には、信頼するパッケージソースが内部から毒されることを想定した監視体制や、万一侵入されても拡散を防ぐネットワーク分離など、新しい視点でのセキュリティ強化が求められています。

収集・抜き取りされる情報: 攻撃者が狙う機密データとその流出先の詳細、および悪用される可能性を検証・解説

Shai-Huludマルウェアは開発環境から一体何を盗み出したのか、また盗まれた情報はどこへ行き、どのように悪用される危険があるのかを整理します。

窃取される情報の種類: npmトークン、GitHub PAT、クラウドプロバイダ鍵などの一覧【機密種別】

Shai-Huludが標的とした情報は多岐にわたります。主なものとして以下の種類が確認されています。

• npmアクセス・公開トークン: .npmrcファイル等に保存された認証トークンやAPIキー。これにより攻撃者はnpmに不正アップロードが可能になります。
• GitHubの個人アクセストークン (PAT): 開発者がGitHubで使うアクセストークン。リポジトリ操作やAPI利用に必要な鍵で、これが漏れるとアカウント操作を乗っ取られる恐れがあります。
• クラウドプロバイダの秘密鍵・APIキー: AWSやGCP、Azureなどのクラウドサービスのアクセスキーやシークレットキー。ストレージやVM管理、データベースアクセス権限などが含まれ、非常に機密度が高い情報です。
• 環境変数中の認証情報: データベース接続文字列、サードパーティサービスのAPIキー、メールサーバのパスワード等。開発・運用上広く使われる秘密情報です。
• SSH秘密鍵: 開発者マシンに保存されたSSHの秘密鍵ファイル。これが盗まれると攻撃者は被害者になりすましてサーバーにログインできてしまいます。
• ウォレット関連情報: 暗号通貨のウォレットファイルや秘密鍵、その他金銭的価値のある情報。過去の攻撃では暗号資産狙いもあったため、同様の探索が行われた可能性があります。

以上のように、Shai-Huludは開発者の生産性向上のために保持している便利な認証情報を丸ごと盗み出す設計でした。リポジトリ公開権限からクラウド全権アクセスキーまで、その範囲は極めて広範であり、一つでも漏洩すれば重大インシデントにつながりかねないものばかりです。

クラウドメタデータの悪用: AWS/GCPなどのインスタンス情報から取得されるキーの詳細【クラウド鍵流出経路】

Shai-Huludの情報収集で特筆すべきは、クラウドインフラに特有のメタデータサービスを悪用している点です。例えばAWSではEC2インスタンス内からhttp://169.254.169.254/latest/meta-data/にアクセスすると、そのインスタンスに付与されたIAMロールの一時認証トークンなどが取得できます。同様にGCPやAzureにもメタデータサービスが存在します。

Shai-Huludのコードは、こうしたメタデータエンドポイントへのHTTPリクエストを送信し、可能であればクラウドの一時認証情報を引き抜く仕組みを備えていました。開発者がクラウド上のVMやコンテナ内でパッケージをインストールしていた場合、マルウェアはローカルなキーのみならずクラウドサービス用のキーまで丸ごと取得できてしまいます。

このクラウドメタデータ悪用は、近年のサプライチェーン攻撃でも徐々に見られるテクニックであり、攻撃者がクラウド環境の知識を持っていることを示します。インスタンスメタデータ上の認証情報は通常数時間～日単位で有効なため、攻撃者はその時間内にクラウドリソースへアクセスして二次被害を引き起こす恐れがあります。開発者にとっては、自分のPCだけでなくクラウド上でCI/CDを回している環境も同時に危険に晒されることを意味し、非常に厄介です。

収集データの保存先: 攻撃者が作成するGitHubリポジトリとWebhook【データ流出先】

Shai-Huludが盗み出したデータの送り先については、すでに技術的な流れの中で触れましたが、改めて整理します。まず第一の保存先は、攻撃者が被害者ごとにGitHub上に作成した公開リポジトリ「Shai-Hulud」でした。ここには先述の通りdata.jsonがコミットされ、二重のBase64エンコードでシークレット類が収められていました。GitHubリポジトリを使うことで、攻撃者はブラウザで該当リポジトリを見るだけでデータを収集できます。

第二の送り先は、Webhook経由のデータ集積サーバーです。Shai-HuludはGitHub Actionsの仕組みを悪用して、各リポジトリのシークレットをWebhookサイト（攻撃者が監視できる一時的なURL）へHTTP送信していました。このWebhookは一種の一時的な受け皿で、攻撃者はそのURLにアクセスすることで収集データを閲覧できるようになっていました。ただし、前述の通りWebhookサービス側で無効化されたため、一部データはこの経路ではなくGitHub上のログに留まっています。

いずれにせよ、攻撃者はGitHubプラットフォームという一見安全な経路を利用しつつ、確実に情報を手に入れるルートを二重三重に確保していたわけです。結果として、開発者から盗まれた大量のシークレットが攻撃者の手元に渡りました。なお、攻撃者が用意したGitHubアカウントやWebhookは攻撃発覚後に凍結・削除されましたが、その頃にはすでに必要な情報はダウンロード済みだったと考えられます。

漏洩した認証情報の悪用リスク: クラウドリソース乗っ取りや横展開の懸念を考察

窃取された資格情報が攻撃者の手に渡った場合、どのような二次被害が起こりうるでしょうか。そのリスクは多岐にわたります。

• クラウドリソースの不正利用: AWSやGCPの鍵が漏れた場合、攻撃者は被害者のクラウド環境にログインし、データストレージ（S3バケットやGCS）、データベース、仮想マシン等に自由にアクセスできてしまいます。最悪の場合、重要データの窃取、破壊、暗号化（ランサムウェア）、不要なリソースの大量作成（仮想通貨マイニング等）といった被害が発生します。
• 開発インフラの破壊・改ざん: CI/CD用のシークレットやGitHubトークンが漏れれば、攻撃者は被害者のソースコードやビルドプロセスに介入することも可能です。例えば、ソースコードにバックドアを仕込んだり、ビルド済みアプリケーションに不正な変更を加えるなど、組織のソフトウェア供給網そのものを乗っ取るような攻撃が派生する恐れもあります。
• 社内ネットワークへの横移動: SSHキーやVPN認証情報が盗まれれば、攻撃者は被害者企業の内部ネットワークに侵入し、別のサーバやサービスへ横方向（ラテラル）に移動できます。そこから社内の他のシステムを次々と攻撃することで、被害範囲が企業全体に拡大する可能性があります。
• プライベート情報の公開による損害: プライベートリポジトリが公開されてしまった場合、内部のソースコードや設計情報が外部に漏れます。知的財産の流出や、脆弱性情報が第三者に知られることによるセキュリティ低下、ビジネス上の信用失墜など、長期的な損害も懸念されます。
• フィッシング詐欺等への悪用: 攻撃者が盗んだ連絡先情報や認証情報を元に、さらにフィッシングメールを送ったりサプライチェーンの他の部分（例えば関連会社や顧客）に侵入する手掛かりとすることも考えられます。

このように、Shai-Huludがもたらす被害は直接的な開発環境侵害に留まらず、その後の連鎖的な攻撃リスクまで含めて非常に深刻です。組織は自社が漏洩した可能性のある情報の範囲を精査し、クラウドアカウントの不審な動作がないか監視するなど、二次被害を防ぐための対策を早急に講じる必要があります。

攻撃フローと技術的特徴: GitHubやnpmを悪用する巧妙な手口と攻撃コードの詳細解析【技術分析】

ここではShai-Hulud攻撃の手口を技術的観点からさらに深掘りします。GitHubやnpmといったプラットフォームをどう悪用したのか、攻撃コードにどんな工夫が凝らされていたのかを順に見ていきましょう。

GitHub Actionsワークフロー悪用の詳細: shai-hulud-workflow.ymlが行う動作を解析

Shai-Huludが仕掛けたGitHub Actionsワークフロー（shai-hulud-workflow.yml）について、その中身を詳しく見てみましょう。このワークフローはYAML形式で記述され、リポジトリに取り込まれると特定のトリガーで実行されます。基本的な動作は以下の通りです。

• シークレットのシリアライズ: リポジトリに設定されたシークレット（例えばGITHUB_TOKENやクラウドサービスの鍵など）をすべて文字列化し、一つのデータブロックにまとめます。
• 外部への送信: まとめたシークレット情報をHTTPリクエストとして送信します。送信先は攻撃者が用意したWebhook URL（webhook.site/...）であり、POSTリクエストによりシークレットが外部に漏洩します。
• ログへの埋め込み: さらに、このシークレット情報をBase64エンコードし、GitHub Actionsのログ出力にも書き込みます。これにより、たとえWebhookが無効化されてもログから情報を抜き取れるようにする二重の策が施されています。

ワークフローは主に上記のことを実行するジョブからなり、トリガー条件としてはプルリクエストのマージやpushイベントなどが指定されていたと推測されます。つまり、攻撃者が意図したブランチがマージされてしまった後、次の開発サイクルでコードをプッシュした際にこのワークフローが発火し、自動的に情報漏洩が行われるのです。

なお、このワークフロー自体には“shai-hulud”という名称が含まれているため、注意深くリポジトリの設定を見れば検知は可能でした。しかし、大規模なプロジェクトではActionsの設定ファイルが多数存在する場合もあり、見落としがちです。攻撃者はこの点も突いて、バレにくい環境では長期間ワークフローが活動するよう仕組んでいました。

npmトークン自動利用: 被害者保有のパッケージへのマルウェア注入プロセスの全容【自動汚染】

Shai-Huludの自己増殖ロジックについて、技術的にもう少し詳しく説明します。攻撃コードには、盗み出したnpmの認証トークンを使って、パッケージの改ざんと公開を自動化するモジュールが含まれていました。大まかな流れは以下の通りです。

1. 攻撃コードがnpm CLIコマンド等を内部的に呼び出し、被害者のnpmアカウントにログイン（認証トークンを使用）。
2. 被害者がメンテナー権限を持つすべてのパッケージの一覧を取得。
3. 各パッケージに対し、新たな悪性コード片（先述のbundle.jsなど）を注入したバージョンを生成。
4. 更新したバージョンを、バージョン番号を上げてnpmレジストリに公開（publish）。

これらの処理がシンプルなループとAPI操作で実現されており、人手を介さず高速に行われました。被害者ごとに侵害パッケージは異なりますが、平均すると一人あたり数個から十数個のパッケージが連鎖改ざんされた模様です。

コード上の工夫としては、公開の際に元々のパッケージのReadmeやその他メタデータなどをそのままにしておき、悪意ある改変を最小限の差分に抑えている点が挙げられます。こうすることで、パッケージの利用者がアップデートしても挙動の変化に気付きにくく（ドキュメント等は正規のままなので疑念を抱かれにくい）、攻撃のステルス性が向上します。まさに水面下で次々とパッケージが毒されていった背景には、こうした巧妙な自動汚染プロセスが存在したのです。

リポジトリ公開トリック: Private->Publicへの切り替えで情報曝露を狙う手口の手法【リポジトリ乗っ取り】

攻撃フローの中でも異色だったプライベートリポジトリ強制公開について、その手法を技術的にまとめます。攻撃コードはGitHubのAPIやGitコマンドを駆使して、組織のプライベートリポジトリを攻撃者アカウントに乗っ取るような操作を行いました。

まず攻撃者は、被害者がアクセスできる各リポジトリに対し、GitHub API経由でリポジトリ内容を複製します。これはGitミラーリングやクローンと同等のことを自動化したものと思われます。そして攻撃者自身のGitHubアカウント上に同名または類似名のリポジトリを新規作成し、その中に複製したデータをインポートします。当初このリポジトリはプライベートで作られますが、直後にGitHub APIでリポジトリのvisibilityをpublicに変更します。

この一連の操作は非常に迅速に行われ、GitHub上のイベントとしてはCreateEvent（非公開）に続いてPublicEvent（公開）の2つが記録されます。今回の調査で、攻撃者が触れたリポジトリでは軒並みこのセットのイベントが確認されており、攻撃者が自動スクリプトで実行したことを裏付けています。

攻撃者がなぜこんなことをしたのか考えると、目的は2つあったと推測されます。1つは機密コードベースの暴露です。競合企業や第三者にソースコードを晒すことで被害組織にダメージを与える意図が考えられます。もう1つは、公開したリポジトリに含まれるシークレットなど二次的情報の入手です。プライベートリポジトリにはアプリケーションの構成情報等が含まれる場合も多く、公開されることで思わぬ情報が漏れる可能性があります。

この手口は比較的派手で露見もしやすいため、攻撃者としては最後の仕上げ的に行ったのかもしれません。実際、本攻撃でリポジトリを公開された被害者は限定的でした。ただ、従来の攻撃では見られなかったこのようなトリックを盛り込んでくるあたり、攻撃者の大胆さと悪質さが際立っています。

攻撃コード解析: JavaScriptペイロード(bundle.js)に見る自己複製ロジックの詳細【攻撃コード】

Shai-Huludの中心にあるJavaScriptペイロード（bundle.js）の実装も簡単に触れておきます。bundle.jsは難読化されている部分もありましたが、主要なロジックは逆コンパイルや静的解析によって解明されています。

このコードは大きく分けて次のようなモジュールに整理できます。

• 環境チェック・初期設定: OSプラットフォームや必要コマンドの存在確認、エラー時の挙動設定など。
• シークレット収集モジュール: TruffleHog等を呼び出し、環境変数・ファイルシステム・メタデータから秘密情報を収集する処理。
• データ送信モジュール: GitHub APIやWebhookへの送信、GitHubリポジトリ作成・コミットなどを行う処理。
• 自己増殖モジュール: npmの認証、パッケージ一覧取得、コード改変、npm公開を行う処理。
• ワークフロー設置モジュール: GitHub APIでリポジトリ一覧取得、ブランチ作成、YAMLファイルアップロード、プルリク生成を行う処理。
• リポジトリ移行モジュール: シェルコマンドを組み合わせ、リポジトリをクローンし公開設定を変更する処理。

これら各モジュールがシームレスに連携するように記述され、直列的に実行されます。コード中にはコメントも含め、かなり冗長な箇所もありました。難読化については次節で触れますが、全体としてbundle.jsは非常に大規模でありながら、攻撃フローを漏れなく実現した中核コンポーネントでした。

解析により、一部コードは非効率な実装や未使用の関数も見受けられたことから、攻撃者が外部から借用したコードを混ぜている可能性も指摘されています。とはいえ要所はしっかり機能しており、このbundle.js一つでこれだけのことをやってのける点は驚嘆に値します。

難読化と回避策: 攻撃コードが検知逃れのために施した工夫の詳細【難読化】

Shai-Huludのコードには、セキュリティ対策に引っかかりにくくするための様々な工夫も見られました。

まず、難読化です。bundle.js内の変数名や関数名は意味のない文字列に置き換えられており、また不要なコメントや無意味なコード片が挿入されていました。これは静的解析を妨げ、人間の分析を難しくする典型的な手法です。加えて、コードの一部が前述のようにAI生成らしき冗長さを持っていたため、逆にそれが難読化の一環となっていたとも言えます。

次に、検知回避に関しては、ネットワーク通信の工夫が挙げられます。外部へのデータ送信先として攻撃者独自のサーバーではなくGitHubやWebhookサービスといった「普段から利用されているドメイン」を使用したことは、ネットワーク監視をすり抜けるポイントでした。また、システムコール的にも過度な怪しい動作をしないよう配慮されています。例えば、ファイルを大量生成したりレジストリをいじったりといった典型的マルウェア行動は控え、あくまで開発用途のツール（git, npm等）の範囲で動いているように見せています。

そのほか、エラーメッセージやログ出力も抑制されており、ユーザーがターミナル上で異変に気付く機会はほぼ皆無でした。万一どこかで失敗してもプロセス全体がクラッシュしないよう例外処理も組み込まれています。これらの工夫により、Shai-Huludは非常にステルス性の高い攻撃を実現していました。

総じて、Shai-Huludの攻撃コードは洗練されており、単に多数の機能を持つだけでなくそれらをいかにバレずに遂行するかにも主眼が置かれていました。この難読化・検知回避技術の高さも、本攻撃が成功裡に大規模拡散を果たした一因でしょう。

侵害の兆候とIoC: 感染を見極める手がかりと監視すべき兆候、および検知のための指標

Shai-Hulud攻撃をいち早く発見するためには、開発環境やサービス上に現れる異変（侵害の兆候）を知っておく必要があります。ここでは、感染の有無を判断する具体的な手がかり（IoC: Indicator of Compromise）を挙げます。

新規リポジトリ『Shai-Hulud』の有無: 開発者アカウントに不審な公開Repoの存在確認【不審Repo】

最も分かりやすい兆候の一つは、GitHubアカウント上に見覚えのない「Shai-Hulud」という公開リポジトリが存在することです。自分やチームメンバーのGitHubアカウントに、この名前のリポジトリが突然作成されていないか確認してください。Shai-Hulud攻撃では被害者ごとにこの公開リポジトリが自動作成され、収集データを置く用途に使われました。

通常、自身でShai-Huludという名称のリポジトリを作ることはまずないでしょうから、発見した時点で感染が強く疑われます。対策としては、該当リポジトリを速やかに削除するとともに、残っているコミット内容（data.jsonなど）から漏洩情報の範囲を特定します。また、同様のリポジトリが組織内の他メンバーにないか横断的に調査することも重要です。

ワークフローに残る痕跡: .github/workflows/shai-hulud-workflow.ymlの存在をチェック

自身のGitHubリポジトリ内に、.github/workflows/shai-hulud-workflow.ymlというファイルが存在しないか確認してください。これは攻撃者が設置した悪性ワークフロー定義ファイルです。特にプルリクエスト欄に見知らぬ「shai-hulud」ブランチからのマージ提案が残っていないか、Actions設定に不審なワークフローが追加されていないかを調べましょう。

大規模なリポジトリではファイルを一つ一つ見るのは困難ですが、GitHubの検索機能で「shai-hulud」というキーワードをリポジトリ全体から探すとヒットします。また、組織全体でGitHub APIを使ってWorkflow一覧を調べ、該当するYAMLファイルがないか監査することも効果的です。もし発見した場合は、その時点でまだ情報が抜き取られている可能性があるため、すぐにワークフローを無効化・削除してください。

Webhook通信の記録: https://webhook.site/… へのアクセス痕跡の検知ポイント

ネットワークモニタリングを行っている場合、特定のWebhookサイトへの通信履歴が重要なIoCとなります。Shai-Huludはデータ送信先としてwebhook.siteドメイン（および特定のGUIDパス）を利用していたため、自社ネットワークや開発者PCからそのURLへのHTTP POSTリクエストが発生していないかログを確認しましょう。

webhook.site自体は開発テストで使われることもあるサービスですが、通常プロダクション環境から頻繁に通信することは考えにくいものです。プロキシやエンドポイントセキュリティのログから、このような外部通信が行われていた形跡があれば、Shai-Hulud感染の強い疑いがあります。また、GitHub Actionsのログ中にもWebhook URLが登場していないかを検索することをお勧めします。実際、攻撃後にセキュリティチームがログからこのURLを発見したケースが報告されています。

一時ディレクトリのマルウェア痕跡: /tmpフォルダ内の不審なスクリプトの存在【マルウェア痕跡】

Shai-Huludの攻撃中、Linux系環境では/tmpディレクトリに一時的なスクリプトファイルを作成する動作が確認されています。例えば、/tmp/processor.sh（ワークフローを設定するシェルスクリプト）や/tmp/migrate-repos.sh（リポジトリ公開用スクリプト）などがドロップされていました。

通常、開発環境で/tmpにこれらの名前のスクリプトが置かれることは稀です。万が一残存していれば、Shai-Huludの活動があった明確な証拠となります。したがって、端末上でls /tmp | grep -i shaiやls /tmp | grep -i migrateなどと検索し、不審なファイルがないかチェックしてみてください。

なお、攻撃コードは基本的に処理完了後に一時ファイルを削除するようになっていました。しかしエラー等で削除処理が実行されないとファイルが残る可能性があります。対応としては、/tmpディレクトリに怪しいシェルスクリプト等が残っていた場合、すぐに内容を確認・隔離することが挙げられます。それ自体に機密情報（実行ログなど）が含まれる場合もありますので、慎重に扱ってください。

公開イベントログ: リポジトリのPublic化（CreateEvent/PublicEvent）の確認【公開履歴】

組織や開発者アカウントのアクティビティログも、有用な兆候検知の手がかりです。具体的には、GitHub上の監査ログ（GitHub Enterpriseの場合）や、パブリックなイベントフィードにおいて、自分のアカウントから「Repository created」や「Repository visibility change」といったイベントがないか確認してください。

Shai-Hulud攻撃ではプライベートリポジトリが攻撃者アカウントにおいて新規作成・公開化されるという動作がありました。例えば、ある被害者のケースでは、9月15日に攻撃者がその人のリポジトリをクローン→同日内に公開というイベントが記録されています。このように時系列で見れば明らかに異常な操作があったことがわかるので、GitHubの提供するログ機能を活用することが重要です。

加えて、GitHubからの通知メール（リポジトリが公開された際には本人に通知が届くことがあります）も見逃さないようにしましょう。もし身に覚えのないリポジトリ公開通知が来た場合は、即座にアカウントをチェックする必要があります。

開発環境・クラウドへの影響と潜在的リスク: CI/CDやクラウドへの波及によるセキュリティ上のリスクとその深刻性

Shai-Hulud攻撃によって引き起こされる可能性のある様々なリスクを、開発環境やクラウドへの影響という観点から整理します。これは先に述べた認証情報の悪用リスクと重なる部分もありますが、被害が現実化した場合の具体的なシナリオを想定することで、リスクの深刻性を再認識します。

クラウドサービスへの影響: AWS/GCPキー漏洩によるインフラ侵入やデータ漏えいのリスク【クラウド被害】

クラウド関連の認証情報（アクセスキーやシークレットキー）が漏洩した場合、組織のクラウドインフラ全体が危機にさらされます。攻撃者は正規ユーザーになりすましてクラウドサービスにログインし、以下のような行為が可能となります。

• 機密データの窃取: S3バケットやCloud Storageに保存された顧客データ、データベース内の情報などをダウンロードして持ち去る。
• 破壊・改ざん: 仮想マシンやデータベースを削除したり、データを改ざん・暗号化（ランサムウェア化）することでサービスを停止させる。
• 不正リソース作成: マイニング目的の高性能VMを大量起動したり、ボットを動作させるコンテナをデプロイするなどして、被害者に経済的損失（クラウド利用料の増大）を与える。
• 持続的バックドアの設置: IAMユーザーやロールを密かに作成し、攻撃者専用のアクセス経路を仕込むことで、たとえ漏洩キーを無効化されても再侵入できるようにする。

このようにクラウドキー漏洩は組織にとって甚大なリスクです。オンプレミス環境とは異なり、クラウドでは攻撃者がグローバルにどこからでも操作可能なため、侵入後の被害拡大スピードも速いです。特に注意すべきは、クラウドは本番サービスの基盤でもあるため、障害＝顧客影響直結になりやすいことです。

Shai-Huludの被害者組織は、自社のクラウドアカウントで不審な操作履歴がないか即座に洗い出す必要があります。アクセスログ（AWS CloudTrail等）を確認し、異常なIPアドレスや通常行わない操作がないかチェックしましょう。また、漏洩した可能性のあるキーはすべて無効化・ローテーションし、新しいキーに切り替えることが肝要です。

CI/CDパイプラインの危険: ビルドプロセスにおけるマルウェア拡散と改ざんリスクの恐れ【CI攻撃】

Shai-Hulud攻撃はCI/CDパイプラインにも悪影響を及ぼす可能性があります。開発現場では、GitHub ActionsやJenkins、GitLab CIなど様々なCIツールが使われていますが、これらに今回の攻撃が絡むと以下のようなシナリオが考えられます。

• ビルド成果物への汚染: 攻撃者がCIの権限を掌握した場合、ビルド中に不正コードを混入させ、出来上がったソフトウェアにバックドア等を仕込む可能性があります。
• CIパイプラインの停止: 攻撃によりCI上のシークレットが漏洩したり、ジョブが異常終了する事態になると、開発・デプロイの流れが滞りビジネスに影響が出ます。
• CI環境のマルウェア拡散: CI/CD用の共通コンテナイメージやビルドエージェントにマルウェアが潜伏すると、パイプラインを実行する度に再感染するなど、持続的な脅威となりえます。

特に前述したGitHub Actionsワークフローの不正設置は、CIプロセスを乗っ取り情報を抜く典型例でした。これがより悪質な改ざんに発展する可能性もあり、注意が必要です。組織はCI用のシークレット（例えば署名キーやデプロイ用クレデンシャル）が漏洩していないか確認し、必要に応じてそれらも更新することを検討すべきです。

また、CI/CD環境は本番へのコード反映を担う重要インフラであるため、ゼロトラストの考え方で「CIが侵されても被害を最小限に抑える」対策が今後求められます。具体的には、ビルド済みバイナリの検証や、二段階のデプロイ承認、重要シークレットへのアクセス制限強化などが考えられます。

社内ネットワークへの波及: 被害者企業内での横方向の侵入可能性を警戒すべき必要性

Shai-Huludによって開発者PCが侵害された場合、その影響は社内ネットワーク全体にも波及しうる点を忘れてはなりません。前述の通り、盗まれたSSH鍵やVPN資格情報は、攻撃者が社内ネットワークに侵入する足掛かりとなります。もし開発者PCが社内LANに常時接続されていたり、社内の他サーバへのアクセス権を持っていれば、そこから内部攻撃が始まる可能性があります。

例えば、開発者PC→CIサーバ→本番DBサーバという風に、段階的に侵入範囲を広げられると被害は甚大です。特にSSHは多くのサーバ管理に用いられているため、一度秘密鍵を盗まれるとなりすまし攻撃が成立してしまいます。近年、APT（高度持続的脅威）と呼ばれる攻撃者グループは、最初の侵入点から巧みに横方向へ侵入して組織内に長期間潜伏することがありますが、Shai-Huludによる資格情報漏洩はまさにその入り口を大量に提供してしまったとも言えます。

企業はこのリスクに備え、社内ネットワークの監視やセグメント分離を見直す必要があります。万一一部のクレデンシャルが悪用されても、組織全体が一網打尽にならないよう、権限や接続経路に制限を設けることが重要です。また、異常な内部アクセス（深夜帯に開発者PCから本番サーバへのSSH接続試行がある等）を検知できるよう、ログ分析体制を整えることも求められます。

開発プロジェクトへのダメージ: プライベートコード公開や信頼性喪失による損害の恐れ【信用失墜】

Shai-Hulud攻撃は技術的な損害だけでなく、プロジェクト運営やビジネス面でのダメージも招きます。プライベートなソースコードが漏洩した場合、競合に戦略を読まれたりゼロデイ脆弱性を悪用される可能性が出てきます。また、社内専用ツールやノウハウなど、本来秘匿すべき情報が公開されると、競争上の不利益を被る恐れがあります。

さらに、開発者や組織の信用失墜という見逃せない問題もあります。オープンソースコミュニティにおいて、自分が管理するパッケージからマルウェアが配布されてしまった開発者は、その後の活動において信頼を回復するのに苦労するでしょう。同様に、企業が提供するSDKやライブラリが感染源になった場合、ユーザー企業からの信用は大きく損なわれます。場合によっては契約違反や訴訟に発展するケースも考えられます。

顧客やユーザーへの対応コストも無視できません。もし製品やサービスにマルウェアを混入させてしまった場合、謝罪や修正版リリース、場合によっては賠償など、多大なコストと労力を要します。Shai-Hulud攻撃は一見開発現場の問題に見えますが、実はビジネス継続性やブランド評価にも直結するリスクを孕んでいるのです。組織はこうした非技術的影響も含めて被害想定を行い、対策と危機管理計画を用意しておく必要があります。

対策・防御方法および被害からの回復手順: 早期対応と再発防止策、被害を最小限に抑える実践的対処法を解説

最後に、Shai-Hulud攻撃に対する具体的な対策と、被害に遭ってしまった場合の回復手順について解説します。早期の対応が被害拡大を防ぎ、また再発防止策を講じることで将来的なリスクを軽減できます。

感染パッケージの除去とシステムクリーンアップ: npmモジュール削除とキャッシュクリア手順【初動対応】

Shai-Hulud感染が判明・疑われた場合、まず真っ先に行うべきは悪意あるパッケージをシステムから排除することです。具体的な手順としては:

• プロジェクトのnode_modulesディレクトリを削除する（全て再インストールするため）。
• npmのキャッシュをクリアする（npm cache clean --forceコマンドを実行）。これによりキャッシュに残った悪性コード片も消去されます。
• パッケージロックファイル（package-lock.jsonやyarn.lock）を確認し、該当の悪性バージョンが含まれていないかチェック。必要に応じてロックファイルを更新または削除し、クリーンなバージョンで再インストールする。

これらを実施した上で、プロジェクトをnpm経由で再度セットアップし直します。攻撃者の改変が残っていなければ、以降インストールされるコードは正規のものとなります。また、可能であれば開発マシン全体のマルウェアスキャンも行います。Windows Defenderや各種ウイルス対策ソフトを使ってPC全体をチェックし、不審なプロセスやファイルが残っていないことを確認してください。

これら初動対応により、ひとまず開発環境からマルウェアそのものを駆逐することができます。ただし既に漏洩してしまった情報は戻りませんので、この後の手順で被害を食い止める必要があります。

盗まれた資格情報の無効化: npm/GitHubトークンやクラウドキーの緊急ローテーション対応【資格情報無効化】

マルウェアによって盗まれた可能性のある認証情報は、一刻も早く無効化または変更（ローテーション）する必要があります。以下を優先的に実施してください。

• npmトークンの無効化: npmアカウントに紐づくアクセストークンを全て無効にします。npmの設定画面から発行済みトークンを確認し、該当するものを取り消してください。その上で、新しいトークンを再発行し、必要な場所（CI環境等）に設定し直します。
• GitHub Personal Access Token (PAT) のローテーション: GitHubアカウントで使用していたPATを破棄し、新規発行します。併せて、GitHubが提供するセキュリティログで不審な認証の有無を確認しましょう。
• クラウドAPIキーのローテーション: AWS、GCP、Azureなどのアクセスキー・シークレットキーをすべて再発行します。IAMユーザーやサービスアカウント単位でキーを洗い出し、漏洩の疑いがあるものは直ちに失効、新規キーへの切り替えを行います。
• SSH秘密鍵の入れ替え: 開発者PC上のSSH鍵が盗まれた可能性があるため、新たなキーペアを生成し、サーバ側のauthorized_keysを更新します。旧鍵はすべて登録解除しておきます。
• その他シークレット類の変更: データベースパスワード、サードパーティAPIキー、OAuthクライアントシークレットなど、開発環境から取得され得るすべてのシークレットを見直し、必要に応じ変更します。

これらの措置は時間との勝負です。攻撃者が情報を得てから悪用するまでの隙を与えないためにも、可能な限り迅速に対応しましょう。組織として多くの秘密情報を管理している場合、事前に緊急ローテーション手順を用意しておくことが重要です。今回は npm と GitHub が主でしたが、他の言語エコシステムやサービスでも同様の事態は起こりえます。被害を最小限に抑えるため、「すべて漏れたもの」と仮定して一斉交換するくらいの覚悟が求められます。

GitHubリポジトリの確認と修復: 不審な公開Repoや悪性ワークフローの削除手順【修復】

次に、攻撃者に改変・作成されたGitHub上の痕跡を取り除きましょう。

• 不審な公開リポジトリの削除: 自分のアカウント配下に「Shai-Hulud」というリポジトリがあれば削除します。その際、残っているdata.jsonなどから漏洩情報を確認し、証跡として記録しておくと後続対応に役立ちます。
• 悪性ワークフローの無効化・削除: 各リポジトリの.github/workflowsを確認し、shai-hulud-workflow.ymlが存在したら直ちに無効化（Actions設定でdisable）し、ファイルを削除します。同様にshai-huludブランチがあれば削除し、関連するプルリクエストもクローズします。
• 公開されてしまったリポジトリの対策: プライベートから公開にされてしまったリポジトリについては、速やかにPrivateに戻すかアーカイブするなどアクセスを制限します。既にクローン取得された可能性もあるため、重要情報が含まれていれば内容変更や無効化を検討します。
• 監査ログの確認: GitHubの監査ログやプロジェクトのリリースログを確認し、攻撃者による操作履歴が他にないか洗い出します。例えば見知らぬユーザー招待や、設定変更が行われていないかなども確認します。

これらの修復措置により、攻撃者が仕掛けたバックドアは概ね取り除かれます。ただし念のため、以降しばらくはリポジトリの更新に注意を払い、不審なコミットがないか監視を続けることをおすすめします。特に大規模組織では一度に全て洗い切れない場合もあるため、自動スキャンツール等を活用して「shai-hulud」のキーワード探知を定期的に行うと良いでしょう。

開発環境の復旧: 漏洩範囲の調査と安全な状態への復帰手順【環境復旧】

技術的な侵入経路を塞いだ後は、開発環境全体の復旧作業に移ります。まず、攻撃によりどこまで被害が広がったかを評価します。

• 侵入経路の確認: どのプロジェクト・どのマシンで悪性パッケージをインストールしたかを洗い出し、その範囲外に感染が広がっていないことを確認します。複数台のPCやCIサーバがある場合、それぞれについて同様の除去・対策を行ったかチェックします。
• システムクリーンインストールの検討: 万が一重要サーバ（CI/CDサーバなど）が侵害された場合、完全にクリーンな状態に戻すためOSから再セットアップすることも選択肢です。被害の深刻度に応じては、PCの初期化とバックアップからの復元も検討します。
• ログ・証跡の保存: 攻撃の痕跡となるログやファイルは今後の分析と再発防止に役立ちます。必要に応じてフォレンジック調査用にイメージを保存しておきます。
• 安全性の確認: 各開発環境が再び通常どおり稼働できることを検証します。特に依存パッケージのバージョンをすべて見直し、悪性バージョンが残っていないことをダブルチェックします。

この復旧フェーズでは、組織内で情報共有を密にし、「どの工程まで完了したか」「残課題は何か」を明確にして進めることが大切です。また、復旧が完了した後も暫くは警戒を続け、ネットワークやシステムの監視を強化しておきます。万全を期すなら、外部のセキュリティ専門家にフォレンジック調査を依頼し、見逃しがないか確認してもらうのも良いでしょう。

再発防止のセキュリティ対策: MFA徹底・依存パッケージ監視とゼロトラスト化の推進【再発防止策】

最後に、今回のような攻撃の再発を防ぐために講じるべきセキュリティ強化策をまとめます。

• MFA（多要素認証）の徹底: npm、GitHubなど開発関連のアカウントには必ず多要素認証を適用します。仮にフィッシング等で資格情報が漏洩しても、不正利用を防ぎやすくなります。組織としてMFAを必須化し、定期的に有効性をチェックしましょう。
• 依存パッケージの監視・固定: サプライチェーン攻撃対策として、プロジェクトの依存関係を常に最新監視します。新しいバージョンが出ても自動更新せず、内容を確認してからアップデートする運用が望ましいです。また、package-lock.jsonでバージョンを固定し、意図しないアップデートを避けるのも有効です。
• 信頼性の高いレジストリの利用: npm公式レジストリ以外にも、企業向けにマルウェアスキャン機能付きのプロキシレジストリ（npm firewallサービスなど）が提供されています。そうしたセキュアなレジストリを経由してライブラリを取得することで、既知の悪性パッケージをブロックできます。
• ソフトウェアサプライチェーンの透明性確保: 依存ライブラリのSBOM（ソフトウェア部品表）を管理し、どのプロジェクトにどのバージョンのパッケージが使われているか即座に把握できるようにします。攻撃発生時に影響範囲を特定しやすくなります。
• ゼロトラスト・モデルの導入: 開発ネットワークでも「信頼しない」を前提に、セグメント分離や最低権限の原則を推進します。たとえば、開発者PCから生産用サーバへの直接アクセスを禁止し、間に認証ゲートウェイを置く、CI環境からインターネットへの発信を制限するなど、仮に一部が侵害されても被害が波及しにくい構造に見直します。
• 従業員教育と演習: サプライチェーン攻撃の事例を共有し、開発者自身が異変に気付けるよう教育します。また定期的にインシデント対応訓練を実施し、初動をスムーズに行えるようにしておきます。

これら対策を講じることで、組織としてのセキュリティ耐性が高まります。特にMFAの有無は攻撃難易度に大きく影響するため、すぐにでも実施すべきです。また、今回の攻撃はオープンソースコミュニティ全体の課題でもあるため、コミュニティ内での情報共有・早期警戒体制にも参加すると良いでしょう。npmやセキュリティ団体が発信するアドバイザリに目を配り、怪しい挙動を発見した際は速やかに報告・協力することが、全体の防御力向上につながります。

以上、Shai-Huludに代表される新手のサプライチェーン攻撃について、その概要から対策まで詳述しました。このような脅威は今後も進化していく可能性がありますが、基本に忠実なセキュリティ対策とコミュニティの連携により、被害を未然に防ぐことができるはずです。開発者・組織ともに一層の警戒と準備を心がけ、安全なソフトウェア開発基盤を維持していきましょう。