ハッカーが約12件のDeFiプロトコルのウェブサイトを乗っ取り、不正なフロントエンドに接触したユーザーから約13万8,000ドルを流出させました。被害を受けたすべてのサイトに共通していたのは、ドメインがName.com経由で登録されていたという点です。この事件は、DeFiプロトコルの信頼の対象がスマートコントラクトにとどまらず、UIを提供するウェブインフラストラクチャにまで及ぶことを改めて示しています。

DeFiサイト乗っ取り事件で分かっていること

The Blockの2026年10月31日の報道によると、攻撃者は約12件のDeFiウェブサイトを制御下に置き、ユーザーを悪意あるフローへ誘導し、約13万8,000ドルの資金を窃取しました。

確認されている事実は限定的です。被害を受けたのは約12件のDeFiウェブサイトで、いずれもName.com経由で登録されており、ユーザー資金約13万8,000ドルが盗まれました。標的となった具体的なプロトコル、正確な攻撃ベクター、個別の被害者数は、現時点の報道では確認されていません。登録業者の共通使用だけでは因果関係は立証されず、Name.comが直接的な障害点であると確認されたわけでもありません。

未確認の点

未確認の報道によれば、Name.com登録の共通性は、レジストラレベルでの認証情報の漏えいまたはアカウント乗っ取りを示唆している可能性があり、それが成立していれば、攻撃者は基盤となるスマートコントラクトに触れることなくDNSレコードを改ざんし、ドメインのトラフィックを転送できたことになります。一方、レジストラアカウントの侵害、ソーシャルエンジニアリング、あるいはまったく別のベクターが関与した可能性もあります。

この区別は、被害を受けたユーザーとプロトコルチームの双方にとって重要です。DNSレコードが改ざんされていた場合、オンチェーンのスマートコントラクト自体は無傷である可能性があり、プロトコルの金庫や流動性プールは保全されていても、偽のフロントエンドに接触したユーザーが損失を負うことになります。

ドメインインフラ経由のフロントエンド乗っ取りには業界内で前例があります。2022年には、攻撃者がドメインプロバイダーのアカウントを侵害した後、Curve FinanceのDNSを偽インターフェースのクローンへ転送し、この広く引用された事例が、DeFiチームのセキュリティチェックリストにレジストラとDNSの管理を載せるきっかけとなりました。ただし、前例は証拠ではありません。今回のName.com登録の共通性が中心的な要因か偶然かは、被害を受けたチーム自身のインシデント調査によってのみ確定します。

乗っ取られたDeFiサイトがユーザーにもたらすリスク

ウェブフロントエンドの侵害は、スマートコントラクトのエクスプロイトとは構造的に異なります。攻撃者はドメインを制御すると、正規のインターフェースを視覚的に同一に複製しながら、ウォレット接続エンドポイント、コントラクトアドレス、トランザクションのcalldataを密かに差し替えることができます。一見日常的な承認に署名したユーザーは、実際にはドレイナーコントラクトにトークン残高全額を引き出す権限を与えていた可能性があります。

トランザクションに署名する前にユーザーが確認すべきこと

DeFiインターフェースでウォレットを接続したりトランザクションに署名したりする前に、ユーザーはブラウザのURLだけでなく、対話対象のコントラクトアドレスをプロトコルの公式ドキュメントと照らして独自に確認すべきです。トランザクションデータの読み取りと検証の方法を理解することは不可欠であり、Secure Transaction Verification and Authorization（STVA）フレームワークは、承認前のcalldata検査の手順を詳述しています。ドメインが正しく解決され、有効なSSL証明書が表示されていても、DNSやホスティング層でフロントエンドが改ざんされていない保証はありません。

フィッシング耐性のあるハードウェアウォレットは、ブラウザとは独立にデバイス画面上でトランザクションの詳細を表示でき、ユーザーに第二の検証層を提供します。それでも、フロントエンドを支配する執拗な攻撃者は、誤解を招くトランザクション説明を作り出せます。唯一確実な防御は、接続中のdAppインターフェースではなく、公式のGitHubリポジトリやガバナンス文書に基づくプロトコルの正規のオンチェーンデプロイと、宛先コントラクトアドレスを照合することです。

