週1億DLのaxiosに北朝鮮バックドア ─ UNC1069による3時間のサプライチェーン汚染

3時間で世界中の開発者が感染源になりかけた

2026年3月31日 00:21 UTC。GitHubの画面に、axiosの新しいリリースが静かに現れた。

バージョン 1.14.1 と 0.30.4。リリースノートに不審な点はない。しかし実際には、このコードは北朝鮮の国家支援APTグループ「UNC1069」が仕込んだバックドアを含んでいた。

axiosは週間ダウンロード数1億回、全クラウド・コード環境の約80%が直接・間接的に依存するJavaScriptのHTTPクライアントライブラリだ。3時間20分後、セキュリティコミュニティが異変を察知し悪意あるバージョンは削除された。しかしGoogleのThreat Intelligence Group（GTIG）は「その3時間の影響を過小評価してはならない」と警告する。

攻撃者はどうしてaxiosを「乗っ取れた」のか

GitHubリポジトリは普通なら安全だ。しかし今回、攻撃者はGitHubのセキュリティをほぼ完全に迂回した。

Googleとmicrosoftの分析によれば、UNC1069は次の手順を踏んだ。

Step 1: メンテナーアカウントの侵害 まず、axiosの特定のメンテナーアカウントを乗っ取り、登録されたメールアドレスを攻撃者の制御下にあるアドレスへ変更した。これにより、そのアカウントは正規の2FAなどのリカバリー手段が使えなくなる。

Step 2: 長期間有効なアクセストークンの悪用 axiosはnpm publishコマンドを使ってパッケージを公開している。攻撃者はアカウントに紐付いた長期間有効なnpmアクセストークンを発見し、それを使ってnpm CLIから直接パッケージを公開した。

ここが重要な点だ。axiosのCI/CDはGitHub ActionsのOIDC（OpenID Connect）トークンを使用してnpmへ公開する、セキュアな仕組みを採用していた。しかし攻撃者はGitHubを経由せず、直接npmのAPIに長期トークンを使ってpublishした。GitHub Actions経由ではないため、リポジトリのコミット履歴にも変更が残らない。

Step 3: 悪意ある依存関係の注入 悪意あるバージョンのaxiosは、plain-crypto-jsという難読化された新しいパッケージを依存関係に追加していた。このパッケージが実質的なドロッパーで、インストール時（postinstallフック）にWAVESHAPER.V2を展開する。

WAVESHAPER.V2 ─ 北朝鮮の進化したバックドア

WAVESHAPER.V2はGTIGが2024年後半に最初に追跡し始めたマルウェアファミリー「WAVESHAPER」の第2世代だ。クロスプラットフォーム対応（Windows・macOS・Linux）が特徴で、UNC1069の過去の攻撃にも使われている。

確認されている主な機能は以下の通りだ。

• 持続性の確立: OSのスタートアップメカニズムへの登録（systemdサービス、Windowsスケジュールタスク等）
• 暗号化通信: C2との通信はTLS + カスタム暗号化でラップ
• 認証情報収集: ブラウザの保存パスワード、SSHキー、AWS/GCPの認証情報ファイルを検索・外部送信
• ファイル操作: 任意ファイルのアップロード/ダウンロード
• プロセス実行: リモートからの任意コマンド実行（シェルアクセス）
• ラテラルムーブメント支援: 内部ネットワークのスキャンと結果の送信

UNC1069 ─ 金融とDeFiを狙う北朝鮮グループ

UNC1069は2018年以降活動が確認されている北朝鮮連動の金銭的動機を持つAPTグループだ。GTIGは、UNC1069がLazarus Groupの傘下ないし関連クラスタであると評価している。過去の標的は主に仮想通貨取引所、DeFiプロジェクト、ブロックチェーンゲーム会社だった。

今回axiosのような汎用インフラを攻撃したことは、UNC1069の戦術拡大を示している。仮想通貨企業を直接狙うよりも、その企業が依存するOSSサプライチェーンを汚染する方が、より広範かつ持続的な足場を得られると判断したと考えられる。

Microsoftの分析では、悪意あるバージョンがインストールされた環境の相当数がAWS・GCP・Azureのクレデンシャルファイルを保持するCI/CDランナーやコンテナ環境だったと報告されている。クラウド認証情報が流出した場合、そこから仮想通貨関連のシステムへのアクセスを試みるというのがUNC1069の典型的な動線だ。

サプライチェーン攻撃への根本的な対策

今回の事件は、著名なOSSライブラリが「信頼のアンカー」にならないことを再確認させた。

npm/パッケージマネージャー側の対策

# インストール済みパッケージの整合性チェック
npm audit

# package-lock.jsonを厳密に使用し、lockfileなしのインストールを禁止
npm ci  # npm install ではなく npm ci を常に使う

# 依存ツリーのスナップショット比較（予期しない追加依存を検出）
npm ls --all > deps-snapshot.txt

組織レベルの対策

1. プライベートレジストリの運用: Nexus・Artifactoryなどのプロキシレジストリを使い、全パッケージの通過点を設けてスキャンする
2. SBOMの維持: Software Bill of Materialsを常に最新に保ち、侵害ライブラリの影響範囲を即座に把握できるようにする
3. CI/CDの権限最小化: ビルドランナーが本番システムやクラウドリソースに直接アクセスできないよう、OIDC短命トークンのみを使用する
4. npm provenance: npm 9以降で利用可能なprovenance（Sigstore署名）を検証し、GitHubのコミットに紐付かないパッケージを拒否する
5. 長期トークンの棚卸し: npm・PyPI・GitHub ActionsなどCI/CDで使用するトークンの有効期限を定期的に見直し、不要な長期トークンを削除する

npm ciが「npm installより安全」と言われるのは、package-lock.jsonにある通りのバージョンしかインストールしないからだ。しかし今回のように、攻撃者がlockfileが更新される前のタイミングで悪意あるバージョンを公開した場合は防げない。最終的には多層的な防御が必要だ。

---

参考情報

• Google Cloud Blog: North Korea Threat Actor Targets Axios NPM Package in Supply Chain Attack
• Microsoft Security Blog: Mitigating the Axios npm supply chain compromise
• Bloomberg: Hackers Compromise Axios, Widely Used Software Development Tool
• Tenable: FAQ About the Axios npm Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069
• SecurityWeek: Axios NPM Package Breached in North Korean Supply Chain Attack