npm 悪性パッケージの 4 つの隠蔽手法：難読化から遅延起動まで · Insights

攻撃側が解くべき問題

公開レジストリに悪性パッケージを置くとき、攻撃者が直面する中心的な矛盾があります。インストールされる程度には正常に見えなければならず、同時にどこかの時点で正常でないことをしなければならないという点です。

初期の汚染はかなり粗いものでした。インストールスクリプトに curl を一行書き、~/.ssh をまとめて外部へ送る——目視でも分かる水準です。自動スキャンが普及するにつれ、この種の検体は数時間と生き残れなくなりました。そこで手法が進化します。目的はただ一つ、発見される時点を先送りすることです。

以下の 4 つが現在最も一般的な技術路線であり、しばしば組み合わせて使われます。

1. 難読化：人にも機械にも読ませない

最も直接的な発想は、悪性ロジックを読めなくすることです。よくある形態は、多層の base64 符号化、文字列配列の分解と再構成、eval と動的プロパティアクセスの併用、そして重要な文字列を文字コード配列に分解して実行時に連結する手法です。

典型的な検体では、ソースコード上に http や exec といった語がまったく現れません。それらは実行時に組み立てられるためです。

静的検査が見逃す理由：特徴文字列やキーワード照合に基づくスキャンは、連結と符号化の前ではほぼ無力です。そして難読化それ自体を悪性と断定することもできません。正当な圧縮成果物の多くも難読化されているからです。

有効な兆候：難読化の度合いがパッケージの用途と釣り合っていない（小さなユーティリティに三層の符号化は不要）、eval と動的な文字列組み立ての併用、ビルド成果物とソースリポジトリの不一致。

2. 遅延起動：インストール時には何もしない

第二の発想は時間を引き延ばすことです。悪性コードはインストール時には完全に沈黙し、数日後、特定の日付、あるいは一定の利用回数を超えた時点で初めて起動します。

これは自動審査の観測窓を正確に狙った手法です。多くのスキャンは公開直後の短時間に行われ、人の審査もインストール時点の挙動しか見ないことが大半です。起動する頃には、そのパッケージはすでに数千のロックファイルに載っています。

有効な兆候：機能と無関係な時刻判定、初回実行時に計数目的でローカル状態ファイルを書き込む挙動、遅延実行のロジックに包まれたネットワーク要求。

3. 環境検知：観測されていると分かれば死んだふりをする

さらに進むと、悪性パッケージは「今、自分は解析されているか」を能動的に判定します。判定項目には、CI 環境かどうか（環境変数の確認）、コンテナや仮想マシン上かどうか、デバッガの有無、ホスト名やユーザー名がサンドボックスの特徴と一致するか、出口通信がプロキシされているか、などが含まれます。

解析環境だと判定されれば、パッケージは完全に正常に振る舞います。これは動的サンドボックス解析を直接無力化します。サンドボックスが見るのは無害な挙動であり、実際の開発者の端末では別のことが起きています。

有効な兆候：機能と無関係な環境情報を大量に読み取る、既知のサンドボックス指紋との照合ロジックが存在する、環境によって挙動が一致しない。

4. 段階的ロード：最初のパッケージは清潔

最も発見しにくい種類です。公開されるパッケージ自体は完全に無害で、悪性ペイロードは実行時に遠隔から取得されます。

最初のバージョンは本当に使えるツールで、ダウンロード数と信頼を積み上げます。その後のあるマイナー版に「設定サーバーから更新を取得する」という一行が加わり、以降、悪性ロジックはパッケージではなくサーバー側に存在します。攻撃者はいつでも切り替えられ、特定の対象にだけ配信でき、解析可能な検体を残しません。

これが最も難しい理由：パッケージの静的な内容は常に清潔です。ソースを百回監査しても問題は見つかりません。問題がソースの中にないからです。

有効な兆候：実行時に宣言のないネットワーク要求を発する、外部からコードを取得して実行する、要求先がパッケージの機能とまったく関係しない。

3 層の防御

この 4 種類に単一の手段では対応できません。組み合わせが必要です。

第 1 層：導入時の静的審査とメタデータ確認。 コードスキャンに加え、実際にはメタデータの信号のほうが有効なことが多くあります。パッケージの年齢、維持者の履歴、ダウンロード数の異常な跳ね上がり、人気パッケージとの名称の類似度、維持者アカウントの最近の変更。多くの汚染パッケージは、コード解析に入る前にメタデータで綻びを見せます。

第 2 層：挙動分析。 統制された環境で実際に導入・実行し、ファイルアクセス、プロセス生成、ネットワーク接続を観察します。環境検知への対抗としては、解析環境を可能な限り実際の開発端末に近づける必要があり、これ自体が継続的な攻防になります。

第 3 層：出口通信の監視。 これは最後の受け皿であり、段階的ロードに対して最も有効な層です。悪性コードがどれほど深く隠れていても、最終的にはデータを外へ送る必要があります。開発環境とビルド環境の出口許可リストは、「感染した」を「感染したが損害は出ていない」に変えます。

企業への実務的な提案

まず内部レジストリミラーを構築します。 すべての依存関係を内部ミラー経由で取得し、許可リストと導入審査を組み合わせます。この一手は構造的な効果を持ちます。汚染、依存混同、存在しないパッケージという 3 種のリスクを同時に緩和するからです。

新規導入の依存関係に観察期間を設けます。 公開されて日が浅く、ダウンロード数がまだ伸びている最中のパッケージは、本番の依存関係に入れる前にしばらく待つ価値があります。時間は最も安価なフィルタです。

ロックファイルの変化を注視します。 依存関係の更新は明示的な判断であるべきで、ビルド時の偶発事象であってはなりません。ロックファイルの変更はすべてコードレビューに現れるべきです。

追跡可能性を保ちます。 あるパッケージに問題が報じられたとき、「どのプロジェクトが、どのバージョンを、いつ導入したか」に数分で答えられる必要があります。完全な依存関係台帳と継続的な監視の価値は、まさにここにあります。

汚染はなくなりません。公開レジストリの開放性こそが生態系の繁栄の前提だからです。変えられるのは、発見の速さと影響の範囲です。

---