北朝鮮系ハッカーが新型マルウェア「EtherRAT」とReactの脆弱性 React2Shellをサイバー攻撃に悪用|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2025年12月11日更新日時: 2025年12月16日

北朝鮮系ハッカーが新型マルウェア「EtherRAT」とReact2Shellの脆弱性をサイバー攻撃に悪用

2025年12月3日に公開された React Server Components の重大脆弱性 CVE-2025-55182（通称 React2Shell） を巡り、各国の攻撃グループが一斉に悪用を始めています。そんな中、クラウドセキュリティ企業 Sysdig の調査チームが、公開からわずか 48時間後 に、Next.js アプリからこれまでとは桁違いに高度なマルウェア「EtherRAT」を確認しました。

1 概要
2 React2Shell 脆弱性とは
3 EtherRAT攻撃チェーン：4段階でNext.jsサーバを乗っ取る
4 スマートコントラクトを使った指令サーバ隠蔽
5 Linuxでの永続化
6 北朝鮮「Contagious Interview」との関係
7 情報システム部門として取るべき対策

概要

これまで確認されていた React2Shell 悪用は、仮想通貨マイニングや AWS クレデンシャル窃取など、比較的単純なシェルスクリプト主体の攻撃が中心でした。それに対し EtherRAT は、

イーサリアムのスマートコントラクトを使った ブロックチェーンC2
5種類の Linux 永続化手法
Node.js ランタイムを nodejs.org から正規ダウンロード して利用
自己コードを書き換えるアップデート機構

といった、高度な機能を盛り込んだ「長期潜伏用マルウェア」となっています。

Sysdig は、このツールが北朝鮮関連キャンペーン「Contagious Interview」で使われたマルウェアと強い類似性を持つと指摘しており、北朝鮮（DPRK）系グループが React2Shell を新しい侵入手段として取り込み始めた可能性があると見ています。

React2Shell 脆弱性とは

EtherRATの解説に入る前に、入口となるReact2Shellがどういう問題なのかを簡単に記載します

React2Shell（CVE-2025-55182）は、React Server Components（RSC）で使われている「Flight」プロトコルの処理に欠陥があり、攻撃者が細工したHTTPリクエストを送るだけで、サーバ側で任意のJavaScriptを実行できてしまう脆弱性です。認証は一切不要で、標準的なNext.js + App Router構成であれば、特別なカスタムコードがなくてもそのまま攻撃対象になります。

問題のあるバージョンは、React 19系の react-server-dom-* 系パッケージ（19.0 / 19.1.0 / 19.1.1 / 19.2.0）と、それを取り込んでいるNext.js 15 / 16シリーズです。React側は 19.0.1 / 19.1.2 / 19.2.1 で、Next.js側は 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 で修正済みです。

CISAのKEVリストに載っていることからも分かるように、「PoCコードが出たからそのうち悪用されるかも」ではなく、

すでに世界中で自動スキャンされ悪用されているている前提で考えた方がいい　脆弱性です。

EtherRAT攻撃チェーン：4段階でNext.jsサーバを乗っ取る

Sysdigの分析では、EtherRATの侵入から常駐までの流れは大きく4つの段階に分かれています。

簡単に言うと、React2Shellでドロッパ起動 → シェルスクリプトで環境づくり → 暗号化ペイロードを復号 → 常駐インプラントとして動作開始」という流れです。

Stage 0：React2Shellでベース64ドロッパを実行

最初のきっかけは、React2Shellを使った1本のHTTPリクエストです。攻撃者はこのリクエストの中で、base64エンコードしたシェルコマンドをRCEとして実行させます。中身を復号すると、特定のIPアドレス上のHTTPサーバから s.sh というスクリプトを落として実行する処理になっており、ダウンロードが失敗しても何度でもリトライするように組まれています。

curlがなければwget、それもなければpython3でHTTPリクエスト、というように、ターゲット環境に合わせて手段を変えながら、300秒ごとに延々と再試行する作りです。ログ上は、Webサーバのプロセスから外部へのHTTPアクセスが繰り返される形として現れます。

Stage 1：シェルスクリプトでNode.jsとペイロードを展開

無事に s.sh がダウンロードされると、次はこのシェルスクリプトが実行されます。ここでは、侵入先のユーザーのホームディレクトリ配下に隠しディレクトリを作り、その中にNode.jsとペイロード一式を展開します。

