DeFiの頻繁な盗難、AI時代においてどのようにハッカー攻撃を防ぐべきか?

撰文:systs

OpenBuild 導読:

2026 年 4 月、DeFi は最暗の時代を迎え、月間盗難額が6.25億ドルを突破し、史上最高を記録した。Drift と KelpDAO の2件の攻撃だけで約5.8億ドルを飲み込んだ。AI の爆発により攻防の構図は根本的に逆転し、従来は数週間かかっていたプロトコルの脆弱性調査が、大規模モデルでは数時間で完了できるようになり、攻撃コストは暴落し、攻撃面は急増している。ますます多くのプロトコルが標的となっている。

資源豊富で長期戦略に長けた専門的な攻撃者は、あらゆるプロトコルの隙間を狙っている。一方、普通のチームは分散したリソースで防御が受動的かつ脆弱であり、極端な偏執と全工程の防御構築、損失の厳格な管理と事前計画だけが、このAI主導の攻防戦を生き延びる道だ。以下は原文内容をOpenBuildが翻訳・整理したもの。

開発 @openforage プロジェクトや、多数のDeFiプロトコルの歴史的攻撃事例を研究した結果、国家レベルの勢力による攻撃者に対して警戒心を抱くようになった。こうした相手は熟練し、資源も豊富で、超長期的な戦略に長けている。まるでトップクラスの悪役のように、あなたのプロトコルやインフラの隅々まで徹底的に調査し、利用可能な脆弱性を探し出す。一方、普通のプロトコルチームは、事業運営と安全確保を両立させるためにリソースを分散させており、全身全霊の防御は不可能だ。私は自らをセキュリティの専門家と自負していないが、高リスク環境でチームを率いた経験(軍事や大手金融機関での大規模資金管理を含む)から、リスク対応と緊急計画の実戦経験を持つ。私は常に信じている:偏執的な者だけが生き残れる。どんなチームも最初から「安全はおざなりにして良い」とは考えないが、ハッカーの攻撃は絶えない。私たちはより良くなければならない。

/ 01 AI 時代:すでにすべてが変わった

ハッカー攻撃は以前から頻繁だったが、最近の頻度は明らかに増加している。2026年第1四半期はDeFi史上最高のハッカー攻撃件数を記録し、第2四半期に入ったばかりで、前四半期の記録を破る見込みだ。

私の核心的な見解は:AIは脆弱性スキャンと発掘のコストを大幅に引き下げ、攻撃面を飛躍的に拡大していることだ。数百のプロトコルの設定ミスを人力で調査するには数週間かかるが、最新の大規模モデルなら数時間で完了できる。これにより、プロトコルの安全防御と緊急対応の根底の論理が根本的に書き換えられた。AI登場以前に生まれ、従来の安全手法を踏襲してきた古参のプロトコルは、正確に攻撃されるリスクに直面している。

/ 02 攻撃面と層別防御の観点から

実践的には、DeFiハッカーの核心的突破口は三つだけだ:

  • プロトコル運営チーム
  • スマートコントラクトと基盤インフラ
  • ユーザーの信頼境界(ドメイン名、SNS等)

攻撃面を明確にした後、五層の層別防御体系を構築する:

  • 事前予防:標準化されたプロセスを導入し、厳格に実行して破られる確率を最大限低減。
  • 損失緩和:予防失敗時に即座に損失規模をコントロール。
  • 緊急停止:高圧下では最適な判断は難しい。攻撃を確認したら即座に緊急停止スイッチを作動させ、資産を凍結して損失拡大を防ぎ、冷静な判断の時間を確保。
  • 管理権の回復:悪意あるモジュールや侵入したコンポーネントが制御不能になった場合は、直接切り離し・置換。
  • 事後復旧:盗まれた資産を取り戻す。事前に機関やパートナーと連携し、資金凍結や取引の巻き戻し、追跡調査を支援。

/ 03 核心原則

以下の原則は、層別防御体系の実現を指針とする。

大胆な最先端AIによる防御

最先端の大規模モデルを活用し、コードベースや設定ファイルの脆弱性をスキャンし、広範な攻撃面でのレッドチーム・ブルーチームの侵入テストを展開:フロントエンドの脆弱性を積極的に発掘し、バックエンドへの侵入可能性を検証。攻撃者は必ずこうするため、防御側もスキャン可能な脆弱性を見つけ出す。pashov、nemesisなどのツールや、Cantina(Apex)、Zellic(V12)などのAI安全プラットフォームを活用し、正式監査前にコードの初期スクリーニングを迅速に行う。

