暗号資産報酬ファーミング詐欺に関連する、NPMエコシステムのIndonesianFoods自動パッケージ公開インシデント

「Amazonの調査結果は、私たちのチームが分析したIndonesianFoodsワーム活動の実質的な続報です。AIによる自動化を使えば、価値のないパッケージやリスクのあるパッケージを何十万件も大規模に公開することがいかに容易になるかを示しています。開発者は手作業でのレビューに頼るのではなく、依存関係の健全性を自動で保護する仕組みや、振る舞いに基づくスキャンを活用すべきです。ダウンロード数が少ないパッケージ、テンプレートを使い回したコンテンツ、大量公開の急増を検知し、ビルドに取り込まれる前に警告する必要があります。レジストリ運営者も進化しなければなりません。大量アップロード、ハッシュが再利用されたテンプレート、メタデータの健全性に関する異常を事前に検知し、こうしたキャンペーンを発生源で阻止する必要があります。」

— Manoj Nair、Snykの最高イノベーション責任者

要点

2025年11月、セキュリティ研究者は、構造や命名パターンが類似したパッケージがNPMレジストリで大規模に公開されていることを確認しました。初期の報告ではワームの可能性が推測されましたが、この活動は、暗号資産報酬スキームに関連する長期間休眠状態だった自動化スクリプトの残存物である可能性が高いと考えられます。

注: 実環境で悪用されていることは確認されておらず、影響を受けたパッケージが現時点で及ぼすリスクはごくわずかです。

開発者がスパム用スクリプトを作成し、それ自体をスパムの一部としてアップロードしたようです。これは、古い暗号資産報酬ファーミングプロジェクトに関連していた自動公開スクリプトの残存物です。合計で5種類のパッケージがあり、名前をわずかに変えながら数千件に複製されています。悪意のある機能は、パッケージを継続的に公開することだけです。公開スクリプトを含む各パッケージの月間ダウンロード数は、平均わずか18件です。

とはいえ、この事案は、依存関係を細心の注意を払って管理し、信頼できるレジストリ運用を行う必要性が今も続いていることを示しています。

関係するコンポーネントとエコシステム

このインシデントでは、複数のよく似た名前のアカウントから公開されたNPMパッケージ群が関係しています。一貫したコードテンプレート（多くの場合、Next.jsのベース）を使用し、バージョンや名前ごとに構造を少しずつ変えています（-wekto、-riris、-z3nなどの接尾辞）。これらのパッケージは、稼働中のシステムにインストールされて悪用されたというよりも、スクリプトで自動化され、時間をかけて大量に公開されたようです。古い暗号資産報酬キャンペーン（tea.xyz）への参照はありますが、インストール後に悪意のあるコードが実行されたり、自動拡散したりしたことは確認されていません。

インシデントのタイムライン

• 2023年後半：ベースとなるパッケージがいくつか公開される（例：vointea、voinzaril）。当初は無害に見えるWebアプリのコードが含まれていました。

• その直後、大量公開が始まり、名前の接尾辞を変更した類似コードテンプレートを使う派生パッケージが数百から数千件公開されます。

• 数カ月の空白期間：活動が一時停止します。

• 2カ月後：さらに別のシリーズが大量に公開されます（接尾辞のパターンが変化）。

• 2025年11月11日：コミュニティで議論が始まり、最大約44,000件のパッケージが関係している可能性が示されます（実際の大量公開件数はこれより少ない可能性があります）。

• 2025年11月12日：分析により、これらのパッケージは古いキャンペーンの無害な残存物であり、活動中のマルウェアではないことが示されます。

影響を受けたNPMパッケージ

• 特定できる「ルート」パッケージは約5種類です（vointea、voinzaril、およびwekto、riris、z3nの接尾辞を持つバリエーション）。

• 複製されたパッケージの推定数は、数万件ではなく数千件（例：約4,000～5,000件）と考えられます。より大きな数字は、パッケージ内の細かなバージョン違いも含めた場合のものです。

• これらのパッケージの平均ダウンロード数は非常に少なく、通常は月20回未満です。

• 下流の依存関係が侵害されたという報告はなく、既知の悪用チェーンも確認されていません。

• コードの実行には手動での呼び出しが必要で、隠されたリモートペイロードも確認されていないため、一般ユーザーにとってのリスクは引き続き低いと考えられます。

IndonesianFoodsキャンペーンの経緯

