- 攻撃者がAxiosの主要メンテナーのnpmアカウントを侵害し、インストール時にクロスプラットフォームのRATをデプロイする架空の依存関係であるplain-crypto-jsを含むバージョン1.14.1と0.30.4をリリースした。
- このマルウェアはC2サーバー（sfrclak[.]com）に接続し、Windows、macOS、Linux用の特定のペイロードをダウンロードして、システム偵察、定期的なビーコンの維持、場合によっては永続的なアクセスを確立しました。
- Googleや他の研究者らが北朝鮮の攻撃者UNC1069によるものと断定したこの攻撃は、約3時間の攻撃機会と、管理者に対する高度なソーシャルエンジニアリング攻撃を組み合わせ、認証情報を盗み出したものだった。
- 影響を受けるバージョンをインストールできた組織は、対策を講じ、RAT（リモートアクセスツール）の痕跡を捜索し、認証情報をローテーションし、Axiosの安全なバージョンを固定し、サプライチェーン、CI/CD（継続的インテグレーション/継続的デリバリー）、および依存関係管理のコントロールを強化することを約束しなければなりません。
JavaScript開発コミュニティは、ライブラリの脆弱性問題によって、依存関係に対する信頼度を再考させられるような、恐ろしい出来事を経験したばかりだ。エコシステムで最も広く使われているHTTPライブラリの一つであるAxiosが、npm上で改ざんされ、一見正規版に見えるバージョンを通じてリモートアクセス型トロイの木馬（RAT）が拡散された。この事件はわずか数時間で収束したが、ソフトウェアサプライチェーンが多くの人が考えていたよりもはるかに脆弱な状態にあることを浮き彫りにした。
深刻な問題は、攻撃者が週に数千万回、あるいは数億回もダウンロードされるパッケージにマルウェアを紛れ込ませたことだけではありません。本当の問題は、彼らがメインメンテナーのnpmアカウントを乗っ取り、一見正常に見える「公式」バージョンを公開し、Axiosのソースコードを一行も変更しなかったことです。悪意のある動作はすべて、攻撃のために特別に設計された架空の依存関係の中に隠されていました。
Axiosがnpmに注力するようになった経緯
この事件の深刻さを理解するには、まず侵入経路から見ていく必要があります。攻撃者は、Axiosの主要メンテナーである「jasonsaayman」のnpmアカウントを乗っ取り、関連付けられたメールアドレスを、自身が管理するProton Mail上のアドレスに変更しました。それ以降、攻撃者はまるで自分がメンテナーであるかのように、パッケージの新しいバージョンを自由に公開できるようになったのです。
彼はその認証情報を使って、Axiosの悪意のあるバージョン1.14.1と0.30.4の2つをアップロードし、プロジェクトの主要2つのブランチを網羅した。アップロードはわずか39分間隔で行われ、StepSecurityの分析によると、GitHub Actionsに基づく通常のCI/CDパイプラインを完全に迂回し、古典的な長期有効トークンを使用してnpmから直接行われた。
最終攻撃の18時間前、攻撃者はすでに悪意のある依存関係に関連する「クリーンな」バージョンをnpmレジストリに公開していた。この事前準備は履歴を生成するとともに、攻撃時に全く新しいパッケージが出現した際に一部の自動チェックが作動するのを防ぐためのものだった。
驚くべきことに、攻撃者はAxiosのソースコードを改変したり、GitHubリポジトリに目に見える変更を加えたりしなかった。実際、バージョン1.14.1と0.30.4はGitHubには対応するコミットやタグがなく、npmにのみ存在していた。決定的な違いは、レジストリに公開されたパッケージの依存関係ファイルにあった。
通常、Axios は follow-redirects、form-data、proxy-from-env の 3 つの依存関係のみを宣言します。しかし、不正なバージョンでは、プロジェクトに以前は存在しなかった 4 番目の依存関係、plain-crypto-js バージョン 4.2.1 が現れました。この架空のライブラリは Axios のコードベースのどこにも使用されていませんでしたが、npm、pnpm、または同様のツールでパッケージをインストールする際に自動的に実行されるインストール後スクリプトが含まれていました。
plain-crypto-js: RATによってデプロイされた偽の依存関係
攻撃の鍵は、その追加の依存関係にあった。plain -crypto-jsは、「nrwise」というユーザー（Proton Mailのメールアドレスも使用）によってnpmに公開されており、その唯一の目的は、Node.jsで難読化されたインストール後スクリプト（setup.js）を実行することだった。このスクリプトはドロッパーとして機能し、マルウェアの第2段階の初期インストーラーとして動作した。
ポイズニングされたバージョンの Axios をインストールすると、npm のインストール後ライフサイクルによって、開発者による特別な操作なしに plain-crypto-js コードが自動的にトリガーされました。ドロッパーは、sfrclakcom ドメインでアクティブになっているコマンド アンド コントロール (C2) サーバー (ポート 8000 でリッスン) に接続し、影響を受けたマシンのオペレーティングシステムに固有のペイロードをダウンロードしました。この動作は、ネットワーク トラフィック分析によって特定できます。
StepSecurityの研究者や他の分析チームは、非常に巧妙な動作について説明している。悪意のあるペイロードを実行した後、ドロッパーは痕跡を消去した。具体的には、postinstallスクリプトを削除し、package.jsonファイルを「クリーンな」バージョンに置き換え、一見無害に見えるnode_modulesファイルを残した。このようにして、その後の手動検査では、Axios内部に悪意のあるコードが直接見つかることはなかった。
操作を特定するための唯一の信頼できる手がかりは、ロックファイル（package-lock.json、pnpm-lock.yaml、yarn.lock）と特定のバージョンの存在でした。axios 1.14.1 または 0.30.4 と plain-crypto-js 4.2.1、さらに一部の分析で関連付けられた中間番号（4.2.0、4.2.2）を持つこのパッケージの 2 つのバージョンです。一方、Socket は後に、同じマルウェアがパッケージ @shadanai/openclaw（さまざまなバージョン 2026.3.xx）と @qqbrowser/openclaw-qbot（0.0.130）を通じても配布されていることを検出しました。ハニーポットなどのセキュリティ技術も、同様のキャンペーンの特定に役立ちます。
クロスプラットフォームRAT：Windows、macOS、Linuxに注目
実行されると、setup.jsスクリプトはオーケストレーターとして機能し、オペレーティングシステムを検出し、プラットフォーム固有の攻撃経路をたどった。この攻撃キャンペーンは明らかに事前に準備されていた。StepSecurityによると、攻撃者はシステムごとに1つずつ、3つの異なるペイロードを事前にコンパイルしていたという。
macOSシステムでは、インストール後の処理でAppleScriptが起動され、sfrclakcom:8000サーバーからトロイの木馬化されたバイナリがダウンロードされました。このバイナリは/Library/Caches/com.apple.act.mondパスに保存され、実行可能になるようにパーミッションが調整された後、/bin/zshを使用してバックグラウンドで起動されました。RATが起動すると、フォレンジック分析をさらに困難にするため、AppleScript自体が削除されました。
Windows マシンでは、マルウェアはシステムの PowerShell バイナリを検出し、それを %PROGRAMDATA%\wt.exe にコピーして Windows ターミナルに偽装し、一時的な VBScript を生成しました。この VBScript は C2 サーバーに接続して追加の PowerShell RAT スクリプトをダウンロードし、実行した後、ダウンロードしたファイルを削除しました。さらに、Windows 版は、マルウェアがログインするたびに自身を取得できるダウンロードルーチンを含む %PROGRAMDATA%\system.bat ファイルを作成し、永続性を確保するために Windows レジストリに実行キーを追加しました。
LinuxやmacOS以外のUnix系システムでは、ドロッパーはNode.jsのexecSyncを使用してシェルコマンドを起動し、sfrclakcomからPythonスクリプトをダウンロードして/tmp/ld.pyとして保存し、nohupで実行してバックグラウンドで実行し続けました。Windowsとは異なり、この亜種は堅牢な永続化メカニズムを備えていなかったため、より迅速なデータ漏洩を目的としたアプローチ、あるいは後続コマンドによる一時的な永続化の展開が示唆されました。
SafeDepとElastic Security Labsは、第2レベルのペイロードを分析し、macOS（C++ Mach-Oバイナリ）とLinux（Pythonスクリプト）向けのRATが、同じコマンドセット、C2プロトコル、メッセージ形式、および動作特性を共有していると結論付けました。この種の分析は通常、サンプルとIOCの相関関係を容易にするVirusTotalなどのスキャンサービスに依存しています。
いずれの場合も、侵害された各ホストは直ちにシステム偵察を実行しました。ユーザーディレクトリ、ドライブルート、アクティブなプロセス、その他のメタデータなどが収集されました。この情報はコマンド＆コントロールサーバーに送信され、エージェントは約60秒間のビーコンループを維持し、追加スクリプトの実行やバイナリのメモリへの注入など、新たな指示を待ちました。
暴露期間、目的、および北朝鮮への帰属
悪意のあるバージョンのAxiosは、慎重に選ばれた時間帯に約3時間、npm上で公開されていました。侵害されたパッケージは日曜日の深夜直前（防御側の対応時間を最大限に確保できる時間帯）に公開され、セキュリティ企業が当局に異常な挙動を通報したことで、月曜日の早朝には事態は収束しました。
その比較的短い期間に、Huntressは少なくとも135のシステムが攻撃者のサーバーに接続していることを検出した。Axiosは毎週80万～100億件以上のダウンロードを記録しており（様々な情報源によると、期間によっては300億件を超えることもある）、この数字は氷山の一角に過ぎず、データを公開している分析会社の目に留まったシステムに限られていると考えられる。
Googleは、脅威インテリジェンスチームを通じて、この攻撃はUNC1069という名称の北朝鮮の攻撃者によるものと断定した。Elastic Security Labsは、macOSに仕掛けられたRATと、Mandiantが発見し、同じ脅威グループに関連付けられているC++バックドアであるWAVESHAPERとの間に強い類似性があることを発見し、この仮説を裏付けた。
Googleのアナリストは、北朝鮮関連のグループが長年にわたりサプライチェーン攻撃や仮想通貨窃盗を専門としてきたことを強調した。その手口は一貫しており、開発インフラ、広く利用されているライブラリ、あるいは信頼性の高いソフトウェアを侵害した後、高価値資産、秘密鍵、認証情報などを管理する標的へと横方向に攻撃を仕掛けていく。
複数の報告書では、攻撃の巧妙な構成と設計から、綿密に連携したチームの存在が示唆されていると指摘されている。具体的には、同一のRAT（PowerShell、C++、Python）を3つのバージョンで並行して実装し、一貫したC2プロトコルを使用し、すべてのバージョンでほぼ同一の動作を示し、痕跡を残さないための明確な自己消去戦略を採用していた点が挙げられる。Elastic社は、こうした一貫性は、単一の開発者、あるいは共通の設計文書に基づいて作業するグループによるものであり、即興的なものではないと強調している。
純粋に技術的な側面を超えて、この事件で最も不安を掻き立てる点の1つは、メインメンテナーのnpmアカウントが乗っ取られた経緯である。Axiosの管理者自身は後に、ほぼすべてのサービスで二段階認証を有効にしていたにもかかわらず、気づかないうちにアクセス権を与えてしまったと説明した。
チームが共有した事後分析によると、攻撃者はAIツールを活用した非常に巧妙なソーシャルエンジニアリング作戦を展開し、相手の信頼を得ようとした。彼らは企業の創業者になりすまし、その企業のビジュアルアイデンティティ、写真、さらには企業ブランディングまでを模倣した。また、企業のロゴが入った本物のSlackスペースを作成し、LinkedInと同期しているように見せかけた投稿を含むチャンネルを開設し、従業員や他のオープンソースソフトウェアのメンテナーの偽プロフィールまで作成した。
そのような状況下で、彼らはMicrosoft Teamsを使って会議を予定し、専門家グループ全員が参加しているように見えた。会議中、彼らは技術的な問題をシミュレーションし、システムの一部のコンポーネントが古くなっていることを示唆した。保守担当者は、それがビデオ会議ツール自体に関連する正当な要件であると判断し、提案されたファイルをダウンロードしてインストールした。
実際、そのファイルはリモートアクセス型トロイの木馬であり、攻撃者はそれを利用して被害者の認証情報にアクセスし、最終的にAxiosの公開に使用されていたnpmアカウントを乗っ取った。一連のプロセスは非常に巧妙に計画され、信憑性の高い詳細が数多く盛り込まれていたため、被害者は「完璧に調整され、プロフェッショナルで、完全に説得力があった」と述べている。
この事件における人的要素は、高度なソーシャルエンジニアリングが、視覚的ななりすまし、ディープフェイク、あるいは組織の精巧なクローン作成と組み合わさった場合、2段階認証のような技術的対策でさえ不十分であることを明確に示している。やはり、最も弱いリンクは人間同士のやり取りなのである。
Axiosを使用している組織や開発者への影響
実務的な観点から言えば、主な問題は実際に影響を受けた人物を特定することです。[email protected]または[email protected]が利用可能だった期間中にインストールした組織は、インストールを実行したマシンまたはパイプラインが侵害されている可能性があると想定する必要があります。
StepSecurity、Aikido、Huntress、Elasticといった企業からの推奨事項は明確です。疑わしい場合は、単に「node_modulesを削除して再インストールする」のではなく、積極的な対応が必要です。賢明な対処法は、影響を受けたマシンや環境を信頼できるイメージから再構築し、CI/CDログを注意深く確認して、どのジョブやパイプラインが侵害されたバージョンを実行した可能性があるかを特定することです。
さらに、RATがこれらのノードからアクセスした可能性のあるすべての認証情報と秘密情報（npmトークン、クラウドプロバイダーキー、パイプラインシークレット、データベース認証情報、SSHキーなど）をローテーションすることが極めて重要です。このような攻撃の後、これらの認証情報を流通させたままにしておくと、静かな横方向の移動を許してしまうことになります。
技術的なレベルでは、チームはロックファイル（package-lock.json、pnpm-lock.yaml、yarn.lock）を確認し、侵害されたバージョンの Axios および plain-crypto-js への参照がないか確認する必要があります。これらの要素が見つかった場合は、次のステップとして、影響を受けるシステムを検査して潜在的な RAT アーティファクトを探します。macOS の場合は /Library/Caches/com.apple.act.mond、Windows の場合は %PROGRAMDATA%\wt.exe および %PROGRAMDATA%\system.bat、Linux の場合は /tmp/ld.py を確認します。
同時に、Axiosのセキュアなバージョン（1.14.0や0.30.3など）を明示的に設定し、オーバーライドや解決機能を使用して、推移的な依存関係が望ましくないバージョンに解決されないようにすることをお勧めします。また、少なくとも攻撃の全容が分析されている間は、sfrclakcomドメインへのアウトバウンドトラフィックをブロックすることも、適切な封じ込め策です。
ソフトウェアサプライチェーンにおけるセキュリティの教訓
Axiosの事件は単発的な出来事ではなく、SolarWinds、Kaseya、3CX、Polyfill.io、Log4jの脆弱性悪用などを含むサプライチェーン攻撃の連鎖における新たな一環である。その根底にある考え方は常に同じだ。個々のマシンを攻撃するのではなく、広く利用され信頼されているコンポーネントを侵害することで、攻撃範囲を最大化する。
専門家から繰り返し伝えられる教訓の一つは、ライブラリの人気やメンテナーの評判だけに頼って信頼を築くことはできないということだ。リリースチャネル（npmアカウント、CI/CDパイプライン、ビルドインフラストラクチャ）が侵害された場合、それを通してリリースされるすべてのものがそのリスクを継承する。また、マルウェアが推移的依存関係に潜んでいて、実行後に自己削除する場合、手動によるコードレビューだけでは不十分である。
依存関係の更新における「デフォルトの速度」には、攻撃対象領域という点で代償が伴うことも指摘されています。常に最新バージョンを自動的に採用することは非常に便利ですが、悪意のある更新がわずか数分で拡散するリスクを高めます。そのため、一部の組織では、新しいバージョンを採用する前に一定期間エコシステムに存在していることを必須とする、あるいは重要なパッケージの変更には追加の手動レビューを義務付けるといったポリシーを既に検討しています。
開発インフラに関しては、CI/CD環境は極めて機密性の高い資産として扱う必要があります。依存関係のインストール中に実行されるあらゆるRAT（リモートアクセスツール）は、ほぼ確実にパイプラインの機密情報や他の環境へのアクセスを狙ってきます。これらのノードをセグメント化し、より綿密に監視し、機密情報を定期的にローテーションすることは、もはや「理想的な」推奨事項ではなく、必須事項となっています。
最後に、このような攻撃を検出するには、インストールされているバージョン、ロックファイル、オペレーティングシステムの侵害指標、ネットワークテレメトリなど、複数の情報源からの情報を組み合わせる必要があります。ソフトウェア部品表（SBOM）を生成および管理するツールは、どのプロジェクトがどのパッケージを使用しているかを迅速に追跡するのに役立ち、今回のような大規模なアラートが発生した場合に非常に重要となります。
Axiosとの一連の出来事は、依存関係のエコシステムが、どれほど成熟し統合されているように見えても、依然として信頼と絶え間ない警戒に大きく依存していることを如実に示している。一見無害に見えるライブラリが、巧妙なソーシャルエンジニアリング攻撃の被害に遭った一人の人物によって管理されている場合、わずか数時間で、あらゆる規模の企業、フリーランサー、組織に対するクロスプラットフォームのRAT（リモートアクセスツール）を展開するためのグローバルな媒介物になりかねない。公開アカウント、パイプライン、重要な依存関係に関する管理を強化することは、もはやオプションのベストプラクティスではなく、攻撃者がますます忍耐強く、創意工夫に富み、より優れたツールを備えている環境で開発を継続するための前提条件となっている。
