< syuhei176

DEFI HACK LOG

2016年の The DAO から2026年まで、被害額が大きく、手口から学べることの多い39件を、攻撃の手口・根本原因・その後の経過で整理した。被害額の合計は約111億ドルになる。下のブロックは事件を古い順に並べたもので、面積が被害額、色が原因の大分類を表す。

最終更新:2026年10月

2016〜2023年

  1. ’16
  2. ’17
  3. ’20
  4. Poly Network’21
  5. ’22
  6. Ronin Bridge
  7. BNB Bridge
  8. ’23

2024〜2026年

  1. ’24
  2. Bybit’25
  3. ’26
  4. Binance

BLOCK #39 / 2026年10月29日 / 取引所・Ethereum

鍵・署名プロセスの侵害:ホットウォレットの Binance 14 が EIP-7702 で攻撃者のコントラクトに委任され、1回のトランザクションで約25億ドル分の資産が引き出された。

  • コードの欠陥
  • 人と運用の欠陥
  • ブロックの面積が被害額に比例。左から古い順。クリックで詳細へ。

根本原因を7つに分け、それを「コードの欠陥」と「人と運用の欠陥」の2つにまとめた。件数ではコードの欠陥が多いが、2024年以降の被害額は大半が人と運用の欠陥による。

このページに掲載した39件の被害額(合計 約111億ドル)を、原因の大分類ごとに集計した。

コントラクトやプロトコル設計そのものに穴がある。監査・テスト・形式検証で事前に見つけられる余地がある。

全体の被害額の22%・8件

必要な検証が抜けている、初期化やアクセス制御を誤っている、といった実装ミス。ブリッジの署名検証・メッセージ検証の欠陥はここに含まれる。

典型的な流れ:「誰が」「何を証明したか」の確認が一箇所だけ欠けていて、そこから任意の引き出しやミントが通る。

全体の被害額の2%・3件

外部呼び出しの最中に、状態を更新する前のコントラクトへもう一度入られる。The DAO 以来の古典だが、コンパイラのバグや読み取り専用の再入として形を変えて再発している。

典型的な流れ:送金・コールバックの後で残高を減らす実装で、同じ関数や同じ状態を参照する別の関数を再帰的に呼ばれる。

全体の被害額の4%・4件

丸め方向の誤り、精度の取りこぼし、オーバーフロー検査の誤りなど。集中流動性AMMやステーブルスワップのように固定小数点演算が多い設計で起きやすい。

典型的な流れ:1回あたりは微小な誤差を、境界値の状態をつくってから大量に繰り返し、価格や持分の計算を攻撃者に有利な方向へずらす。

全体の被害額の1%・2件

署名や鍵生成に使う乱数が弱い、署名の実装に偏りがある、といった暗号処理そのものの欠陥。鍵を盗まなくても、公開されている情報から鍵を割り出せてしまう。

典型的な流れ:予測できる乱数で作られた鍵や、偏りのある署名を、ブロックチェーン上の公開データから総当たりや統計分析で割り出す。

全体の被害額の5%・7件

コードは仕様どおりに動くが、価格オラクルや投票権といった経済的な前提が一時的に崩される。フラッシュローンによって、その資本コストはほぼゼロになった。

典型的な流れ:流動性の薄い市場で価格をつり上げ、その価格で評価された担保で借り入れる。あるいは借りた資金で議決権を得て、即座に提案を通す。

コードは仕様どおりに動いている。鍵を持つ人、署名に使う端末、配信されるUIが攻撃される。

全体の被害額の52%・11件

秘密鍵やマルチシグの署名者が、ソーシャルエンジニアリング・マルウェア・内部者によって奪われる、または騙されて悪意あるトランザクションに署名する。被害額ではここ数年の最大要因。

典型的な流れ:偽の採用面接や取引先を装って端末にマルウェアを入れ、署名画面に正常な取引を表示したまま、実際には権限移譲やコントラクトの差し替えに署名させる。

全体の被害額の15%・4件

コントラクトの外側、つまりWebフロントエンド、その配信基盤、DNS、依存ライブラリが改ざんされ、利用者に悪意ある承認や送金をさせる。

典型的な流れ:正規ドメインから配信されるJavaScriptに、特定のウォレットだけを狙って取引内容を書き換えるコードを差し込む。