時間とプロセスの摩擦は防御そのもの

潜在的リスクのある操作は、多段階のプロセスとタイムロック機構を設計すべき。一旦異常を察知したら、十分な人間介入と資産凍結の時間を確保。過去はタイムロックや多段階権限の導入に抵抗感があったが、今や状況は変わった。AIはこれらの人為的な摩擦を自動的に回避し、プロトコルはシンプルな操作に固執しても意味がない。

不変条件の設計

スマートコントラクトは、破られ得ないコアの不変条件を定義し、それを実行時に検証することで防御。@openforage の不変条件は、支払い能力に関する設計:金庫資産+展開済み資産 ≥ 未払い債権。一般的なプロトコルは少数の重要な不変条件だけを設定すべきで、多数の関数に硬コードされた検証はコードの肥大化と保守性低下を招く。

権力のバランス

多くのハッカー攻撃は、ウォレットの秘密鍵漏洩やマルチシグの侵害に起因する。適切な権限設定は、たとえマルチシグが失守しても迅速に損失を止め、ガバナンスによる安定状態に切り替えられることだ。二つの制約を意識:

  • ガバナンス権限:プロトコルの核心決定を掌握
  • 緊急救援権限:安定秩序の回復を担うが、既存のガバナンスを凌駕しない

必然的に起こる事態を想定

どんなに専門的なチームでも、攻撃は避けられないという前提を持つ。スマートコントラクトや依存コンポーネントの故障、ソーシャルエンジニアリング攻撃、バージョンアップによる未知の脆弱性もあり得る。この心構えのもと、レートリミットやリスクコントロール、熔断停止は必須手段だ。損失を5~10%以内に抑え、資産凍結後に冷静に対応策を立てる。危機時には焦らず冷静に。

事前の計画と準備

攻撃に対する最良の対応は、事前に準備しておくこと。緊急対応の手順や制度を文書化し、チームで繰り返し訓練しておく。AI時代は、ツールとアルゴリズムを駆使し、全情報を瞬時に収集・要約し、意思決定の核に伝えることが求められる。

生存こそ最終目標

絶対的な完璧さを追求する必要はないが、生き残ることは絶対だ。システムは稼働開始時から完璧ではなく、継続的な振り返りと改善を通じて、脆弱性に耐える構造へと進化させる必要がある。攻撃を受けていないからといって安全ではない。最も油断しやすいときこそ、最大のリスクが潜む。

/ 04 事前予防体系

スマートコントラクト設計

コアの不変条件を明確にし、それを実行時に検証するロジックに組み込む。必要なルールだけを厳選し、FREI-PI(関数要件 - 実行影響 - 外部交渉 - プロトコル不変条件)設計パターンに従う。資産変動に関わる関数は、実行後にコアの不変条件を再検証。CEI(検査 - 実行 - 交渉)規範に従った攻撃(例:フラッシュローンアービトラージ、オラクルの悪意的清算、関数間の支払い能力喪失)も、不変条件の検証で防げる。

テスト体系の充実

状態模糊テスト:プロトコルの公開インターフェースに対し、ランダムな呼び出しシーケンスを生成し、不変条件を検証。多くのオンチェーン攻撃は複数取引の組み合わせによるため、状態模糊テストはこれらの脆弱性を事前に発見できる唯一の信頼できる手段。ルールの不変性を担保するテストと、すべての到達可能状態での形式検証を併用すべき。

オラクルと外部依存

複雑さは安全性の最大の敵。外部依存層が増えるほど攻撃面は拡大。基盤コンポーネントを開発する場合は、信頼の選択権をユーザに委ねるべき。依存を排除できない場合は、多源冗長化と分散化を徹底し、シングルポイント故障を避ける。監査範囲にはオラクルや外部依存の故障シナリオも含め、リミットとレートリミットを設定し、異常時も被害を最小化できる仕組みを整える。最近のKelpDAO攻撃は典型例:LayerZeroのデフォルト設定 requiredDVNCount=1は監査範囲外であり、最終的に攻撃されたのは監査外のオフチェーンインフラだった。

攻撃面の全面洗い出し

DeFiの既知の攻撃ベクトルはすでに完全なリスト化済み。各項目を照合し、自身のプロトコルに適合するか判断し、対応策を実施。内部のレッドチーム・ブルーチームによる攻撃探索能力を強化し、AIエージェントに積極的に脆弱性を発掘させることは、現行の業界標準の最低ラインだ。

