NullReceiver:検知は困難だが、再利用される攻撃者ウォレットは依然露見

NullReceiverは、北朝鮮(DPRK)によるブロックチェーンC2の手口を洗練させたステルス重視の亜種です。一見普通に見えるイーサリアム送金の裏に再利用可能な攻撃者ウォレットを隠しつつ、稼働中の指令サーバーを特定できるだけのバイト数はあえて露出させています。

Tailwind CSSプラグインを装った2つのトロイの木馬入りnpmパッケージ、[email protected]と[email protected]には、私たちが「NullReceiver」と呼ぶ新しいブロックチェーンベースのC2解決手法が実装されています。

これらのパッケージは、Node.jsのリモートアクセスやサプライチェーン侵入のためにnpmを繰り返し悪用してきたDPRKの「Contagious Interview」キャンペーンとの関連が確認されています。

VPN&リモートアクセス

今回の調査結果はすべて、公開されているnpmアーカイブファイルの静的解析と、攻撃者ウォレットの活動に対する読み取り専用のRPC呼び出しに基づいています。

この悪意あるコードには、検知用タグ(global.i = "A10-npm3!")、ハードコードされた攻撃者ウォレットS = "0xa322e5f3d311d3080e6f0121063e9adc2490ef1a"、そしてウォレットの直近の送金トランザクションをイーサリアムに問い合わせる際に使う小規模なRPCプールR = ["https://1rpc.io/eth", "https://eth.drpc.org"]が埋め込まれています。

オンチェーン上でペイロードが実行されることはなく、スマートコントラクトとのやり取りも一切ありません。ブロックチェーンは純粋に設定情報の取得元として利用されているだけです。

NullReceiverは、「秘密情報」をトランザクションのデータフィールドから、送金先アドレス自体へと移す仕組みです。マルウェアのロジック自体は単純ですが、既存のEtherHiding中心の検知手法を回避できるよう緻密に設計されています。

実行時、このNode.js製RAT(遠隔操作型マルウェア)のコードは、ヘルパー関数Jを介して設定済みのRPCエンドポイントの1つにHTTPS JSON-RPCで問い合わせを行い、攻撃者ウォレットの直近の送金トランザクションを取得します。

次に最新のトランザクションを選び出し、そのto(送金先)フィールドを抽出して、そのアドレスの生バイトから直接IPv4アドレスをデコードします。デコードが完了すると、RATはそのIPアドレスへC2接続を開始し、通常のバックドア活動を始めます。

GBHackersに寄せられたレポートの中でOpensource malwareは、攻撃者らはイーサリアムを「耐障害性のある読み取り専用のデッドドロップ」として扱うことで、従来型のC2インフラの利用を今なお避け続けていると指摘しています。マルウェアはC2エンドポイントを一切ハードコードせず、実行時にオンチェーンで検索するのです。

取得されたトランザクションは意図的に極限まで簡素化されています。ETH送金額はゼロ、inputフィールドは「0x」で、これはイーサリアムのトランザクションとして考えられる最も低コストな形です。

唯一意味を持つフィールドは、でっち上げられた送金先アドレスです。このバイト列をデコードすると166.88.134.62というIPアドレスになり、末尾のバイトはASCII文字列「helloipbot!!」を綴っています。

NullReceiverのウォレットの痕跡

この文字列は、マルウェア自体が必要とするものというより、攻撃者側のツール向けの人間が読める目印である可能性が高いと考えられます。重要なのは、コントラクト呼び出しもペイロードフィールドも存在しないという点です。

アンチウイルス&マルウェア

「マルウェアがスマートコントラクトと通信している」あるいは「マルウェアがcalldataから隠しデータを読み取っている」といった痕跡を探すことに慣れた防御側の目には、この手口は明らかに不審な点がないように映ります。

Google Threat Intelligenceが2025年10月に公開したEtherHidingは、イーサリアムのバーンアドレス0x000…dEaDとトランザクションのcalldataを秘匿チャネルとして利用します。

攻撃キャンペーンは、この固定された有名な宛先にトランザクションを送信し、C2のURLやスクリプトをデータフィールドに埋め込みます。防御側はバーンアドレスを継続的に監視し、不審なcalldataを含む送金を検出することでこれを捕捉してきました。この方式はEtherHidingを目印として捉えやすくする一方、1バイトあたりのコストは高くなるものの、格納できる容量は大きくなります。

NullReceiverは、この弱点を意図的に補正しています。送金先を再利用することは一切なく、問い合わせのたびに、わずか数バイトのデータを符号化するためだけに存在する使い捨ての新しい送金先アドレスを用いるのです。

指紋採取の手がかりとなる空でないcalldataは存在せず、スマートコントラクトもなく、バーンアドレスに相当する既存の検知フックもありません。

その代償となるのが容量です。NullReceiverはIPアドレスや小さなトークン程度しかアドレスのバイト列に収められないため、本格的な配送機構というよりは隠れたビーコンに近い存在ですが、このDPRKのnpmツールにとってはそれで十分なようです。両手法には依然として1つの構造的弱点が共通しています。それは、送金元ウォレットがキャンペーン全体で使い回されているという点です。

bianira-uiとfluid-type-uiでは、同一の攻撃者ウォレットがすべての問い合わせを支えています。つまり、アナリストがいったんこのウォレットを特定すれば、以降の送金トランザクションを監視し、EtherHidingのバーンアドレスへのペイロードに対して行ったのと同様に、NullReceiverのデッドドロップを事後的に再構築できるということです。

DPRKは、難読化されたコード文字列からカスタムエンコーディングへ、固定ドメインからブロックチェーンリゾルバーへ、そしてEtherHidingへと、その都度発覚した手口から次々に手を変えてきた実績があります。この流れを踏まえると、NullReceiverはDPRKのnpmキャンペーンにおける次の既定路線となっても不思議ではありません。

防御側は、不審なウォレットからの通常のゼロ額送金であっても、「でっち上げられた」送金先アドレスを持つものは潜在的なC2ビーコンとして扱うべきです。また、ブロックチェーン分析の対象を、スマートコントラクトやcalldataを中心としたヒューリスティックにとどめず、さらに広げていく必要があります。

侵害指標(IOC)

注: IPアドレスおよびドメインは、誤って名前解決やハイパーリンク化されるのを防ぐため、意図的に無効化表記(例: [.])にしています。再度有効な形式に戻す作業は、MISP、VirusTotal、SIEMなど管理された脅威インテリジェンス基盤内でのみ行ってください。

100万ドルのデータ侵害保証は本物の補償と言えるのか?: 無料の「AI SOC侵害保証ガイド10のポイント」をダウンロード

データ侵害対応