Next.jsを使ったWebアプリケーションを狙った、大規模かつ高度に自動化されたクレデンシャル窃取キャンペーンが確認された。Cisco Talosが今週公開したレポートによれば、「UAT-10608」と追跡される脅威クラスターが「NEXUS Listener」と呼ばれる専用フレームワークを駆使し、わずか24時間のうちに766ホストの侵害に成功している。

何が起きているのか——React2Shell（CVE-2025-55182）という「入り口」

今回の攻撃の起点となっているのが、CVE-2025-55182として採番されたReact2Shellという脆弱性だ。Next.jsアプリに存在するこの欠陥を悪用することで、攻撃者はシステム上でコマンドを実行できる状態を作り出す。

攻撃の流れはシンプルかつ効率的に設計されている。

  • インターネット上の脆弱なNext.jsアプリを自動スキャン
  • React2Shellで初期侵入を確立
  • システムの一時ディレクトリに多段階クレデンシャル収集スクリプトを配置
  • 収集した機密情報をHTTPポート8080経由でC2サーバー（NEXUS Listener）へ逐次送信

何が盗まれているのか——想像以上に広い収集範囲

Cisco Talosの研究者が実際にNEXUS Listenerの露出インスタンスへアクセスして分析した結果、収集対象は以下のとおりであることが判明した。

  • 環境変数・シークレット: APIキー、データベース認証情報、GitHub/GitLabトークン
  • SSHプライベートキー
  • クラウドクレデンシャル: AWS・GCP・Azureのメタデータ、IAM認証情報
  • Kubernetesトークン
  • Dockerコンテナ情報
  • コマンド履歴
  • プロセス・ランタイムデータ

特筆すべきは、これらが「あったら盗む」ではなく「ありそうな場所を全部狙う」という設計になっている点だ。AWSのインスタンスメタデータから始まりKubernetesのサービスアカウントトークンに至るまで、クラウドネイティブ環境で使われる機密情報のほぼすべてが収集対象に含まれている。

実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと

この攻撃が厄介なのは、被害が侵入されたサーバー単体に留まらない点だ。盗まれたSSHキーは横移動（ラテラルムーブメント）に使われ、クラウドのIAM認証情報はアカウント乗っ取りを可能にし、GitHubトークンはサプライチェーン攻撃の扉を開く。さらにCisco Talosは、個人情報の漏洩によるプライバシー法規制上のリスクも指摘している。日本ではGDPR同等の個人情報保護法への対応が求められる組織も多く、他人事ではない。

今すぐ実施すべき対応策：

  • React2Shellのセキュリティアップデートを即時適用する。 対象システムが特定できない場合、Next.jsを使ったアプリをすべてリストアップするところから始める
  • 侵害の疑いがある場合はクレデンシャルをすべてローテーションする。 「たぶん大丈夫」で済ませてはいけない
  • AWSを使っている場合はIMDSv2を強制する。 IMDSv1が有効なままだとメタデータエンドポイントへの不正アクセスリスクが残る
  • コンテナ・クラウドロールの最小権限原則（Least Privilege）を徹底する。 広すぎる権限は、侵害されたときの被害を指数関数的に拡大させる
  • WAF/RASPをNext.jsアプリの前段に配置する。 シグネチャベースの検知だけでは限界があるが、それでも攻撃コストを上げる効果は大きい
  • シークレットスキャンを有効化する。 GitHubであればSecret Scanningが標準で使える。誤ってコードにクレデンシャルを書いてしまった経験は誰にでもある

筆者の見解

この種の攻撃を見るたびに思うのは、「防御の難しさ」より「そもそもの設計」の問題だということだ。Next.jsアプリのサーバー環境に、AWSのIAMクレデンシャルからKubernetesのサービスアカウントトークンまで、なぜそれほど多種多様な機密情報が置かれているのか。利便性を優先して一台のサーバーに何でも詰め込んでしまうと、一点突破で全部持っていかれる。

「Just-In-Time」なアクセス管理と最小権限の原則は、耳にタコができるほど繰り返されてきた話だが、今回の766ホストという数字は、それが実態に落とし込まれていないことを示している。常時発行されているクレデンシャルが多いほど、盗まれたときのダメージは大きい。環境変数に長期有効なAPIキーを何十個も持つ構成は、攻撃者にとって宝の地図をまるごと渡すようなものだ。

ゼロトラストの文脈で言えば、ネットワーク層・認証層・認可層の3層すべてで独立した防御を設計することが正道だ。どこか一層が突破されたとしても、次の層が機能していれば被害を最小化できる。今回のNEXUS Listenerのような自動収集ツールは今後さらに洗練されていく。一度壊れた信頼を取り戻すコストを考えれば、設計段階での投資は決して高くない。

出典: この記事は Hackers exploit React2Shell in automated credential theft campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。