ネイティブの緊急救援権限

投票制ガバナンスでは、初期段階で権限は多署名に集中し、その後徐々に分散。トークン配布が広くても、委任権は少数のウォレットに集中し、最悪の場合は一つの重要アドレスだけになることも。こうしたウォレットが攻撃されると、プロトコルは崩壊する。守護者ウォレットを導入し、権限を厳格に制限:プロトコルの一時停止のみ可能にし、最悪の場合は4/7以上の守護者が侵害された場合に、事前設定の予備ウォレットに委任権を移行できる。守護者はガバナンス提案や操作を起動できない。

こうして、プロトコルには独立した緊急救援層が生まれる。これにより、ガバナンスの安定性を回復できる一方、原生のガバナンスを凌駕しない。4/7以上の守護者が同時に侵害される確率は、持ち分の分散性が低いため非常に低い。ガバナンス体制が成熟し、権限の分散が進めば、この緊急層は段階的に廃止できる。

ウォレットと鍵の構造

マルチシグウォレットは標準装備で、最低4/7の構成とし、誰も全7鍵を単独で掌握しない。定期的に署名者のアドレスを静かに入れ替える。署名用デバイスは日常的にウェブ閲覧やメール、オフィスソフトに使うべきではない。侵害リスクを考慮し、多重のマルチシグウォレットを運用し、役割を分担。少なくとも一つのマルチシグは完全に攻撃可能な前提で設計し、緊急時の対応策を準備。個人は脅迫や人身威嚇などの極端な状況でも、単独でプロトコルを侵害する権限を持たない。

脆弱性報奨金の計画

Nascentの脆弱性報奨金に関する見解に賛同する。資金力のあるプロトコルは、TVLに対して高い比率の報奨金を設定すべき。規模が小さくても、報奨金はできるだけ高額に(少なくとも7桁から)。国家レベルの高度な攻撃者には、報奨金交渉はほぼ無効だが、ホワイトハットの安全な避難所計画を導入し、盗難資金の保全を委任し、一定割合を報酬として抽出する仕組みも有効。これは基本的に預金者負担のコストとなる。

優良な監査機関の選定

以前は、大規模モデルの能力向上により、従来の監査の付加価値は低下すると考えていたが、見解を改める。

トップクラスの監査機関は常に最先端を走る。革新的な設計を採用した場合、コードや潜在的な脆弱性はモデルの訓練データに含まれないため、計算能力だけでは新たなロジックの脆弱性を発掘できない。新手法の攻撃に最初に遭遇するのは誰も望まない。

見落としがちな点は、監査機関は自らの業界での評判を背負っていることだ。監査報告後に盗難が発覚した場合、機関は損失の振り返りに協力する動機が強い。専門のセキュリティチームと長期的に連携することは、貴重な資産となる。

運用とセキュリティの実装

運用の安全性も重要な評価項目に含める。定期的なフィッシング演習や、信頼できる外部レッドチームによるソーシャルエンジニアリング攻撃のテストを実施。予備のハードウェアウォレットや代替デバイスを常備し、緊急時に備える。

/ 05 損失緩和

資金の出入口は損失の上限

すべての資産流出チャネルには上限を設定すべき。脆弱性を悪用した場合の理論上の最大損失を見積もり、それを超えない範囲に制限。例えば、無制限の発行関数は無限の発行リスクを意味し、無制限の引き出しは資産残高の改ざんリスクとなる。各資金流出チャネルに硬い上限を慎重に設定し、最大許容損失とユーザ体験のバランスを取る。防御ラインが破られた場合でも、この制限があればプロトコルの完全崩壊を防げる。

ホワイトリストとブラックリスト

多くのプロトコルには、呼び出しインターフェースや取引資産、許可されたアドレスの非公開リストが存在し、禁止行為の境界も明示されている。規則が非公開でも、制度化すべきだ。ホワイトリストとブラックリストを明確にした上で、二段階の権限変更を設定し、攻撃の摩擦を増やす。攻撃者はまずホワイトリストの改ざんやブラックリストの解除を行い、その後悪意の操作を仕掛ける。二重の仕組みで、攻撃者は二つのハードルを突破しなければならない:事前の承認(インテグレーション/ローンチ)と、安全規制の回避(リスク管理の再検証)。

/ 06 管理権の回収

アルゴリズムによる自動監視

緊急停止スイッチがあっても、誰も監視していなければ意味がない。オフチェーンの監視システムを構築し、24時間体制でコアの不変条件を巡回し、異常を検知したら自動的にアラートを上げる。アラートは守護者の多署名の担当者に直ちに通知され、詳細なコンテキストも提供され、数分単位の意思決定を支援。

