40件のnpm偽装パッケージがWSLの境界を越えてWindowsへ侵入 — 22MBのRust製ステーラーをメモリ展開、CloudSEKが「BRIDGEHEAD」を分析

CloudSEKは2026年8月20日、npmレジストリで40件の偽装パッケージがWindows Subsystem for Linux（WSL）の境界を越えてWindowsホスト側で暗号資産窃取を行うキャンペーンを「BRIDGEHEAD」と名付けて公表した。報告したのは同社のVikas Kundu氏で、40件のパッケージはchalkやaxios、commander、lodash、react、typescriptといった利用者の多いライブラリの綴りを1文字変えるなどのタイポスクワッティングで、2026年8月16日02:48から02:56 UTCの約8分間に一斉公開され、同日04:07から04:12 UTCまでの約84分間で削除された。しかし攻撃の本体であるペイロードはnpm外のGitHub上に置かれており、削除後も約39時間生存したとCloudSEKは報告している。

使い捨ての「運び屋」と残存する本体

CloudSEKは、このキャンペーンが寿命の異なる2層で構成されていたと説明する。npm側の40件は「騒がしく、安価で、使い捨て」の運び屋で、実際のペイロードはGitHubアカウント「bebra z1」が2026年8月15日03:19 UTCに公開したリリース資産 main.exe（22MB）だった。npmパッケージが削除された後もGitHub資産は生存し、CloudSEKの観測では2026年8月17日01:50 UTC時点で119件だったダウンロード数が同日18:49 UTCには173件へと17時間で54件増加した。アカウント全体が404を返したのは同日23:12 UTCで、npmの削除だけでは武器が残る構造だったと同社は指摘している。

タイムラインを整理すると、ペイロードの公開（8月15日）が最初のnpm公開（8月16日02:28 UTCのテストパッケージ）に約23時間先行しており、事前に本体を配置してから運び屋をばらまく段階的な準備がうかがえるとCloudSEKは分析している。

感染の流れ — WSL検出からWindows実行へ

いずれのパッケージも scripts/postinstall.js にインストールフックを持ち、インストール時に自動実行される。CloudSEKが復元した実行順は次のとおりである。

ステージ1: 運び屋の実行 パッケージ名は人気ライブラリの1文字違いや転置、あるいは正規名にそれらしいサフィックスを付けた名前空間詐称で、いずれもバージョン1.0.0で公開された。

ステージ2: インストール時のビーコン スクリプトはハードコードされたC2（193.70.34.101:20099、OVH、パス /vote）へビーコンを送る。IPアドレスは配列を結合して実行時に組み立てるため、単純な文字列検索では検出されにくい。スクリプトはNodeのバージョンやアーキテクチャなどの詳細なホスト情報を収集するが、実際に送信するのは Windows / MacOS / Linux の粗いラベルのみで、詳細は破棄されるとCloudSEKは述べている。

ステージ3: WSLゲート Windowsへ展開する前に、スクリプトは自身がWindowsに到達可能な位置にいるかを確認する。process.platform が win32 ならそのまま対象とし、Linuxの場合はWSLか否かを3つの方法で判定する。具体的には環境変数 WSL_DISTRO_NAME または WSLENV の存在、/proc/version と /proc/sys/kernel/osrelease に microsoft や WSL という文字列が含まれるかを確認する。WSLはLinuxシェルとWindowsホストを直接つなぐ扉であり、CloudSEKは「開発者が別々の部屋だと考えがちなLinuxシェルと、ブラウザや認証情報、ウォレットを置くWindowsデスクトップの間にある扉だ」と表現している。

判定でWSLまたはネイティブWindowsと判断された場合、スクリプトは静的なXORキーで難読化されたPowerShellコマンドを復号し、GitHub上の main.exe を一時ディレクトリへダウンロードしてウィンドウを出さずに起動する。ネイティブWindowsではPowerShellを使わずNode.jsの標準ネットワーク機能で取得・起動するため、PowerShellの実行だけを監視する検出では見逃されると同社は指摘している。

22MBのラッパーとメモリ内展開

ダウンロードされる main.exe はRustで書かれた22MBのWindows実行ファイルだが、CloudSEKの静的解析によると実行コードは265KB（約1%）に過ぎず、残る98.6%は16進テキストで書き出された約11MBの暗号化ペイロード（22,638,592文字）で占められる。ラッパーはこのテキストをバイト列へ戻し、改変されたChaCha20（ちやちや・にじゅう）という暗号アルゴリズムで復号して自身のプロセス内で実行する。二次的な実行ファイルをディスクに書き出さず、子プロセスも生成しないため、ファイル作成や親子プロセスを監視するだけのエンドポイント対策では検出が困難だと同社は説明している。

CloudSEKが隔離されたWindows環境で動的解析したところ、ペイロードは実行前に外部サービスへ問い合わせて被害者の公開IPを指紋採取し、すべての通信でTLS証明書を検証して研究者による通信の横取りを妨げた。メモリダンプからは、被害者アカウント向けに展開済みの3つの標的リストが回収された。

• 暗号資産ウォレット26種 — Electrum、Exodus、BitPay、Coinbase Walletなどデスクトップウォレットのパス
• Chromium系ブラウザ — Microsoft EdgeやBraveの Local State や認証情報データベース、Cookie、オートフィル情報
• Telegram Desktop — パスワード不要でアカウント乗っ取りにつながるセッションディレクトリ

解析機に存在しないBrave向けパスも含まれていたことから、これらはハードコードされた標的リストであるとCloudSEKは判断している。窃取データとハードウェアプロファイルは匿名のファイル共有サービス gofile.io へマルチパートで送信された。正規の公共サービスを経由するため、犯罪ドメインのテイクダウンのような方法では阻止できないと同社は指摘している。

CloudSEKが推奨する対策

CloudSEKは、npmの削除だけではGitHub上のペイロードとgofile.ioへの送信経路が残存した点を重視し、開発パイプライン全体での対策を推奨している。同社が報告書で示した主な対策は次のとおりである。

• プライベートプロキシレジストリの利用 — タイポスクワッティングを自動検出するプロキシでパッケージを検証し、未知の出所のロックファイルを信頼しない。
• WSL設定の監査 — LinuxシェルからWindowsバイナリが自動実行される経路を制限し、WSLとWindows間の相互実行ポリシーを見直す。
• 匿名アップロード先への通信監視 — 開発端末から匿名ファイル共有サービスへの想定外の送信を検知する。
• 認証情報の保護 — ブラウザやウォレットの認証情報を多要素認証で保護し、不正なパッケージ実行を完全な認証情報漏えいとみなして資格情報をローテーションする。

CloudSEKは、今回の40件は検出から約84分で削除されたものの、GitHub資産のダウンロード数が削除後も増加したことを挙げ、レジストリの削除だけでは供給網攻撃を止められないと警告している。開発組織はパッケージの正規性検証とWSL境界の制御をあわせて強化する必要があると同社は呼びかけている。

出典

• CloudSEK「BRIDGEHEAD: An npm typosquatting campaign that crosses from WSL into Windows to plant a crypto-wallet stealer」（2026年8月20日） https://www.cloudsek.com/blog/bridgehead-npm-typosquatting-wsl-windows-crypto-wallet-stealer