Last Updated on 2026年8月10日 by oba3
ブロックチェーンをマルウェア配信や指令取得に利用する「イーサーハイディング（EtherHiding）」への警戒が改めて強まっている。2026年8月3日にはセキュリティ企業が同手法をあらためて分析し、分散型台帳の耐障害性が攻撃者にとっても強力なインフラになり得る点を指摘した。具体例として重要なのが、トレンドマイクロ（Trend Micro）が5月26日に公表したクリアフェイク（ClearFake）の調査だ。この事例ではBNBスマートチェーン（BNB Smart Chain・BSC）のテストネット上にあるスマートコントラクトが、攻撃経路の案内や実行状況の確認に利用された。BNBチェーン自体が侵害されたわけではない。見るべきなのは、正規サービスにとっての「止まりにくさ」が、攻撃者にとってはテイクダウンされにくい配信基盤にもなるという二面性だ。
何が起きたのか？
今回の技術的な中心となる事例は、トレンドマイクロが5月に分析したクリアフェイクの攻撃キャンペーンだ。攻撃者は侵害したウェブサイトから利用者を誘導し、BNBスマートチェーンのテストネット上に配置したスマートコントラクトから、その後の攻撃に必要な情報を取得する仕組みを使っていた。
スマートコントラクトが最終的なマルウェア本体のすべてを直接送り込む単純な構成ではない。ブロックチェーン上の情報は、次にアクセスすべき場所や悪意ある処理を選択するためのルーティング情報などとして使われた。最終段階では遠隔操作型マルウェアのセクトップRAT（SectopRAT）と情報窃取型のACRスティーラー（ACRStealer）が展開された。
さらに特徴的なのは、同じ攻撃者に関連する複数のスマートコントラクトのうち、一部が感染処理の実行状況を確認するオンチェーン追跡にも利用されていた点だ。ブロックチェーンは単なるデータ置き場ではなく、攻撃経路を変更したり、処理が成立したかを確認したりする仕組みの一部になっていた。
なお、トレンドマイクロの元調査は8月7日に新しく判明したものではなく、5月26日に公開されたものだ。8月時点ではイーサーハイディングそのものがサイバー防御上の耐障害型インフラとして改めて取り上げられている。したがって、今回のニュースは新しいBNBチェーン侵害ではなく、既存事例から見える攻撃インフラの変化として読む必要がある。
なぜ重要なのか？
従来型のマルウェアでは、攻撃者が管理するサーバーやドメインを見つけて遮断することが有効な防御手段だった。ホスティング会社やドメイン管理事業者が対応すれば、攻撃者と感染端末の通信経路を止められる場合がある。
イーサーハイディングでは、この役割の一部を公開ブロックチェーンへ移す。スマートコントラクトに保存された情報は、通常のウェブサーバーのファイルを削除する方法では消せない。攻撃者は正規のブロックチェーンノードやRPC経由で情報を読み取れるため、単一のサーバーを停止する防御モデルが通用しにくくなる。
ただし、今回利用されたのはBSCのテストネットであり、メインネット上の資産やコンセンサスが侵害されたわけではない。また、ブロックチェーンへ接続しただけで利用者が自動的に感染するわけでもない。クリアフェイクでは偽のCAPTCHAなどを利用し、利用者自身に不正なコマンドを実行させるクリックフィックス（ClickFix）型のソーシャルエンジニアリングも重要な役割を持っていた。
市場構造への影響
今回の事例は、分散化の価値を安全か危険かの二択で評価できないことを示している。公開ブロックチェーンは、特定企業が停止してもデータへアクセスし続けられることに価値がある。その性質は金融取引や分散型アプリケーションにとって強みだが、利用目的を自動的に善悪で選別する機能ではない。
攻撃者が同じ性質を使えば、耐障害性はテイクダウン耐性へ変わる。正規サービスのために存在するRPCやスマートコントラクト読み取り機能を利用するため、通信先のドメインだけを見て悪意のあるアクセスを判別することも難しくなる。
その結果、防御の中心は「悪意あるデータをブロックチェーンから削除する」ことではなく、そのデータがブラウザーや端末へ届き、実行される経路を止める方向へ移る。チェーン、RPC、ブラウザー、スクリプト、エンドポイントという複数層をまとめて監視する必要がある。
これはWeb3インフラ事業者にも関係する。ブロックチェーンそのものが正常でも、その正規機能が攻撃チェーンへ組み込まれる場合、RPC事業者やセキュリティ企業、ブラウザー、企業ネットワークのどこで防御するかという責任分界が重要になる。
資金・規制・流動性との関係
今回の論点は市場への資金流入より、企業ネットワークがブロックチェーン通信をどう管理するかにある。Web3を業務で利用していない企業であれば、不要なBSCテストネットRPCへの通信を遮断することは有効な対策になり得る。
一方、Web3サービスを開発・利用する組織では、ブロックチェーン通信を一括して禁止することは現実的ではない。その場合は、許可するRPCを限定し、不審なスマートコントラクトへのアクセスとブラウザー側の挙動、端末上での異常なコマンド実行を組み合わせて確認する必要がある。
トレンドマイクロは防御策として、不要なBSCテストネットRPC通信の制限に加え、不要なWindows WebClient機能の無効化や、偽CAPTCHAを通じてコマンド実行を求める手口への利用者教育なども挙げている。つまり防御はブロックチェーンだけを監視すれば完了するものではない。
情報窃取型マルウェアが端末へ到達すれば、ブラウザーに保存された認証情報やセッション、暗号資産ウォレット関連情報などが狙われる場合もある。ただし、今回の事例について具体的な暗号資産盗難額が確認されているわけではなく、資金被害を推定で拡大して説明するべきではない。
初心者向け補足
スマートコントラクトとは、ブロックチェーン上に配置できるプログラムやデータの仕組みだ。暗号資産の交換だけでなく、外部プログラムが読み取る情報を保存することもできる。イーサーハイディングでは、この機能が攻撃経路の一部として悪用される。
RPCとは、アプリケーションがブロックチェーンのノードへ問い合わせるための窓口のようなものだ。通常のWeb3アプリもRPCを利用して残高やスマートコントラクトの状態を確認するため、RPC通信そのものが悪意ある行為というわけではない。
今回重要なのは、正規機能の組み合わせが攻撃に転用されたことだ。侵害されたウェブサイト、偽CAPTCHA、ブロックチェーン上の情報、端末でのコマンド実行がつながることで感染が成立する。そのため「BNBチェーンがハッキングされた」「スマートコントラクトを読むと感染する」という理解は正確ではない。
Web3Timesの視点
Web3Timesが今回見るのは、BNBチェーンが危険なネットワークかどうかではない。焦点は、分散型インフラが持つ耐障害性を正規利用者だけが使うわけではないという点だ。
ブロックチェーンの強みは、特定の管理者へ依存せずデータへアクセスできることにある。しかしその強みを攻撃者が利用すれば、中央サーバーを一つ停止して攻撃を終わらせる従来型の対応が難しくなる。分散化は防御機能そのものではなく、善意と悪意の双方が利用できるインフラ特性だ。
今回特に重要なのは、オンチェーン情報が攻撃経路の案内だけでなく実行確認にも使われたことだ。攻撃者がブロックチェーンを単なる保存場所ではなく、耐障害型の制御基盤として組み込み始めれば、防御側もドメインやIPの遮断だけでは対応しにくくなる。
今後追うべきなのは悪意あるスマートコントラクトの件数ではない。Web3を必要としない環境では不要なRPCをどこまで遮断できるか、必要な環境ではコントラクトへのアクセスと端末挙動をどう結び付けて検知するか、攻撃者がチェーンやコントラクトを変更した際に防御側がどの速度で追随できるかが重要になる。ブロックチェーンの普及が進むほど、分散化の強みを維持しながら、その同じ性質を利用する攻撃をどこで止めるかが技術インフラ側の課題になる。