従来型のワームやリモート攻撃ではなく、この活動は自動化された公開プロセスのようです。ベースとなるWebアプリのコードテンプレートから複数のバリエーションを生成して公開するスクリプトで、インセンティブや実験を目的としていた可能性があります（例：「tea.xyz」の暗号資産プロモーションとの関連）。

分析の結果、パッケージに有害なペイロードは含まれておらず、多くは定型コードやスタブコードだけであることがわかりました。公開プロセスには自動終了条件がなく、感染したシステムを介して自律的に拡散するのではなく、特定の日に手動で実行されたようです。

活動の概要

• 公開権限を強化されたNPMアカウントを1つ以上使用。

• 数百から数千のバリエーションで、同じコードテンプレートを再利用。

• 利用がごくわずかな、ダウンロード数の少ないパッケージ。

• 高度な隠蔽やポリモーフィック型ペイロードではなく、目立つ形での大量公開。

なぜもっと早く検知されなかったのか？

• パッケージのダウンロード数が少なく、実行時に目立った影響もなかったため、検知を免れていました。

• レジストリのヒューリスティックは、これまで公開数そのものよりも、脆弱性の悪用や悪意のあるインストール後の動作に重点を置いてきました。

• このキャンペーンは半ば放棄されたようで、現在進行中の悪用は確認されていません。

検知とスキャンの戦略

開発者や組織ができること

開発者はSnyk Vulnerability Databaseなどのツールを活用し、新しい依存関係の人気度、メンテナンス状況、セキュリティ、コミュニティに関する指標を評価できます。

また、次のようなツールを使い、依存関係の健全性とコードのリスクの両方を自動スキャンの対象にすることも重要です。

• Snyk Open Source（ソフトウェア構成分析）は、サードパーティライブラリの既知の脆弱性やライセンス上の問題をスキャンします。

• Snyk Code（静的アプリケーションセキュリティテスト）は、独自コードの脆弱性を分析します。

• Snyk ContainerとSnyk IaCは、それぞれコンテナイメージとInfrastructure as Codeの構成をスキャンします。

今回のインシデントに関連して、ダウンロード数が極端に少ないパッケージや、多数のバージョン間でコンテンツが繰り返し使われているパッケージにフラグを立てることができます。また、単一アカウントからの大規模なアップロードの急増や、複数のパッケージ間でのテンプレート再利用を監視することも有効です。さらに、最終公開日、バージョン履歴、メンテナーの数、コミュニティの活動状況など、メタデータに基づくヒューリスティックも活用しましょう。

レジストリチームが監視を強化する方法

アカウントごとの公開件数と公開タイミングに注目し、大量公開のパターンを追跡することで監視を強化できます。また、公開数の急増、バージョンの頻繁な変更、命名パターンの再利用を検知する仕組みも重要です。異なるパッケージ間でファイルハッシュを比較するなどして、テンプレートの再利用をチェックする必要があります。さらに、ダウンロード数、リポジトリのスター数、メンテナーの活動状況といったメタデータの「健全性」指標を、早い段階で評価しましょう。

緩和策と次のステップ

エンドユーザーと組織向け：

1. 不審なパッケージを参照またはインストールしていない場合、ただちに対処する必要はありません。

2. 依存関係グラフを確認し、使われていないパッケージやリスクの低いパッケージを特定して、使用頻度の低い依存関係を削除または隔離しましょう。

3. 新しい依存関係を追加する前に、インストール前に Snyk Advisorを使って、パッケージの健全性とリスク指標を確認しましょう。

4. npqを使用しましょう： npqはオープンソースツールで、ダウンロード数などのヒューリスティックを使用して、この種のパッケージのインストールを防ぎます。

5. CI/CDにポリシーゲートを設定し、ダウンロード数がしきい値を下回るパッケージや、最近コミットされていないパッケージの追加をブロックしましょう。

最後に

NPMレジストリでのこの公開活動は「ワーム」やサプライチェーン攻撃として大きく報じられましたが、私たちの調査により、これは現在進行中のマルウェア感染ではなく、暗号資産キャンペーンに関連した過去の自動化の残存物であることが確認されました。ほとんどのユーザーにとって、差し迫ったリスクは低いと考えられます。

それでも、このインシデントは重要な注意喚起となります。無害に見えるパッケージであっても、管理されていない、メンテナンスが不十分、または出所が不明瞭であれば、サプライチェーンのリスクを招く可能性があります。Snyk AdvisorやSnyk for JavaScriptなどのツールを使い、堅牢な依存関係ポリシーを徹底し、レジストリを適切に監視することで、エコシステム全体のサプライチェーンの健全性を維持できます。