米国のセキュリティメディア「BleepingComputer」は、悪意あるエヌピーエム（npm）パッケージが、インストール時スクリプトを無効化する防御をすり抜け、アプリケーションの実行時に不正処理を行う手口を用いるキャンペーンを報じた。対象となったのは、既存ライブラリ「sorted-btree」を模した偽パッケージ「indexed-btree」であり、開発者やCI環境がパッケージをインストールした段階では不審な挙動を見せない一方、実際にライブラリの機能を呼び出した際に悪意あるコードが動作する仕組みとなっていた。
事案の詳細
エヌピーエム（npm）は、ジャバスクリプト（JavaScript）/ノード.js（Node.js）向けのパッケージ（部品）を配布する仕組みで、開発現場で広く利用されています。従来、悪用が多い手口の一つが「インストール時に自動実行されるスクリプト（install script）」で、環境情報の窃取や追加ペイロードの取得などが行われることがありました。そのため、組織によってはインストール時スクリプトを抑止する設定を有効にし、リスク低減を図っています。
今回報じられたキャンペーンでは、こうした“インストール時に動く処理”の監視・制限を前提にした防御を回避し、パッケージが実際に使われた「実行時（runtime）」に悪意ある動きを起こす手口が用いられていました。問題の「indexed-btree」パッケージは、正規ライブラリ「sorted-btree」に似せたAPIを提供しつつ、その内部の BTree.prototype.set() メソッドにローダーコードを潜ませることで、特定のキー値が渡されたときに初めて悪意ある処理を起動するよう設計されています。つまり、インストールの瞬間には目立つ挙動を見せず、アプリケーションの起動や特定の関数呼び出しなど、利用のタイミングで不正コードが動く可能性が実際の事例として示された形です。
このローダーは、開発者やCIサービスの権限のもとで環境変数の読み取り、アクセス可能なファイルの列挙、外部サービスへの接続、子プロセスの起動などを行えるため、インストール時スクリプトを止めていても安心できない点が本件の要点です。開発・ビルド環境（CI/CDを含む）や運用環境で、依存関係として取り込んだパッケージがアプリケーションの一部として読み込まれると、そこで初めて攻撃が成立し得ます。こうした実行時発火の手口は、導入時のチェックをすり抜けやすく、被害の発見が遅れるリスクがあります。
日本への影響
日本の中小企業でも、Webサイト、業務用Webアプリ、EC、社内ツールの外注開発や内製開発でノード.jsとnpmを利用するケースは珍しくありません。海外で公開された悪意あるパッケージは国境に関係なく配布され、外注先や利用しているSaaSの開発基盤、社内の開発PC・ビルドサーバー経由で取り込まれる可能性があります。今回の「indexed-btree」のように、インストール時スクリプトを回避しつつ、実行時に環境情報や認証情報を窃取したり、外部の攻撃者インフラへ通信したりするタイプのマルウェアは、インターネット経由で広く拡散し得るため、日本企業も影響を受ける可能性があります。
「インストール時スクリプトを止めているから大丈夫」という前提が崩れるため、依存関係全体の管理不足が、そのままサプライチェーン（部品の連鎖）リスクとして日本企業にも波及します。特に、外注開発や兼任体制で依存関係の更新・検証が後回しになっている環境では、実行時に動くマルウェアの検知が遅れ、開発者アカウントやCI環境からの情報漏えい・不正アクセスに発展するおそれがあります。
対策・今後の展望
- インストール時スクリプト無効化だけに依存しない：それは有効な一手でも万能ではありません。npmや関連ツールの設定で
--ignore-scriptsなどを用いてインストール時スクリプトを抑止しても、今回の「indexed-btree」のように、通常のモジュールコードや特定の関数呼び出しに紛れ込んだ不正コードが実行時に動くことがあります。実行時に動く不正コードも想定し、コードレビュー、静的解析、挙動監視など別の防御を組み合わせます。 - 依存関係の棚卸しと固定：利用中のパッケージとバージョンを整理し、ロックファイル等で意図しない更新を抑えます。悪意あるパッケージが後から差し替えられたり、依存チェーンの深いところに追加されたりするリスクを抑えるため、更新時は差分確認の手順を設け、信頼できるバージョン範囲を明示的に管理します。
- 信頼できる取得経路の整備：社内レジストリ（社内向け保管場所）やプロキシの活用、許可リスト運用などで、参照できるパッケージを絞ります。外部のnpmレジストリから直接取得するのではなく、検証済みパッケージのみを社内ミラーに保持し、そこからインストールすることで、悪意あるパッケージが紛れ込む確率を下げることができます。
- 開発・ビルド環境の監視：ビルドサーバーや開発端末で、不審な外部通信、認証情報の持ち出し、未知プロセスの実行がないかを監視します。実行時に発火するマルウェアは、インストール時には検知されない一方で、依存ライブラリを利用したタイミングでC2サーバーへの通信や追加ペイロード取得を行うため、ネットワーク監視やEDRなどのランタイム監視が重要になります。
- 最小権限と秘密情報の分離：ビルドや実行環境の権限を必要最小限にし、APIキー等の秘密情報は環境変数・金庫化などで管理して漏えい時の影響を抑えます。悪意あるnpmパッケージが環境変数や設定ファイルから秘密情報を窃取する事例が複数報告されているため、開発・CI環境における認証情報の扱いを見直し、機密度の高い情報を直接コードや汎用環境に置かない設計が求められます。
CSRIからの現場アドバイス
【現場で何が起きているか】MDRや診断の現場では、外注・兼任体制で依存関係の管理が後回しになり、海外発の不正パッケージがCIや開発PC経由で混入する形を多く見ます。インストール時の挙動だけを見て安心し、稼働後の通信やプロセス監視が薄い企業ほど発見が遅れがちです。今回報じられた「indexed-btree」のように、インストール時はクリーンに見えるパッケージが、開発者やCIサービスの権限で実行時に不正処理を行うケースが現実に確認されています。
【平易な解説】例えるなら、納品時は無害に見える部品が、使い始めた瞬間に勝手に別の動きをするようなものです。つまり「入れたときに怪しくない」からといって安全とは限らず、実際に動かしたタイミングで情報を盗まれる可能性がある、ということです。npmのパッケージも、インストール時のチェックだけでは不十分であり、ライブラリを呼び出したときに何をしているかまで意識する必要があります。
【今週中にできること】まず利用中のnpm依存関係とロックファイルの有無を確認し、勝手に更新されない状態にします。次に外注先・開発担当へ「インストール時対策だけでは不十分で、実行時の監視も必要」であり、通常の関数呼び出しやモジュール初期化の中に悪意あるコードが潜む可能性があることを共有します。最後にビルドサーバーの外部通信先と権限を点検し、不要な権限・不要な通信を減らしてください。これにより、今回のような実行時マルウェアが活動できる範囲と、情報漏えい時の影響を最小限に抑えることが期待できます。
参照: Malicious npm packages evade install-script defenses at runtime