停止後の判断と対応

攻撃を受けたら、まず止血を優先。危機のカウントダウン中に慌てて決定しないこと。プロトコルでは、緊急停止スイッチ(フロントエンドに表示)を用意し、一つの取引で全資産の流れを停止できるようにする。事前に「一括停止」スクリプトを作成し、すべての停止可能なモジュールを自動的に停止させる。ガバナンス権限は停止できないが、守護者層がガバナンスコントラクトを停止できる場合、侵害された守護者は永久に復旧手順をロックされる。

緊急作戦室の立ち上げ

資産凍結と損失抑止後、あらかじめ合意したコア信頼者を招集し、専用のコミュニケーションチャネルを設置。情報の範囲を厳格に管理し、攻撃者や公衆、利益追求者への情報漏洩を防ぐ。役割を固定し、訓練を行う:

  • 決定責任者:全体の指揮
  • 運用実行者:防御スクリプトや停止操作の実行
  • 脆弱性復旧担当:攻撃の追跡と根因特定
  • 対外連絡員:関係者との連携
  • 事態記録員:進展や決定、時間軸を記録

全員の責任と役割を明確にし、事前に訓練を重ね、事態発生時は計画通りに行動。

連鎖的二次リスクの予測

攻撃者は最先端の技術を持つと仮定すべき:最初の脆弱性は単なる奇襲や前哨戦の可能性もある。今回の侵入は罠であり、我々の誤操作を誘導し、深層の脆弱性を引き出すためのものかもしれない。停止操作は厳密に評価し、完全なクローズドループにすべき。全体を凍結し、部分的な停止では他の脆弱性を露呈させる恐れがある。根因と攻撃面を特定したら、周辺の攻撃面や連鎖リスクも同時に調査し、すべて修復。

事前に設定した後継者交代メカニズムの有効化

権限のローテーションは、あらかじめ後継者アドレスを登録しておくことが安全だ。推奨するのは、事前登録された後継者リストの仕組み:攻撃者が悪意のあるウォレットで守護者やガバナンスウォレットを密かに置き換えるのは困難になる。ブラックリスト・ホワイトリストのリスク管理と同じ論理だ。すべての重要役割には、事前に後継者アドレスを登録。緊急時には、役割Xを登録済みの後継者に置き換えるだけ。平時は慎重に候補者を選び、事前に調査しておく。

バージョンアップ前の慎重なテスト

根因と影響範囲を特定したら、必ずアップグレードパッチをリリース。これは最もリスクの高いコード展開となる。焦って作成し、攻撃者は既にプロトコルのロジックと脆弱性の発掘手法を熟知している。テストを省略して公開すべきではない。正式監査の時間がない場合は、ホワイトハットのネットワークや、48時間の脆弱性悬賞コンテストを活用し、外部の攻防視点を取り入れてから正式に展開。

/ 07 事後復旧

迅速な行動

盗難資金はマネーロンダリングの半減期を持つ。攻撃成功後は素早く分散・クロスチェーン移動し、洗浄を行う。Chainalysisなどのオンチェーン分析サービスと連携し、多チェーンの攻撃者アドレス群をリアルタイムでマークし、取引所のリスク管理に通知。資金のクロスチェーン追跡も行う。事前にリストを整理:中央取引所のコンプライアンス部門、クロスチェーンブリッジ運営者、ホスティング機関の管理者、資金凍結や追跡を行える第三者パートナー。

交渉と調整

心情は複雑でも、攻撃者と積極的に交渉すべきだ。すべては交渉の余地がある。ホワイトハット賞金の公告を期限付きで出し、資金を全額返還すれば法的追及を放棄することを公約。国家レベルの勢力の場合は、交渉はほぼ無意味だが、多くの攻撃者は偶然脆弱性を発見し、低リスクで利益を得たいだけのケースもある。交渉には必ず法務担当者を同席させる。

/ 08 ハッカー攻撃は消えず、AIの進化とともに頻度は増す

防御側は、自力の向上だけでは不十分だ。攻撃者と同じAIツールを使い、常時レッドチーム・ブルーチームの対抗戦を行い、リアルタイム監視と損失上限の設定を徹底しなければ、極端なリスクに耐えられず、業界のサイクルを生き抜くことはできない。

DRIFT-0.24%
ZRO-4%
原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
コメントを追加
コメントを追加
コメントなし
  • ピン