記録的なダウンロード数を誇る主要HTTPクライアントへの攻撃
2026年3月30日から31日にかけて、世界中で一週間に1億回以上ダウンロードされるJavaScriptの要となるHTTPクライアントライブラリ「axios」が、深刻なサプライチェーン攻撃の標的となった。フロントエンドフレームワークやバックエンドサービス、エンタープライズアプリケーションの根本を支えるこのパッケージの正規メンテナーアカウントが乗っ取られ、クロスプラットフォームに対応した遠隔操作型トロイの木馬（RAT）をバックグラウンドで展開する悪意のあるパッケージが意図的に混入されたのである。
影響を受けたバージョンは、モダンな環境向けの「1.14.1」と、レガシー環境向けの「0.30.4」という二つの主要なリリースラインにまたがっていた。この攻撃は、単なるスクリプトキッズによる偶発的なコードインジェクションではない。およそ18時間の周到であらかじめ計算された準備期間を経て実行されており、さらには高度な自己消去メカニズムと静的解析を欺くアンチフォレンジック（証拠隠滅）技術を組み込んでいた。数あるnpmレジストリインシデントの歴史上においても、これは類を見ないほど洗練された作戦構造を持っていた。
OIDCの盲点を突いたクラシックアクセストークンによるアカウントの乗っ取り
攻撃の起点として確認されているのは、Axiosの主要メンテナーであるユーザーアカウント（jasonsaayman）の侵害である。アカウントの制御権を奪取した攻撃者は、アカウントに紐づくメールアドレスを自身が管理するProtonMailの匿名アドレス（ifstap@proton.me）へと即座に変更した。そのうえで、プロジェクトが構築してきた安全な正規のCI/CDリリースプロセスを完全に迂回し、悪意を持たせたパッケージバージョンをnpmレジストリへと直接パブリッシュした。
近年、Axiosの正規リリースプロセスにおいては、GitHub ActionsとnpmのOIDC（OpenID Connect）連携によるTrusted Publisherメカニズムという強固な仕組みが採用されており、これによって自動化された安全なパッケージの公開が行われていた。しかしながら、今回の攻撃版である1.14.1のリリースにおいては、GitHubのコミット履歴やタグ付けが一切存在せず、OIDCを経由せずに公開されたことを示す痕跡がnpmのレジストリメタデータに残されていた。OIDCトークンは一時的なものであり、第三者による窃取は論理的に不可能である。この事実から導き出されるのは、攻撃者がメンテナーの旧式かつ無期限に近い「クラシックアクセストークン」をパスワード侵害やセッションハイジャックなどの何らかの手法で奪取し、CLI等から手動で悪意あるパッケージを公開したというプロセスである。
隠蔽されたペイロード「plain-crypto-js」の巧妙な手法と幽霊依存関係
この攻撃の最も恐るべき側面は、Axios自体のソースコードには一行たりとも悪意のある改ざんコードが含まれていなかった点にある。ソースコードに対して変更を加える代わりに、攻撃者はplain-crypto-jsという未知のパッケージ（悪意を持つバージョン4.2.1）を新たな依存関係としてpackage.jsonにただ追加するという手口を用いた。このパッケージはAxios内部のプログラムにおいてインポートされることや、関数として呼び出されることは一切ない。単に依存関係リストの中に潜む「幽霊依存関係（Phantom dependency）」として機能する。従来のコード差分（Diff）ベースのコードレビューにおいて、ソースファイルに一切の変更がないという点は、アナリストから警戒を逸らす強力なカモフラージュとなる。
plain-crypto-jsによる攻撃フローは、npmパッケージのインストール時に自動実行されるpostinstallフックを悪用している。開発者やCI/CD環境がnpm install axios@1.14.1を実行すると、依存関係として自動的に指定されたplain-crypto-js@4.2.1が解決されてダウンロードが進行する。そしてパッケージのインストールプロセス全体が完了するより前の段階で、postinstallフックが静かにトリガーされ、難読化されたNode.jsのドロッパー（setup.js）が起動する。セキュリティプラットフォームStepSecurityによるHarden-Runnerを用いたランタイム分析によれば、インストールプロセス（npm install）の開始からわずか1.1秒後には、ドロッパー本体が難読化を解除し、攻撃者のコマンド＆コントロール（C2）サーバーへと最初の通信経路を確立していたことが確認されている。
3つのオペレーティングシステムを狙い撃つプラットフォーム特化型RAT
ドロッパーは起動直後にシステム環境のオペレーティングシステム（OS）を即座に判別し、Windows、macOS、Linuxのそれぞれに対して最適化され事前準備された3つのペイロード攻撃経路へと動的に分岐する。
macOS環境への攻撃とシステムデーモンへの擬態
macOSにおいては、一時ディレクトリ空間にAppleScriptファイルを生成し、それをバックグラウンドでサイレント実行する。このスクリプトは指定のC2サーバーからC++で記述された第二段階のRATバイナリをダウンロードし、/Library/Caches/com.apple.act.mondという絶対パスに直接保存する。このファイルパスと名称は、Appleの正規のバックグラウンドプロセス群（Activity Monitor Daemonなどに類似）の命名規則を巧妙に模倣している。キャッシュ領域という、通常のインシデントレスポンスやウイルスパターンチェックの際に見過ごされやすい聖域を意図的に狙うことで、持続的な活動を確保しようとしている。
Windows環境での永続化とPowerShellを通じた非表示の侵害
Windowsに対する攻撃チェーンはより重層的である。はじめにシステム内のPowerShell実行ファイルパスを探索し特定すると、それを%PROGRAMDATA%\wt.exeとしてコピーする。これはWindowsの標準的なターミナルアプリケーション（Windows Terminal）の実行ファイル名に偽装するものであり、システム内に正規のツールに見せかけた持続的なコマンドインタプリタのコピーを安全に確保する狙いがある。その後、テンポラリディレクトリにVBScriptを生成して実行することで、画面上に一切のGUIを表示させない完全に透過的なコマンドプロンプトプロセスを描画し、C2サーバーから最終的なPowerShell製のRATスクリプトを取得する。取得したスクリプトはユーザーの目に見えないバックグラウンドで無期限に実行され、システム情報の窃取や任意のコマンド実行を待機する。
Linuxプロセスツリーからの離脱
その他のプラットフォーム（主にLinux環境等を想定）では、Node.jsのexecSyncを呼び出して直接シェルコマンドを実行する。C2サーバーからPython製のRATスクリプトを取得し、/tmp/ld.pyとして保存する。特筆すべきは、実行時にnohupコマンドを用いてプロセスツリー上で実行元プロセス（npmプロセス）からの完全な切り離しを行っている点である。これによりRATはPID 1（init）に紐付けられる孤児プロセスとなり、インストーラープロセスが終了した後もプロセス監視システムからの視認性を低下させた状態でバックグラウンド実行を継続させることができる。
なお、各OSのペイロード展開時には同一のC2サーバー（sfrclak.com:8000）と通信を行う設計となっているが、POSTリクエストのボディに含めるパス識別子（packages.npm.org/product0、product1、product2）をプラットフォームごとに変更している。これにより、単一のエンドポイント設計でありながらもサーバー側がリクエストに応じた適切なマルウェアを遅延なく配信できるようシステム化されている。また、通信先パスにpackages.npm.orgという文字列を利用することで、ネットワークログやSIEMツール上で正規のnpm通信によるトラフィックであるかのように見せかける偽装工作も施されている。
デジタル上の自己消去と完全なアンチフォレンジック
ペイロードの実行という目的を果たした直後、ドロッパーであるsetup.jsは、インストール後の静的分析やフォレンジック調査の目をくらませるための3段階に及ぶ自己消去プロセスを実行に移す。
- まず、自身のファイル本体（
setup.js）をファイルシステムから完全に削除する。 - 次に、悪意ある振る舞いの出発点であった
postinstallフックの記述を含んでいる現在のpackage.jsonを削除する。 - 最後に、攻撃とは無関係な正規のコードのみを含むように事前構築しておいた無害なファイル（
package.md）を、package.jsonという名前にリネームして配置する。
この最終的に配置されたクリーンな偽装ファイルには、postinstallフックのコードはおろかドロッパーに関する一切の情報が存在しない。さらに巧妙なことに、パッケージのバージョン番号の項目には、悪意のある「4.2.1」ではなく、今回の脅威が発生する18時間前に攻撃者が正当な活動履歴を作るために公開していた「4.2.0」（クリーンなバージョン）が記載されている。このバージョンスプーフィングの技術により、感染後に事態を重く見た開発者やセキュリティ管理者がプロジェクトのディレクトリ内やnpm listコマンドで依存関係を事後確認したとしても、コンソールには「4.2.0」と表示され、表面上は完全に安全で無害なパッケージツリーしか確認できないよう調整されている。事件現場には指紋ひとつ残らないが、実際には一時ファイルディレクトリやバックグラウンドの孤児プロセスを通じてRATはすでにシステム内部の深層構造で活動を始めている。
開発環境とCI/CDパイプラインにもたらす不可逆の脅威
これほどまでに精巧な攻撃戦略は、実行時の動的解析ツールを活用しない限り未然に防ぐことが極めて困難である。StepSecurityのHarden-RunnerやAI Package Analyst、あるいはSocket、SafeDepといった分析プラットフォームがリアルタイムでの異常なアウトバウンド通信の監視を行い、プロセスツリーから意図的に独立しようと試みるnohupのふるまいを異常として検知したことで、この洗練された手口は事後数時間以内に特定され被害拡大を食い止めることができた。現在では該当パッケージはnpmレジストリ側でセキュリティホールドの処置が取られている。
しかしながら、マルウェアの活動が可能だったこの数時間の空白は、世界中のソフトウェアサプライチェーンに対して不可逆の打撃を及ぼすリスクを含んでいた。Axiosレベルのダウンロード数と利用実績を持つ巨大なパッケージは、無数のエンタープライズ製品やCI/CDパイプラインの中核に位置している。自動化されたビルドプロセスの中でこの悪意のあるバージョンがインストールされた場合、CI/CD環境という非常に権限の高い領域内に保存されているAWSのアクセスキー、GCPのサービスアカウントトークン、本番環境のデータベースへの接続情報といったインフラの機密情報が、即座に攻撃者のC2サーバーへと吸い上げられることになる。
同時に、CI/CD環境のみならず、開発者自身のローカルマシンで開発用途としてnpm installが単発で実行された場合においても、即座に各種のスクリプト群とRATが展開される。ローカル環境は多くの場合システムに対する深いアクセス権を保有しており、ブラウザのCookieやローカルに保存されたAPIキーファイルなどの認証情報の窃取が容易に行われてしまう。
この巧妙な二段構えの脅威に対しては、単に依存関係ツリーからマルウェアパッケージの記述を削除するだけでは不十分である。バックドアがすでに配置済みであることを前提として、影響を受けた可能性のあるすべての開発環境およびサーバー環境におけるシークレット情報の完全なるローテーション、そしてクリーンな状態からの再構築という根本的な是正措置が要求される。
パッケージの静的差分チェックを通じた監査を完全にすり抜けることを前提とした今回のAxiosサプライチェーン攻撃の技術力と戦略の洗練度は、オープンソースコンポーネントにおける推移的依存の複雑さに依存する現代のソフトウェア開発パラダイムが抱える根源的な脆弱性を明確に示している。継続的なランタイム監視システムと、スクリプト実行の一律停止（--ignore-scripts）に代表されるゼロトラスト原則に基づいた強固なアーキテクチャの導入なしには、プロセスを飛び越えてシステム深層へ侵入するこのレベルの運用統制を持った攻撃を防ぐことは、事実上不可能となりつつある。
Sources