Last Updated on 2026年8月8日 by oba3
トレンドマイクロ（Trend Micro）の調査で、攻撃者がBNBスマートチェーン（BNB Smart Chain）のテストネット上に置いたスマートコントラクトを、マルウェア配信の指示や攻撃状況の確認に利用していたことが明らかになった。確認されたのは、クリアフェイク（ClearFake）と呼ばれる攻撃キャンペーンで使われた手法で、ブロックチェーンから次の攻撃先や実行内容に必要な情報を取得する。
ここで問題になっているのは、BNB Smart Chain自体が侵害されたことではない。誰でもデータを書き込み、公開状態を維持できるブロックチェーンの性質を、攻撃者が耐障害性の高い配信基盤として利用した点にある。分散化や改ざん耐性というWeb3の利点が、そのまま削除しにくい攻撃インフラへ転用される事例だ。
何が起きたのか？
トレンドマイクロは2026年5月、侵害されたウェブサイトから始まるクリアフェイクの攻撃経路を分析し、BNB Smart Chainのテストネット上に配置されたスマートコントラクトが指令配信に使われていたと報告した。
攻撃では、改ざんされたウェブサイトを閲覧した利用者にJavaScriptが読み込まれ、そのコードがBNB Smart Chain上のスマートコントラクトを参照する。コントラクトから返された情報を使って、次に接続するサーバーや実行するコードを決める仕組みが組み込まれていた。
このようにブロックチェーンを攻撃用データの保存や取得に使う手法は、イーサハイディング（EtherHiding）と呼ばれる。従来の攻撃では、攻撃者が所有するウェブサーバーやドメインから指令を取得することが多かったが、この方式では公開ブロックチェーンが途中の情報伝達層として使われる。
今回トレンドマイクロが分析した攻撃では、最終的にセクトップRAT（SectopRAT）とACRスティーラー（ACRStealer）が同時に展開された。前者は遠隔操作やブラウザーセッションへのアクセスにつながる機能を持ち、後者は認証情報などを窃取する情報窃取型マルウェアとして知られる。
さらに攻撃者は、スマートコントラクトを利用して感染が実際に成立したかを追跡する仕組みも使用していた。つまりブロックチェーンは単なるコード置き場ではなく、攻撃経路の制御と状況確認の一部として組み込まれていた。
ただし、スマートコントラクトへアクセスしただけで直ちに感染するわけではない。確認された攻撃では、侵害サイトや偽の確認画面などを通じて利用者を誘導し、最終的に端末上で不正な処理を実行させる工程が存在した。ブロックチェーンは攻撃全体を構成する複数の部品の一つである。
なぜ重要なのか？
従来のマルウェア対策では、攻撃者が使うドメインやサーバーを特定し、通信を遮断したりホスティング事業者へ削除を求めたりする方法が有効だった。しかし、スマートコントラクトへ保存された情報は、通常のウェブサーバー上のファイルとは性質が異なる。
ブロックチェーンへ記録されたデータは、特定のホスティング事業者だけの判断で消すことが難しい。攻撃者が一般に利用されるブロックチェーンのRPC接続を使えば、通信先も一見すると正規のWeb3インフラに見える。
その結果、防御側は特定の悪性ドメインだけを遮断すればよいとは限らなくなる。正常なブロックチェーン通信と、攻撃用コントラクトへのアクセスを区別しなければならないため、従来型のURLやサーバー単位の防御だけでは対応しにくい。
市場構造への影響
ブロックチェーンの価値の一つは、特定事業者が停止しても記録や処理を維持できる耐障害性にある。金融取引やデジタル資産の管理では、この性質が中央管理者への依存を減らす。
しかし、同じ特徴は攻撃者にも利用できる。悪意のある情報がスマートコントラクトへ保存されれば、中央の管理者へ削除を依頼するだけでは排除できない。インフラの耐障害性が、攻撃指令の耐障害性にもなる。
ここで重要なのは、スマートコントラクトそのものを危険な仕組みと考えないことだ。問題は、公開ブロックチェーンが誰でも利用できる汎用インフラであるため、合法的なアプリと同じ機能を攻撃者も使える点にある。
Web3インフラが一般的な企業ネットワークやブラウザーから利用されるほど、防御側はチェーン名だけで通信を許可する方法を取りにくくなる。どのコントラクトへ接続し、どのデータを読み、その後端末上で何が実行されたかまで見る必要が出てくる。
資金・規制・流動性との関係
今回の事例は、分散型金融の資金プールが直接侵害された事件ではない。そのため、BNB Smart Chain上の資金流動性やバリデーターの安全性が損なわれたと解釈するのは適切ではない。
一方、最終的に配信される情報窃取型マルウェアは、ブラウザー認証情報や暗号資産関連のデータを狙う可能性がある。攻撃経路の途中にブロックチェーンが使われることで、暗号資産利用者やWeb3開発者が通常利用する通信の中へ攻撃インフラが紛れ込む。
防御側にとっては、公開RPCへの接続を全面的に禁止すると正規のWeb3アプリまで止めてしまう問題がある。逆にすべて許可すれば、悪意あるスマートコントラクトへのアクセスも通過する。このため、通信先だけでなく、端末上のスクリプト実行や後続プロセスまで組み合わせて判断する必要がある。
現時点で、この攻撃手法を受けてBNB Smart Chain自体へ新たな規制措置が導入された事実は確認されていない。技術面では、悪性コントラクトの識別、ブラウザー側の防御、エンドポイント監視などを複数組み合わせることが中心になる。
初心者向け補足
スマートコントラクトは、ブロックチェーン上で動くプログラムである。分散型取引所やステーブルコインなどにも使われるが、必ず金融処理だけを行うわけではなく、文字列や設定情報を保存して外部のプログラムから読み出すこともできる。
今回の攻撃では、その保存機能が悪用された。攻撃者は自分のサーバーだけに指令を置くのではなく、スマートコントラクトへ情報を置き、感染対象の端末側から読み出せるようにした。
そのため、BNB Smart Chainを利用したこと自体が危険なのではない。危険なのは、侵害されたウェブサイトや偽の確認画面などから不正なコードが実行され、そのコードが攻撃者のスマートコントラクトを参照する流れである。
Web3Timesの視点
今回見るべきなのは、マルウェアがBNB Smart Chainを使ったという珍しさではない。分散型インフラの長所である削除困難性と可用性が、正規サービスだけでなく攻撃者にも提供されるという構造だ。
中央管理型の攻撃サーバーなら、ドメイン停止やサーバー押収によって経路を断てる場合がある。公開ブロックチェーン上の情報は同じ方法では消せないため、防御側は悪性データそのものを削除するのではなく、そのデータを取得し実行する経路を遮断する必要がある。
これはWeb3の安全性を、チェーンのコンセンサスやスマートコントラクト監査だけで測れないことも示している。ブロックチェーンが他のウェブサービス、ブラウザー、端末、開発環境と接続するほど、正常なチェーン利用と悪意ある利用を識別する仕組みが重要になる。
分散化は停止しにくい金融インフラを作る一方、停止しにくい攻撃インフラにもなり得る。今後の焦点はブロックチェーンを遮断することではなく、どのコントラクトが何の目的で呼び出され、その結果として端末上で何が起きたのかを追跡できる監視基盤を作れるかにある。
