Name.comDeFiサイトのドメインが乗っ取られ資金抜き取りページに

概要

• 10月30日（金）の夜、米東部時間で、複数のDeFiサイトが本物のドメインのまま攻撃者のページを表示し始めた。訪問者が「Connect Wallet」を押すと、資金を移す承認や署名を求める画面が出る仕組みだった（The Block、The Crypto Times）。
• 使われたのは Step Drainer という、販売・貸し出しされている資金抜き取りの道具。LevelBlue SpiderLabs は4月に、全ソースコードが約750ドル、盗んだ額の20%を取る版が150ドルで売られており、20以上のブロックチェーンに対応するとうたっていると報告していた（The Block）。
• 被害サイトの DNS を運用している事業者はばらばらで、Cloudflare、Vercel、Name.com 自身のネームサーバーが混ざっていた（The Block、code404zero）。共通点は登録先のレジストラだけだった。
• 侵入経路は公表されていない。Name.com 本体の問題か、Vercel のような再販事業者側か、個々の顧客アカウントかはわかっていない（code404zero、Crypto Briefing）。

この記事では、ベンダー・公的機関・研究者・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。

何が起きたか（時系列）

時刻は出典の表記を UTC に直したもの。10月30日の米東部時間は夏時間（UTC−4）。

技術的な問題点（根本原因）

事実

• 攻撃はコントラクトではなく、その手前の「サイトの住所」で起きた。ドメインのネームサーバーや DNS レコードを書き換えれば、利用者が正しいURLを入力しても攻撃者のサーバーにつながる（Crypto Briefing、code404zero）。
• Flap と Kintsu、Blockaid は、乗っ取りがレジストラの段階で起きたと述べている（Crypto Briefing）。複数の DNS 事業者にまたがっていることも、ネームサーバーを決めるレジストラの段階での変更と整合する、と code404zero は指摘している。
• 盗んだ資金は3つのウォレットに 15%・55%・30% の固定比率で分けられていた。同じ3つのウォレットが BNB Chain、Ethereum、Robinhood Chain、Monad で同じ比率の入金を受けていた。Monad では Kintsu のステーキングトークン sMON を引き出し、Robinhood Chain ではトークン化株式（NVDA、AAPL など）を Morpho から引き出して ETH に替えていた（The Block）。
• 根本原因は、10月31日時点で Name.com から公表されていない。Origami は、Vercel と Name.com が原因の分析を出すまでボールトを止めたままにするとしている（The Block を引用した code404zero）。

考察

• 同じレジストラの多数の暗号資産関連ドメインが同じ夜に一斉に書き換えられ、DNS 事業者がばらばらだったことから、個々の顧客がそれぞれ偶然パスワードを盗まれたとは考えにくい。レジストラか再販事業者の、複数の顧客をまたいで操作できる仕組み（サポート用の機能、API、管理画面など）が使われた可能性があるが、これは推測で、公式には確認されていない。
• 被害額が「大きなブリッジ攻撃」に比べて小さいのは、発覚から警告までが1〜2時間と早く、ウォレットの警告機能も働いたためと見られる。

攻撃・侵入経路

flowchart TD
    A[攻撃者] --> B[レジストラ層<br/>Name.com／再販の Vercel Domains／顧客アカウントのいずれか<br/>経路は未公表]
    B --> C[DeFiサイトのドメインの<br/>ネームサーバー・DNS を書き換え]
    C --> D[利用者が正しいURLで<br/>アクセス]
    D --> E[Step Drainer のページ<br/>Connect Wallet]
    E --> F[資金を移す承認・署名]
    F --> G[3つのウォレットへ<br/>15%・55%・30%で分配]
    C --> H[Blockaid・各プロジェクトが警告]
    H --> I[client hold・向き先の復旧]

なぜ防げなかったか・構造的要因の考察

考察

• 「コードは監査済み」でも、入口のドメインは監査の外。 DeFi のプロジェクトはコントラクトの監査に力を入れるが、利用者が触れるのは Web サイトで、その住所はレジストラのアカウント1つで決まる。今回、コントラクトは無傷でも利用者は資金を失った。
• 再販の連鎖でレジストラが見えにくい。 Vercel でドメインを取った運営者は、実際の登録先が Name.com だと意識していない場合がある。上流の1社の問題が、使っているホスティングの違いを越えて広がった。
• DNS のキャッシュで復旧後も被害が続く。 Kintsu は向き先を戻した後も、キャッシュが消えるまで最大1時間ほど古い向き先が表示されうるとして、サイトに近づかないよう求めていた（code404zero）。復旧の作業と、利用者への「もう安全」という告知は分けて考える必要がある。
• 暗号資産の被害は、コードより運用面に偏っている。 TRM Labs は10月30日の集計で、2017年以降に北朝鮮によるとした100件のうち、スマートコントラクトの欠陥を突いたのは13件で、残りは鍵・サーバー・署名の仕組みを狙ったものだったとしている（infosecpwn のまとめによる）。今回は北朝鮮との関係は示されていないが、狙われたのがコードの外側だった点は同じ。

運用者向けの具体的な対策と検知ポイント

事実（Name.com、各プロジェクト、報道）

• Name.com は顧客に、DNS の設定の確認と二要素認証の有効化を求めている（Crypto Briefing）。
• 一部のプロジェクトは、ネームサーバーを Vercel や Cloudflare に移すことで被害を抑えた（Crypto Briefing）。
• 利用者向けには、対象期間に接続・署名したウォレットの承認の取り消しと資金の移動が呼びかけられている（The Crypto Times）。

考察（運用上の工夫）

• ドメインを鍵と同じ重さで守る。 レジストラのアカウントにはハードウェアキーなどフィッシングに強い多要素認証をかけ、使える人を絞る。レジストリロック（レジストリ側で変更を止める有料サービス）が使える TLD なら有効にする。
• ネームサーバーと主要レコードを外から監視する。 自分の権威 DNS ではなく、公開の DNS リゾルバや RDAP で定期的にネームサーバー・A レコードを確かめ、変わったらすぐ通知する。証明書の透明性ログ（Certificate Transparency）で、自分のドメインに知らない証明書が発行されていないかも見る。
• フロントエンドの「緊急停止」の手順を用意する。 コントラクトの一時停止だけでなく、ドメインが奪われたときの連絡先（レジストラ、再販事業者、ウォレット警告の事業者）と、利用者への告知の文面を前もって決めておく。
• 利用者側は、署名の中身を読む。 正しいURLでも安全とは限らない。ウォレットの取引シミュレーションや警告を有効にし、無制限の承認や見覚えのない署名要求は断る。

参考リンク

• Name.com domain takeover notice（Vercel）
• Hackers hijack a dozen DeFi websites, all registered with Name.com, and steal about $138,000（The Block、2026年10月31日）
• Name.com restores hijacked domains after attack hit at least 12 DeFi front ends（Crypto Briefing、2026年10月31日）
• Flap, Kintsu Websites Hijacked as StepDrainer Wallet Drainer Hits 10 More DeFi Sites（The Crypto Times、2026年10月31日）
• DNS Hijacking: 12 DeFi Sites Served a Wallet Drainer（code404zero）
• Name.com Restores 15 Domains After DeFi Website Redirects（TokenPost）