具体的には、~/.local/share/ の下にランダムな名前のディレクトリを作り、https://nodejs.org/dist/v20.10.0/ からLinux版のNode.jsをダウンロードし、tarを展開して bin/node を取り出します。同時に、暗号化されたバイナリデータと、難読化されたJavaScriptドロッパを、それぞれ別ファイルとして書き込みます。

最後に nohup でJSドロッパをバックグラウンド起動し、s.sh 自身は消してしまうため、表面的には「どこから侵入したのか」痕跡が薄くなります。Node.jsを正規サイトから取ってくるあたりは、あえて自分で怪しいバイナリを持ち込まず、検知を避ける意図が透けて見えます。

Stage 2：AES-256-CBCで本体を復号するJSドロッパ

次に動き出すのが、難読化されたJavaScriptドロッパです。このスクリプトは、あらかじめ埋め込まれた鍵とIVを使って、暗号化されたペイロードファイルをAES-256-CBCで復号し、復号した内容を別の .js ファイルとして書き出します。

同時に、ランダムなボットID（UUID）とペイロードファイル名をステートファイルとして保存しており、「このホストにどのインスタンスが展開されたか」を自分で追跡できるようになっています。

その後、Stage 1でダウンロードした bin/node を使って復号後の .js を起動し、ここからようやくEtherRAT本体としての動作が始まります。

Stage 3：EtherRAT本体が常駐し、C2へ接続

本体のインプラントが起動すると、まず最初にやるのが「どのC2に接続するか」を決める処理です。ここで、イーサリアムのスマートコントラクトを叩いてC2のURLを取得する、という非常に変わった方法を使っています。

C2のURLが分かると、EtherRATは500ミリ秒ごとにC2へHTTPアクセスを送り続け、レスポンス内容をJavaScriptとしてその場で実行します。Node.jsの require や process などのオブジェクトがそのまま渡されるため、攻撃者側から見ると「侵入先のサーバで自由にNode.jsのコードを叩けるリモートシェル」を持っているのと同じ状態になります。

この段階で同時に、後述する複数の永続化仕掛けをホストに書き込み、再起動後も起き上がれるように土台を作ります。

スマートコントラクトを使った指令サーバ隠蔽

EtherRATが一番目を引くのは、C2の解決方法です。一般的なマルウェアは、「特定のドメイン名」「特定のIPアドレス」に向かって通信しますが、EtherRATはその手がかりをイーサリアムのスマートコントラクトに隠しています。

インプラントの中には、あらかじめコントラクトのアドレスと、関数を指定するためのセレクタ、パラメータとなる値が埋め込まれています。起動時にこれらを使って eth_call を投げ、チェーン上から「今使うべきC2 URL」を読み取る仕組みです。

1ヶ所のRPCエンドポイントだけに問い合わせるのではなく、複数のパブリックRPC（例えば eth.llamarpc.com や ethereum-rpc.publicnode.com など）に同じリクエストを並列で投げ、その結果の多数決で「正しい値」を決めている点です。1つのRPCがシンクホール化されても、他のノードが正しい値を返していれば、多数決で上書きされる設計になっています。

一度C2 URLが分かると、EtherRATは /api/ランダム/ボットID/ランダム.拡張子?token=… のようなパスに対して定期的にGETを投げます。拡張子は png や jpg、css などがランダムで選ばれており、見かけはCDNから静的ファイルを取っているトラフィックにかなり近くなります。

C2からそれなりの長さのレスポンスが返ってきた場合、その内容を非同期関数として評価し、require や process を渡して実行します。攻撃者側から見ると、イーサリアム上のスマートコントラクトひとつで全ボットの接続先を切り替えつつ、各ホスト上で自由にNode.jsのコードを走らせられる、というなかなか贅沢な環境になっています。

Linuxでの永続化

侵入先のホストに長く居座るため、EtherRATはLinux環境向けにかなり念入りな永続化を仕掛けてきます。Sysdigの分析では、少なくとも5種類の方法が確認されています。

1つ目は systemdのユーザーサービス です。~/.config/systemd/user にランダムな16進文字列を名前にした .service ファイルを置き、ExecStart にインプラントのパスを指定して systemctl --user enable / start を実行します。説明欄も「User Application Service」のような無難な文言になっており、ざっと眺めただけでは怪しく見えません。

