「npmのパッケージって、ダウンロード数が多ければ安全なんじゃないんでしゅか?」
「インストールスクリプトを止めていれば大丈夫でしゅよね?」
ボス!npmの悪意あるパッケージが、週に200万回もダウンロードされてたって本当でしゅか?
本当だ。「indexed-btree」というB-treeライブラリに見せかけたパッケージで、Checkmarxが見つけた。
そんなに使われてたら、普通は安全だと思っちゃうでしゅ…。
それが狙いだ。しかも今回は、インストール時ではなく、ライブラリを使う処理の中で悪意あるコードが動く仕組みだった。これまでの対策をすり抜けてきたわけだ。
開発現場では、ダウンロード数やGitHubの見た目でライブラリを選ぶことも多いはずです。
この記事では、indexed-btreeの手口と、開発組織が見直すべきポイントを解説します。
- 正規ライブラリsorted-btreeに似せたnpmパッケージindexed-btreeが、検出前に週約200万ダウンロードに到達
- 悪意あるコードはインストールスクリプトではなく、BTree.prototype.setメソッドの中に隠されていた
- 関連する10個のパッケージが見つかり、C2にはEthereumのテストネット上のスマートコントラクトが使われていた
サプライチェーン攻撃から開発環境を守るための確認点が分かります。
目次
悪意あるnpmパッケージindexed-btreeの概要
正規のライブラリに似せたパッケージが、長期間にわたって大量にダウンロードされていました。
発見の経緯と影響の規模
セキュリティ企業Checkmarxは、npmで公開されていたindexed-btreeが悪意あるパッケージだったと報告しました(Checkmarx)。
このパッケージは、B-treeやインデックス処理の正規ライブラリsorted-btreeに似せて作られていました。
検出される前には、週に約200万回ダウンロードされていたとされています(SecurityWeek)。
The Hacker Newsによると、最初のバージョンは2026年6月18日に公開され、現在はnpmから削除されています(The Hacker News)。
数カ月にわたり、誰でもインストールできる状態だったとみられます。
関連する10個のパッケージ
Checkmarxは、同じ攻撃に関係するパッケージを合わせて10個確認しています。
主な関連パッケージとダウンロード数は以下のとおりです。
| パッケージ名 | ダウンロード数 |
|---|
| btree-core | 1,951,274 |
| btree-leaderboard | 493,685 |
| btree-range-store | 468,092 |
| ordered-kv-index | 448,184 |
| sliding-score-window | 448,024 |
| btree-time-index | 425,312 |
| priority-slot-queue | 402,860 |
| btree-lru-cache | 372,185 |
| neighbor-key-map | 366,019 |
いずれもデータ構造や並べ替えなど、開発でよく使う機能をうたう名前です。
依存関係に含めていないか、プロジェクトのpackage-lock.jsonなどで確認する必要があります。
攻撃の仕組みとリスク
今回の特徴は、従来の検出方法を前提にした対策をすり抜ける設計にあります。
インストールスクリプトを使わない仕掛け
これまでの悪意あるnpmパッケージの多くは、preinstallやpostinstallといったインストール時のスクリプトで不正なコードを動かしていました。
npm v12ではこうしたライフサイクルスクリプトの実行が制限されています。
indexed-btreeは、悪意あるローダーをライブラリの中核であるBTree.prototype.setメソッドの中に隠していました。
このメソッドは利用者が日常的に呼び出す関数で、特定の条件を満たす呼び出しをきっかけに不正なコードが動く仕組みでした。
Checkmarxは、ライフサイクルスクリプトの制限は続けるべきだとしたうえで、インストール時だけでなく実行時の振る舞いを分析しなければ、この種のパッケージは捕まえられないと指摘しています。
使う処理の中で動くなんて、インストール時のチェックじゃ見つからないでしゅ!
そういうことだ。しかもGitHubのリポジトリには悪意あるコードを置かず、コミット履歴まで作り込んで信用させていた。見た目だけで判断するのは危ういぞ。
窃取される情報とC2の仕組み
不正なコードは、まず感染した端末の情報を集めて外部に送ります。
Checkmarxが報告している動作は以下のとおりです。
- OSのアーキテクチャ、ホスト名、CPU、メモリ、稼働時間などの情報を収集する
- 集めた情報をSlackのチャンネルとTelegramのチャットに送信する
- EthereumのSepoliaテストネット上のスマートコントラクトから、暗号化された第2段階のペイロードを取得する
ブロックチェーン上のスマートコントラクトをC2に使うと、通常のサーバーのように差し押さえて止めることが難しくなります。
Checkmarxの公表時点で、攻撃者は約109ETHを稼いだとみられています。
まとめ
indexed-btreeの事例は、ダウンロード数の多さやGitHubの見た目が安全性の証明にならないことを示しました。
悪意あるコードをインストールスクリプトではなく通常の処理の中に隠すことで、ライフサイクルスクリプトの制限という新しい防御もすり抜けています。
開発組織は、依存関係の確認に加えて、実行時の振る舞いを監視する仕組みを検討する必要があります。
便利なライブラリほど疑われにくい。攻撃者はそこを突いてくる。依存関係は「入れて終わり」ではなく、定期的に棚卸しすることだ。
今日のうちにpackage-lock.jsonを確認しましゅ!
対策の優先度は明確です。以下を今すぐ実施してください。
- プロジェクトの依存関係にindexed-btreeや関連パッケージが含まれていないか、package-lock.jsonなどで確認する
- 含まれていた場合は削除したうえで、その環境の認証情報やトークンの入れ替えを検討する
- 新しいパッケージの導入時は、公開時期や公開者、名前の似た正規ライブラリの有無を確認するルールを設ける