各事件を開くと、手口の技術的な説明、根本原因、その後の経過、教訓、出典を確認できる。

39件中 39件を表示。被害額の合計は約111億ドル。

攻撃の流れを一歩ずつ追うと、どこで止められたかが見えてくる。手口の異なる4件を取り上げる。

2025年2月21日・Ethereum・約14.6億ドル・サプライチェーン・フロントエンド

2025年2月21日、Bybit の ETH コールドウォレットから約40万 ETH、約14.6億ドルが流出した。2026年10月の Binance の事件が起きるまで、単独の事件として暗号資産史上最大の被害だった。コントラクトにもハードウェアウォレットにもバグはなかった。攻撃者が侵入したのは Bybit ではなく、署名に使う Web アプリ Safe{Wallet} の配信基盤だった。

  1. 01

    2月4日、Safe{Wallet} の開発者の macOS 端末が、Docker のプロジェクトを実行させるソーシャルエンジニアリングで侵害された。攻撃者は盗んだ AWS のセッショントークンで多要素認証を迂回し、翌日から Safe の AWS 環境に入り込んだ。

  2. 02

    2月19日、S3 から配信される app.safe.global の JavaScript に、Bybit のウォレットからの取引のときだけ動き、署名の直前に取引の内容を差し替えるコードを注入した。他の利用者には何も起きないため、気づかれにくかった。

  3. 03

    2月21日、Bybit の署名者はコールドウォレットからウォームウォレットへの定例の送金として、正規の URL の画面から Ledger で署名した。実際に署名されたのは、operation=1(delegatecall)で攻撃者のコントラクトを呼ぶ execTransaction だった。ハードウェアウォレットには、中身が読める形では表示されなかった。

  4. 04

    delegatecall は、呼び出し先のコードを Safe 自身のストレージの上で実行する。攻撃者のコントラクトの transfer() は、ストレージのスロット0、つまりプロキシが参照する実装アドレス(masterCopy)を、攻撃者が用意したコントラクトに書き換えた。

  5. 05

    新しい実装には sweepETH() と sweepERC20() があり、攻撃者は追加の署名なしで ETH、stETH、mETH などを引き出した。

  6. 06

    実行の約2分後、S3 上の JavaScript は正規のものに戻された。

execTransaction(
  to        = 0x9622…7242,                // 攻撃者のコントラクト
  value     = 0,
  data      = transfer(0xbDd0…9516, 0),   // 新しい実装のアドレス
  operation = 1,                          // delegatecall
  ...
)

// 攻撃者のコントラクトの transfer() は Safe のストレージ上で実行され、
// slot 0(masterCopy)を 0xbDd0…9516 に書き換える。
// 以後、Safe のプロキシは攻撃者の実装を呼ぶ。
実際に署名された Safe のトランザクション。Sygnia と NCC Group の分析をもとに簡略化し、アドレスは一部を省略した。

閾値3のマルチシグでも、全員が同じ UI を信じて署名すれば、そのUIが単一障害点になる。署名者が to と operation を別の環境でデコードしていれば delegatecall に気づけたし、Safe の Guard で delegatecall を拒否していれば、署名が揃っても実行は止まった。攻撃されたのは、最も頻度が低く、最も慎重に扱われているはずのコールドウォレットの操作だった。

事件ファイルで出典を見る

対策を層ごとに整理し、どの攻撃手法に効くかを対応表にした。監査やファジングのようなコード側の対策は、人と運用の欠陥にはほとんど効かない。逆に、監視・出金制限・対応計画は原因を問わず被害を小さくする。どちらか片方では足りない。

対策と攻撃手法の対応表
対策ロジック再入数値精度暗号実装価格操作鍵・署名サプライチェーン
外部呼び出しの前に状態を確定させる主な予防策
状態を変える全経路の最後で健全性を検査する主な予防策部分的に効く・被害を抑える
丸め方向をプロトコル有利に統一する主な予防策
初期化・権限まわりを手順ごとテストする主な予防策
鍵生成と署名は検証済みの標準実装に任せる主な予防策
不変条件ファジングと形式検証主な予防策部分的に効く・被害を抑える主な予防策部分的に効く・被害を抑える部分的に効く・被害を抑える
監査とバグバウンティを継続する部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える
コンパイラと依存のバージョンを固定し、既知バグを追う部分的に効く・被害を抑える部分的に効く・被害を抑える
操作されにくい価格源を使う主な予防策
流動性の薄い資産に上限をかける主な予防策
ガバナンスに時間差を入れる主な予防策
署名者を組織・端末・場所で分散する主な予防策
署名する中身を独立に検証する主な予防策主な予防策
危険な操作をコントラクト側で拒否する主な予防策部分的に効く・被害を抑える
採用・取引先を装う接触を前提にする主な予防策
委託先と外部サービスを信頼の境界の外に置く主な予防策主な予防策
フロントエンドの配信経路を守る主な予防策
異常な資金移動を監視し、自動で止める部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える
出金にレート制限と遅延をかける部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える
インシデント対応を平時に決めておく部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える部分的に効く・被害を抑える