2つ目は XDG Autostartの仕組み を使う方法です。~/.config/autostart に .desktop ファイルを作り、Exec にインプラントを指定します。こちらも Name=System Service とし、Hidden=true, NoDisplay=true を付けて、通常のデスクトップ設定画面からは表示されないようにしています。サーバ用途では効かないケースもありますが、デスクトップ用途のLinuxにも対応しようとしているのが分かります。

3つ目は cronの@rebootジョブ です。crontab -l の結果に1行付け足す形で、@reboot sleep 30 && <node …> >/dev/null 2>&1 & を追加します。再起動後30秒待ってからバックグラウンド起動するため、起動シーケンスに紛れやすくなっています。

4つ目と5つ目は、シェルの初期化ファイルの改ざん です。ユーザーのホームディレクトリにある .bashrc と .profile を読み込み、まだ自分の起動行が含まれていなければ、nohup <node …> >/dev/null 2>&1 & といった1行を追加します。これにより、ユーザーがログインするたびにインプラントが起動するようになります。

これらの有効・無効の状態は、先ほどのステートファイルに記録され、何度も同じものを重複して追加しないように制御されています。運用側から見ると、「1つ見つけて消して安心」ではなく、永続化のパターンをひととおり洗い出して潰す つもりで調査しないと、すぐに復活されてしまう設計です。

北朝鮮「Contagious Interview」との関係

Sysdigは、EtherRATの設計やコードの書き方が、過去に北朝鮮系とされるキャンペーンで使われたツール群とよく似ている点をいくつか挙げています。特に比較されているのが、「Contagious Interview」キャンペーンで確認されたBeaverTailなどのマルウェアです。

具体的には、AES-256-CBCで暗号化したペイロードをローダーで復号する構造や、Node.jsベースのバックドアという点が共通しています。また、ブロックチェーンをC2に使う手法自体も、DPRK系の別キャンペーンで見られているものと似通っています。

一方で、EtherRATには従来のDPRKツールとは異なる特徴もあります。例えば、Node.jsを自前でバンドルするのではなく、わざわざ nodejs.org からダウンロードして使う設計は、検出回避をより強く意識したアップデート版とも言えますし、永続化の仕掛けがここまで多段になっている点も、長期的な潜伏を強く意識したチューニングに見えます。

こうした共通点・相違点から、Sysdigは「過去のDPRKキャンペーンで使われたツールセットと技術的に強い関連がある可能性が高い」としつつも、「まったく同じグループだと断定できるほどコードが一致しているわけではない」としています。複数の北朝鮮系グループ間でツールやアイデアが共有されているのか、それとも別の攻撃者が意図的にDPRK風の手口を取り入れているのか。

現時点ではどちらとも言い切れないものの、「国家レベルのオペレーションで使われている技術が、そのままReact2Shellにも持ち込まれている」ことだけは確かです。

情報システム部門として取るべき対策

ここまで見ると、「とにかく高度で恐ろしいマルウェアだ」という印象だけが残りがちですが、実務として何をやるかはもう少し地に足をつけて整理する必要があります。大きく分けると、「入口を塞ぐ」「感染がないか探す」「見つかった場合の後始末」という3つの観点になります。

まず一番は、React2Shellの入り口を塞ぐことです。React／Next.jsを使ったサービスを棚卸しし、RSCやApp Routerを利用しているアプリがあれば、react-server-dom-* とNext.js本体のバージョンを確認します。影響範囲のバージョンを使っている場合は、React／Next.jsのどちらもパッチ済みバージョンへ更新し、再ビルド・再デプロイまで完了させるところまでをセットで行う必要があります。

次に、すでに侵害されていないかを確認します。Webサーバから外向きに出ている通信ログを見て、nodejs.org/dist/ への不自然なアクセスや、複数のイーサリアムRPCエンドポイントへの定期的な接続がないかをチェックします。同時に、~/.local/share 配下の怪しい隠しディレクトリ、~/.config/systemd/user の謎のサービス、crontab -l に見覚えのない @reboot 行、.bashrc / .profile に追加された nohup 行なども確認すると、EtherRATのようなマルウェアが残していく痕跡を拾いやすくなります。

参照

EtherRAT: DPRK uses novel Ethereum implant in React2Shell attacks