更新日： 2026年4月3日 - アカウントが最初に侵害された経緯に関する詳細を追加しました。
--
広く使われているパッケージが侵害された場合、多くのチームは決まった手順を踏みます。つまり、差分を確認し、悪意のあるバージョンを特定し、それが自チームの環境に取り込まれていないかを確認するのです。こうした対応は必要ですが、問題のほんの一部しか解決していません。
Axios は npmエコシステムで広く利用されているHTTPクライアント. これは現代のアプリケーション・スタックの奥深くに位置し、開発ツール、バックエンド・サービス、フロントエンド・フレームワーク、CIパイプラインなどに組み込まれています。インストールは特定の場所で行われるのではなく、ワークステーション、ビルドシステム、本番環境など、あらゆる場所で継続的に行われます。多くの場合、新しい依存関係はデプロイやスケーリングの際に自動的に解決されるため、セキュリティ上の問題を抱えたバージョンが開発者のマシンをはるかに超えて拡散してしまう可能性があります。
脆弱性が存在する期間中、影響を受けるバージョンを解決していた環境では、攻撃者が制御するコードが実行されていました。この点が、対応策を決定づけるべき要素です。問題はバージョン番号や依存関係の差異ではなく、すでに特権アクセス権限を持つシステム内で、信頼できないコードが実行されていたという事実にあります。
実際に何が起きたのか
axiosのメンテナアカウントが乗っ取られ、悪意のあるバージョンが公開・タグ付けされたため、標準的なインストールではそれらのバージョンが参照されるようになってしまいました。
メンテナンス担当者のその後の説明によると、これは単なる認証情報の漏洩ではなく、標的型ソーシャルエンジニアリング攻撃であったことが示唆されています。攻撃者は正規の企業を装い、ブランドロゴや著名なエンジニアのプロフィールを複製して説得力のあるSlackワークスペースを構築し、Microsoft Teams上でライブミーティングを設定しました。そのやり取りの中で、メンテナンス担当者は一見すると通常のアップデートのように見えるものをインストールするよう促されましたが、実際にはそれが マルウェア を展開し、環境へのアクセス権を奪うものでした。
その後、攻撃者はそのアクセス権を利用して、プロジェクトの通常のリリースプロセスを迂回し、バックドアが仕込まれたバージョンのaxiosをnpmに直接公開した。
変更自体はごくわずかでした。依存関係は1つだけ、 plain-crypto-jsが追加されただけだが、コードベースのどこからも参照されることはなかった。必要がなかったからだ。その目的は機能ではなく、実行そのものだった。
その依存関係により、 インストール後 フックは、通常時中に自動的に実行され npm install プロセス。何のメッセージも警告もなく、何か問題が発生した兆候もなかった。スクリプトは、最終的なペイロードを封じ込める代わりに、 滴下器として機能した.
実行されるとすぐに、攻撃者が制御するインフラストラクチャに接続し、通常のnpm関連のトラフィックに見せかけたリクエストを送信した。リクエスト本文は正規のレジストリ通信を模倣していたが、宛先は外部であった。応答には、macOS、Windows、またはLinux向けに調整されたプラットフォーム固有のペイロードが含まれており、これはディスクに書き込まれ、バックグラウンドで実行された。
その時点で、目的はすでに達成されていた。インストールプロセスとは無関係に、システム上でリモートアクセスツールが動作していた。
その後、ドロッパーは自身の痕跡を消去した。インストーラースクリプトは削除され、パッケージのメタデータは書き換えられて、一見クリーンな状態に見せかけられた。その後、依存関係を調べても、明らかに悪意のあるものは何も見つからないだろう。ペイロードはすでに実行されていたにもかかわらず、インストールは正当なもののように見えるはずだ。
この事案が特に注目に値するのは、明らかに脆弱な仕組みに依存していなかった点にある。メンテナンス担当者は多要素認証を導入しており、 OIDCを利用した信頼できるパブリッシングへの移行も 始めていた。しかし、従来のパブリッシング経路では依然として有効期間の長いnpmトークンに依存しており、その仕様上、多要素認証を迂回できていた。
その共存関係が隙を生んだ。厳格な制御は存在していたものの、端から端まで徹底されてはいなかった。攻撃者は、本来想定されていた公開ワークフローを破壊する必要はなかった。攻撃者は、依然として利用可能な経路を利用するだけでよかったのだ。
メンテナとコミュニティによる初期の議論は、すぐに同じ結論に収束しました。すなわち、強力な制御策は導入されていたものの、レガシーな認証経路によって依然として脆弱性が残っていたのです。
ユーザーRiteshkewによるコメント GitHub上のRiteshkewユーザーによるコメント
これは、サプライチェーン関連のインシデントに共通して見られるパターンです。侵害はID情報を通じて行われ、ペイロードは信頼された配布経路を通じて配信され、その実行は通常の動作に紛れ込んでしまいます。変化に気づく頃には、コードはすでに実行されてしまっているのです。
出典： StepSecurity
ここに示されているアウトバウンドリクエストは、npmレジストリではなく、攻撃者が制御するインフラストラクチャに向けられています。リクエスト本文はnpm関連のトラフィックを模倣しており、これにより、第2段階のペイロードを取得する際に、その活動を通常の開発ワークフローに溶け込ませることができます。
なぜこれが通常のワークフローに自然に溶け込むのか
「ポイズンドパッケージ」自体は目新しいものではありませんが、今回の事例は、通常の開発ワークフローと 見事に一致している 点、そして 標的を絞ったアクセスと広範な配布を組み合わせている点で際立っています 。
前述の通り、エクスプロイトそのものが結果を決定づけることはめったにありません。重要なのは、環境内でコードが実行された後に何が起こるかです。
いくつかの要因により、今回の事件は通常のサプライチェーン侵害よりも深刻な影響を及ぼしている。
Axiosは広く組み込まれているため、影響の範囲は単一のアプリケーションやチームをはるかに超えて広がります。この脆弱性の影響は、Axiosに明示的に依存していた組織だけに留まりませんでした。該当期間中に間接的にAxiosを解決していたパッケージ、ビルドワークフロー、またはCIジョブであれば、いずれも悪意のあるリリースを引き込んでいた可能性があり、影響の全容を迅速に把握することは困難です。
実行は即座に行われた。ペイロードはインストールから数秒以内に実行され、多くの場合、自動化されたパイプラインを通じて実行された。Huntressは、悪意のあるバージョンが公開されてからわずか89秒後に、確認された最初のエンドポイント感染を検知した。これは、現代の開発環境において、新しい依存関係がどれほど迅速に解決され、実行されるかを如実に示している。
同時に、攻撃者は自身の痕跡を最小限に抑えるための措置を講じた。インストーラーは自身を削除し、パッケージのメタデータは書き換えられたため、事後の調査では何の問題もなかったかのように見えた。変更そのものは極めて緻密に行われており、依存関係が1つ追加されただけで、機能的な変更はなく、特定のファイルを詳細に調べない限り、明らかな兆候は一切見られなかった。
この事例が他と一線を画す点は、その発端の経緯にもあります。今回の侵害はパッケージのエコシステム自体に起因するものではなく、メンテナンス担当者を標的としたソーシャルエンジニアリング攻撃によって引き起こされました。攻撃者は技術的な脆弱性を悪用するのではなく、信頼関係を悪用することで、多要素認証（MFA）などのセキュリティ対策を迂回し、リリースプロセスへの直接的なアクセス権を獲得しました。
標的型ID侵害とソフトウェア・サプライチェーンを介した拡散という組み合わせこそが、この種の攻撃を予測しにくく、封じ込めることをさらに困難にしている要因である。
パッケージのインストールから認証情報の漏洩まで
インストールは単なる入り口に過ぎません。ドロッパーが実行されると、それを実行しているシステムの権限とアクセス権を引き継ぎます。
実際には、これにはGitHubトークン、npmトークン、クラウドの認証情報、CI/CDのシークレット、APIキー、SSH鍵などが含まれることがよくあります。これらはすべて、開発者のワークステーションやビルドパイプラインといった信頼できる環境内ですでに利用可能であるため、悪用される必要はありません。
その段階に至ると、攻撃者はもはやパッケージそのものに依存しなくなる。焦点は、それらのシステムが何にアクセスできるか、そしてそのアクセス権をどのように再利用できるかへと移る。
このパターンがどのように展開するかは、すでに確認済みです。Shai-Huludの事例では、攻撃は実行段階からすぐに認証情報の収集と再利用へと移行し、既存の信頼関係を利用してリポジトリやパイプライン全体に拡散しました。
そのパッケージは、配信の手段として機能します。リスクは、その配信によって可能になるものから生じます。
この手口はnpmパッケージに限ったことではありません。先日のTrivyのサプライチェーンインシデントでは、攻撃者は侵害されたCI/CDツールを利用してビルドパイプライン内で直接コードを実行し、クラウドの認証情報、Kubernetesのシークレット、APIトークンを大規模に収集しました。侵入経路は異なっても、結果は同じです。つまり、信頼された環境内でコードが実行され、その環境がアクセス可能なあらゆるリソースに即座にアクセスできてしまうのです。
インストール後の表示のずれ
多くの組織がここで方向性を失ってしまう。
ロックファイルに悪意のあるバージョンが含まれているかどうかを確認するのは比較的簡単ですが、それだけではコードが 実際にどこで 実行されたのかは分かりません 。ビルドログには、分離されたバックグラウンドプロセスの動作が記録されることはほとんどなく、開発者のマシンは、本番システムに適用されているのと同じレベルの監視対象外で稼働していることが多いためです。
悪意のある依存関係が特定され、削除される頃には、すでに最初の実行は完了しており、チームに残されるのは限られた証拠と、未解決の疑問ばかりである。
ペイロードは認証情報にアクセスしましたか？
その認証情報は再利用されましたか？
その活動はクラウドやSaaS環境にも及んだのでしょうか？
多くの場合、従来のツールだけでは、これらの疑問に決定的な答えを出すことはできません。
被ばく量を検証する実用的な方法
「影響を受ける可能性がある」という段階から、具体的な行動に移ろうとしているチームにとって、最も手っ取り早く確認できる指標の一つが、対外的なコミュニケーションです。
Vectra AI にて、攻撃者のインフラとの通信を検知することで、悪意のあるaxiosペイロードを実行した可能性のあるシステムを特定するための、5分間の専用ハンティングを公開しました。
今回の調査では、コマンド・アンド・コントロール・ドメインを含め、当該キャンペーンに関連する信頼性の高い指標の少数のセットに焦点を当てています sfrclak.com および関連するIPアドレス 142.11.206.73. 感染期間中またはその後に当該インフラと通信を行うシステムは、すべて不審なものとして扱うべきである。
このクエリにより、そのドメインまたはIPアドレスに関連するネットワークセッションが、送信元および宛先のホスト、プロトコル、接続頻度とともに表示されます。実際の運用においては、アナリストは、繰り返し接続や自動的な接続が見られるシステム、あるいは類似の外部インフラとの通信履歴がこれまでないホストに注意を払う必要があります。
そこから、調査は迅速に進めることができます。DNS、HTTP、SSLのテレメトリデータを活用して 通信の範囲を把握し、エンドポイントデータと照合して原因となっているプロセスを特定します。不審な活動が確認された場合は、インフラストラクチャへのアクセスを遮断し、影響を受けたシステムを隔離して対応を行います。
このような標的型攻撃への対応は、広範な調査に代わるものではありませんが、チームが侵害された可能性のあるシステムを迅速に特定し、対応の優先順位をつける手段となります。実行が密かに行われ、証拠が限られているインシデントにおいては、その初期の兆候を捉えることで、環境内で実際に何が実行されたかを把握するまでの時間を大幅に短縮することができます。
サプライチェーン攻撃の標的がIDへと移行
一度アクセス権を取得すれば、攻撃はもはや マルウェア の持続性に依存しなくなります。有効な認証情報は、より信頼性が高く、検知されにくい経路を提供します。
攻撃者は、開発者や自動化ツールが日常的に利用しているのと同じインターフェースやワークフローを使用して、認証を行ったり、APIを呼び出したり、システムとやり取りしたりすることができます。これにより、攻撃者は通常の活動に溶け込みながら、さまざまな環境へとその影響力を広げることが可能になります。
その Shai-Huludの例 は、盗まれたトークンを使用してリポジトリを作成し、パイプラインを変更し、個々のイベントレベルでは明らかな異常を発生させることなく、既存の信頼関係を通じて拡張していく仕組みを具体的に示した。
Axiosのインシデントも同様の機会をもたらします。これまで使用したことのないリソースにアクセスするサービスアカウント、新しいコンテキストで出現するトークン、あるいは予想とは異なる動作をするパイプライン――これらはそれぞれ個別に説明可能な事象です。しかし、これらを総合的に見ると、通常の動作ではなく、アクセス権の悪用を示唆するパターンを形成します。
侵害発生後の状況を把握する
コードの実行が発生すると、 、課題は「防止」から「アクセスがどのように利用されているかを把握すること」へと移行します。
この攻撃チェーンにおける最も初期の兆候の一つは、コマンド＆コントロール（C&C）インフラへの外部通信です。ドロッパーが自身の痕跡を削除した後でも、このネットワーク活動は継続します。開発者のマシン、CIランナー、またはアプリケーション環境からの異常な外部接続は、特にその接続先が想定される依存関係やビルド動作と一致しない場合、何か異常が発生していることを明確に示す兆候となります。
The Vectra AI は、ID管理システム、クラウドおよびSaaS環境、ネットワークアクティビティ全体にわたって、こうしたパターンを特定することに重点を置いています。本プラットフォームは、通常の利用パターンと一致しない認証行動を可視化し、想定されるワークロードの挙動から逸脱したアクセスパターンを強調表示し、ステージング、持続化、またはラテラルムーブメントを示唆するアクティビティを検出します。
個々の兆候だけでは、目立たないかもしれません。しかし、これらを総合的に分析することで、そのインシデントが実行段階で阻止されたのか、それともより広範な侵害へと発展したのかが明らかになります。
これらのポストエクスプロイトのパターンが各環境でどのように現れるかについて、より詳細に 分析するため、 本レポートでは検知の観点から調査の過程を解説します。
今も信頼できるもの
Axiosのインシデントは、悪意のあるパッケージの削除で終わるわけではありません。それは、確実性がリスク評価へと移行する転換点となるのです。
多くのチームは、影響を受けたバージョンが導入されていたかどうかを特定できます。しかし、それらがどこで実行されたか、あるいは当時その環境がどのような情報をさらしていたかを特定できるチームはそれほど多くありません。この違いは重要です。なぜなら、それがインシデントが限定的なものだったのか、それとも永続的なアクセス権を付与する結果となったのかを決定づけるからです。
侵害されたバージョンが実行された可能性がある場合、最も安全な見解としては、その環境を以前の状態のまま信頼すべきではないということです。開発者のマシン、CIランナー、ビルドシステムは、意図した以上に多くのアクセス権限を持っていることが多く、そのアクセス権限が完全に把握されていることは稀です。
最初の対応策は依然として単純明快だ。部分的なクリーンアップを試みるのではなく、クリーンなバージョンにピン留めし、依存関係を削除し、影響を受けたシステムを再構築する。より難しいのは、その後も何が信頼できるかを判断することである。
これらの環境に関連する認証情報は、悪用されたという証拠があるからではなく、その逆を証明する確実な方法がないため、漏洩したとみなすべきです。信頼を回復するためには、認証情報のローテーションが必要となります。
この事案は、依存関係の取り扱いにおける構造的な問題も浮き彫りにしています。利用可能な最新バージョンを自動的に適用するCI/CDパイプラインは、新たに公開された悪意のあるパッケージが即座に実行される直接的な経路を作り出してしまいます。公開から適用までの間に遅延を設け、より厳格なバージョン固定を行うことで、デプロイ前に問題が表面化する時間を確保し、リスクを軽減することができます。
一方で、根本的な原因は依然として認証情報の漏洩にあります。メンテナやデプロイ用アカウントは重要な資産として扱い、日常的な開発アクセス権とリリース権限を明確に区別する必要があります。有効期間の長いトークンへの依存を減らし、公開ワークフローに対する管理を強化することで、この種の攻撃による影響を最小限に抑えることができます。
サプライチェーン関連のインシデント全般に共通する重要な教訓がある。侵入経路は侵害された依存関係であるかもしれないが、その影響の大きさは、その後のアクセスがどのように悪用されるかによって決まる。axiosの侵害は短期間で収束したが、それによって生じた状況は、インストール期間をはるかに超えて続く可能性がある。