● 主な予防策 ○ 部分的に効く・被害を抑える

Checks-Effects-Interactions を徹底し、共有状態を持つ関数群はまとめて再入ガードで守る。transient storage(EIP-1153)を使えば安価にコントラクト全体のロックをかけられる。再入中の不整合な状態を view 関数が返してしまう read-only reentrancy にも注意する。

関連する事件:The DAO、Curve(Vyper)、GMX V1

借入・寄付・清算・移転など、ポジションを動かす関数すべての終わりで担保比率などの不変条件を確認する。後から関数を足したときに検査が抜けるのが典型的な失敗。

関連する事件:Euler Finance

受け取る側の計算は切り上げ、渡す側の計算は切り捨てに揃える。外部の数値演算ライブラリも信用せず、オーバーフロー検査やビットシフトの境界値を自分でテストする。

関連する事件:KyberSwap Elastic、Cetus、Balancer V2

デプロイとアップグレードをスクリプト化してフォーク環境で再現し、0x00 や address(0) が「有効な値」として通らないか確かめる。任意の calldata を転送する関数や、検証者セットを書き換えられる関数は呼び出し元を限定する。

関連する事件:Nomad Bridge、Parity マルチシグ(盗難)、Parity マルチシグ(凍結)、Poly Network

署名のナンスは RFC 6979 などの決定論的な方式や標準ライブラリに任せ、独自に改変しない。鍵生成の乱数源はビルド設定まで含めて第三者に監査させ、出荷前に生成した鍵のエントロピーを統計的に検査する。

関連する事件:Upbit、Coldcard

Foundry の invariant test や Echidna・Medusa で、「総負債は総担保を超えない」といった性質をランダムな操作列に対して検査する。数値演算ライブラリや署名・証明の検証ロジックは Certora や Halmos で形式検証する。

関連する事件:Euler Finance、KyberSwap Elastic、Cetus、Balancer V2、Wormhole、Liquid Network

監査はある時点のスナップショットでしかない。コードを変えるたびの再監査、競争型監査、被害想定額に見合った報奨金のバグバウンティを組み合わせる。Euler も Nomad も監査済みだった。GMX と Liquid Network では、以前の不具合を直す修正そのものが新しい脆弱性を持ち込んだ。資産が残る古いコントラクトも対象から外さない。

関連する事件:Euler Finance、Nomad Bridge、GMX V1、Liquid Network、Truebit

コンパイラとライブラリのバージョンを固定し、既知バグの告知が出たら自分のデプロイ済みコントラクトと突き合わせる。Curve の事件では、ソースコードは正しくてもコンパイラが再入ロックを壊していた。

関連する事件:Curve(Vyper)

単一プールのスポット価格を担保評価に使わない。TWAP や外部オラクルなど複数の価格源を組み合わせ、ソース間の乖離が大きいときは処理を止める。

関連する事件:bZx、Harvest Finance、Cream Finance、Mango Markets

担保として受け入れる資産ごとに、市場の厚みに応じた担保掛け目・供給上限・借入上限を設定する。価格を動かせても、その価格で借りられる額が小さければ攻撃は割に合わない。

関連する事件:Mango Markets、Cream Finance、Tectonic

投票権は提案前のスナップショットで数え、可決から実行までタイムロックを置く。即時実行の緊急手続きは、同じブロック内で借りたトークンで発動できないようにする。定足数は実際の投票率に合わせ、提案に含まれる命令はデコードして投票者に見せる。

関連する事件:Beanstalk、BonkDAO