侵害されたコントラクトに付与されたトークン承認は、明示的に取り消されるまでオンチェーンに残ります。これらのサイトが攻撃者の支配下にあった期間にウォレットを接続しトランザクションに署名したユーザーは、未処理の承認を潜在的に悪意あるものと扱うべきです。承認管理ツールを使えばERC-20トークンにわたる権限の監査と取り消しが可能ですが、取り消すべき正しいコントラクトアドレスと操作すべき正しいネットワークを独自に確認した後でのみ行うべきです。

ユーザーとDeFiチームが次に取るべき対応

ユーザーの対応

被害を受けたDeFiウェブサイトのいずれかに接触したユーザーはまず、当該プロトコルがフロントエンドの復旧と検証を公に確認するまで、ウォレットの接続や新規トランザクションへの署名を控えるべきです。公式の情報は、プロトコルの認証済みソーシャルアカウントやガバナンスフォーラムから入手すべきであり、フロントエンド侵害後に二次的な攻撃ベクターとしてよく使われる、ダイレクトメッセージやコミュニティチャットに埋め込まれたリンクに頼ってはなりません。被害を受けたプロトコルは現時点の報道で特定されていないため、あらゆるDeFiフロントエンドのユーザーは、自分が被害を受けていないと決めつけるのではなく、利用しているプロトコルからの直接の発表に注目すべきです。

インシデント期間中にトランザクションへ署名したユーザーについては、検証済みの独立した情報源から正しい悪意あるコントラクトアドレスを確認した後にのみ、承認の取り消しを行うことが望まれます。誤ったコントラクトを取り消すとガスを無駄にし、誤った安心感をもたらします。Aave V4などのプロトコルは正規のコントラクトレジストリを公開しており、正当なプロトコルコントラクトと攻撃者が配備したドレイナーを区別する参考点として利用できます。

プロトコルチームの対応

被害を受けたチームは、攻撃チェーン全体が確認されるまで、この事案を進行中のインシデントとして扱うべきです。直近の優先事項には、ドメインレジストラのアカウントアクセスログの監査、Name.comアカウントに関連するすべての認証情報の変更、既知の正常なスナップショットとのDNSレコードの照合、攻撃期間中に発行された不正な証明書の有無を確認するためのHTTPS証明書トランスペアレンシーログのチェックが含まれます。

また、チームは変更を加える前にすべてのインシデント証拠を保全すべきです。攻撃期間に関するフォレンジックデータ（DNS変更ログやレジストラとのやり取りを含む）は、何が、いつ侵害されたのかを正確に特定するために必要になります。調査中の憶測を含む発信ではなく、攻撃ベクターの確定後に明確で時刻を明示したインシデント報告を公表することが、被害を受けたコミュニティが期待する基準です。

二要素認証の強化やレジストラレベルのドメインロックを含むレジストラアカウントのセキュリティは、攻撃者の認証情報が有効であっても不正なDNS変更を防ぐ基本的な強化策です。ドメインロックは、レジストラによる明示的な確認なしには転送やDNS変更を阻止するため、実際の資金を伴うトランザクションにおけるユーザー接点の信頼面としてウェブサイトを持つあらゆるプロトコルにとって、意味のある管理手段となります。

より広い教訓

約12件のプロトコルにわたって報告された13万8,000ドルの損失は、イーサリアムのDeFiの総TVLと比べれば控えめな額です。しかし、この事件が露呈した構造的脆弱性、すなわちweb2のレジストラアカウントがプロトコルのセキュリティスタックにおける最弱のリンクになり得るという問題は、中央登録のドメインに依存してユーザーインターフェースを提供するすべてのDeFiプロジェクトに当てはまります。DNS監視、レジストラアカウントの強化、コントラクトの独自検証に関するユーザーガイダンスを含むフロントエンドのセキュリティは、スマートコントラクト監査に適用されているのと同等の運用上の厳格さに値するものです。