マルチシグの閾値は、単一の組織や個人が過半を握らない構成にする。一時的に委任した署名権限やAPIキーは期限を決めて回収する。MPC や HSM も、運用が一人や一社に集中すれば同じ弱点を持つ。ブリッジの検証者も同じで、KelpDAO は単一の検証者とそのノードに依存していた。

関連する事件:Ronin Bridge、Harmony Horizon Bridge、Multichain、Orbit Bridge、KelpDAO

署名前に、ウォレットUIとは別の環境でトランザクションをデコード・シミュレーションし、Safe の tx hash をハードウェアウォレットの表示と照合する。operation が delegatecall になっていないか、宛先が想定どおりかを確認する。

関連する事件:Bybit、Radiant Capital、WazirX、Drift

Safe の Guard やポリシーエンジンで、delegatecall、owner や実装アドレスの変更、許可リスト外への送金を拒否する。権限の変更と高額の移動にはタイムロックをかける。人が騙されても、コントラクトが止める。

関連する事件:Bybit、WazirX、Radiant Capital、Drift

北朝鮮系のグループは、偽の求人、採用試験のコード課題、取引先を装ったファイル共有でエンジニアの端末に入り込む。署名権限や本番環境の権限を持つ人ほど、外部のファイルを開く端末と業務端末を分ける。

関連する事件:Ronin Bridge、DMM Bitcoin、Radiant Capital、Bybit、Drift

ウォレット事業者、カストディ、ステーキングAPI、署名UIなど、外部から受け取ったトランザクションや出金指示をそのまま署名・実行しない。宛先・金額・命令の種類を自社の側で独立に検証し、許可リストと上限を適用する。DMM Bitcoin、WazirX、Bybit、SwissBorg、Bitget は、いずれも委託先や外部製品が入口だった。

関連する事件:DMM Bitcoin、WazirX、Bybit、SwissBorg、Bitget

デプロイ権限を多要素認証と最小権限で絞り、配信中のJavaScriptが署名済みのビルド成果物と一致するかを監視する。SRI、CSP、DNS・レジストラのロックも入れる。資産を動かせるページには、計測や解析の外部スクリプトを読み込まない。Polymarket では、改ざんされたパフォーマンス計測のスクリプトが、ログイン中の利用者のセッションで取引を実行した。

関連する事件:BadgerDAO、Bybit、Polymarket

大口出金、権限変更、価格の急変を常時監視し、検知したら pause guardian が即座に停止できるようにする。自社の EOA に EIP-7702 の委任が設定されることも、権限変更として扱う。Ronin は流出に6日間気づかなかった。

関連する事件:Ronin Bridge、Nomad Bridge、KelpDAO、Cetus、Binance

一定時間あたりの流出量に上限を設け、大口の引き出しは遅延させる。原因の種類を問わず、被害の上限を前もって決められる数少ない手段。Liquid Network では、約4,000 BTC の払い出しが人の確認なしに通った。EOA のホットウォレットには上限をかけられないので、置いておく残高そのものが被害の上限になる。Binance 14 からは、1回のトランザクションで約25億ドル分が移された。

関連する事件:Nomad Bridge、Ronin Bridge、Wormhole、BNB Bridge、Liquid Network、Binance

停止権限を持つ人、連絡先(SEAL 911、取引所、ステーブルコイン発行体、チェーンのバリデータ)、ホワイトハットとの交渉方針(Safe Harbor 協定、報奨金の上限)を事前に決めておく。資金の凍結や返還交渉は最初の数時間で決まる。

関連する事件:Euler Finance、Cetus、KelpDAO、Bybit、Binance

被害額は事件発生時点の米ドル換算で、出典によって差があるものは代表的な値を採り、各事件の注記に幅を記した。攻撃者が後に返還した額や、凍結された額も被害額に含めている。日付は UTC。

掲載した事件は網羅的なリストではなく、被害額と手口から学べることの大きさで選んだ。個人が被害者の事件と、原因が公表されていない事件は除いている。ただし2026年10月の Binance の事件は、手口の大部分をオンチェーンで確認できるため、Binance の調査結果が公表される前だが暫定的に掲載した。攻撃者の特定は、捜査機関やセキュリティ企業の発表にもとづく。

年次の統計は以下の資料による。Chainalysis は過去の年の値を後の報告で修正することがあり、グラフには各年の報告の初出値を使った。各事件の出典は事件ファイルに記した。

< syuhei176 のトップへ戻る