原文タイトル:DeFi ハックでの資産流出を止める方法
原著者:sysls、openforage
原翻訳者:AididiaoJP、Foresight News
数々の DeFi プロトコルのハッキング事件を理解すると、「国家行為体」に恐怖を覚えます。彼らは高度な技術力と豊富なリソースを持ち、非常に長期的なゲームをプレイしています。これらのスーパーヴィランは、あなたのプロトコルやインフラストラクチャの隅々まで隙間を探り、一般的なプロトコルチームは注意を複数のビジネス方向に分散させています。
私はセキュリティ専門家ではありませんが、過去に高リスク環境でチームを率いた経験があります(軍隊や大口の金融分野を含む)。緊急対応計画の策定や検討において豊富な経験があります。
私は真剣に信じています。生存するには偏執者にならなければなりません。どのチームも最初から「セキュリティにはルーズで手抜かりな態度を取るべきだ」と考えたりはしませんが、それにもかかわらずハッキングは発生しています。私たちはより良くする必要があります。

(データソース:https://defillama.com/hacks)
ハッキングは珍しいことではありませんが、その頻度は明らかに増加しています。2026年第1四半期は、DeFi ハックの数量が過去最多となった四半期であり、第2四半期が始まったばかりですが、前四半期の記録を塗り替える可能性があります。
私の基本的な仮説は、AI が隙間を見つけるコストを大幅に削減し、攻撃面を大幅に拡大しているということです。人間は、100個のプロトコルの設定を調べるのに数週間かかるかもしれませんが、最新のベースモデルはわずか数時間で完了できます。
これは、私たちがハッキングに対処する方法を根本的に変えるはずです。AI が強力になる前のセキュリティ対策に慣れている古いプロトコルは、「秒殺」のリスクに直面する可能性がますます高まっています。

(データソース:https://defillama.com/hacks)

ハッカー攻撃のサーフェスエリアは実際には次の3つにまとめることができます:プロトコルチーム、スマートコントラクトとインフラ、ユーザー信頼境界(DSN、ソーシャルメディアなど)。
これらのサーフェスを特定したら、防御レイヤーを重畳します:
· 予防:厳格に実行されれば、悪用の可能性を最大限に抑えることができます。
· 緩和:予防策が失敗した場合、被害の程度を制限します。
· 一時停止:誰もが大きなプレッシャーの下で最善の判断を下すことはできません。攻撃を確認したら、直ちに総合スイッチをアクティブにしてください。フリーズにより追加の損失を防ぎ、考えるスペースを確保します…
· 再獲得:有毒なまたは侵害されたコンポーネントのコントロールを失った場合は、それらを捨てて置き換えます。
· 回復:失ったものを取り戻します。資金を凍結し、取引を取り消し、調査を支援する機関の協力パートナーとの連絡を事前に計画してください。
これらの原則は、各ディフェンスレイヤーの具体的な行動を指針としています。
コードベースと構成をスキャンし、脆弱性を見つけ、広範囲なサーフェス上でレッドチームテストを実施するために、先進的な AI モデルを大規模に利用してください:フロントエンドでの脆弱性を発見し、それがバックエンドに到達できるかどうかを確認します。攻撃者はそうします。あなたが防御スキャンで発見できるものは、彼らの攻撃的スキャンはもっと前に発見しています。
pashov、nemesis などのスキル、および Cantina(Apex)や Zellic(V12)などの AI プラットフォームを使用して、完全な監査を提出する前にコードベースを迅速にスキャンします。
損害を引き起こす可能性のある操作に対して、複数段階のプロセスとタイムロックを追加してください。異常を検知した場合に介入し、凍結するための十分な時間が必要です。
過去には、時間ロックやマルチステップの設定に反対する理由は、プロトコルチームに摩擦を引き起こすというものでした。しかし、今ではそれほど心配する必要はありません:AI はこれらの摩擦を簡単にバックグラウンドで処理できます。
スマートコントラクトは、防御的に構築するために不変の「事実」を書き留めることができます:これらの事実が壊れると、プロトコル全体の論理が崩壊します。
通常、不変性はわずか数個しかありません。それらをコードレベルに上乗せさせる際は慎重に行い、各関数で複数の不変性を強制すると、管理が困難になります。
多くのハッカー攻撃は侵害されたウォレットから発生しています。あなたは次のような設定が必要です:マルチシグが侵害された場合でも、迅速に被害を抑制し、プロトコルを治理可能な状態に戻すことができます。
これには、ガバナンス(すべてを決定する)とレスキュー(ガバナンスの安定性を回復する能力、ただし、ガバナンス自体を置き換えたり覆したりすることはできない)の間でバランスを取る必要があります。
最初から次のような仮定をする:どれだけ賢いかに関わらず、ハッキングされる可能性があります。スマートコントラクトや依存関係が失敗する可能性があります。ソーシャルエンジニアリング攻撃を受けるかもしれませんし、新しいアップデートによって予期していなかった脆弱性が導入される可能性があります。
こう考えると、被害の拡大を制限する速度制限とプロトコルのサーキットブレーカーはあなたの最良の友達になります。被害を5-10%に制限し、次に処理計画を立てます。誰もが最良の判断を下すことができるわけではありません。
ハッキングされる前に、対処計画を考えてください。プロセスをできるだけコーディング化し、チームと一緒に練習を重ねることで、ショック時に混乱することがありません。AI時代には、できるだけ迅速に大量の情報を提示し、要約および長文を核となるチームと共有するスキルやアルゴリズムを持っていることが重要です。
完璧である必要はありませんが、生き残る必要があります。システムは最初から壊れないものではありません。多くの反復により、学んだ教訓を取り入れて、あなたは反脆弱性になります。
ハッキングの証拠がないことは、ハッキングされないことを意味しません。最大限の快適さが最大の危険地点であることがよくあります。
イミュータブルなものが確立されると、それらをランタイムチェックに昇格させます。強制的に実施すべき不変量はどれかを慎重に考えます。
これが FREI-PI(Function Requirements, Effects, Interactions, Protocol Invariants)パターンです:価値のある関数の終了時に、その関数が維持することを約束したプロトコル不変量を再度確認します。CEI(Checks-Effects-Interactions)による多くの攻撃(Flash Loan Sandwich、Oracle-assisted griefing、cross-function paymaster drain)は、関数の終了時の不変量チェックで捕捉できます。
ステートフルファジングは、プロトコルの完全なパブリックサーフェスにランダムな呼び出しシーケンスを生成し、各ステップで不変条件をアサートします。ほとんどのプロダクション環境の脆弱性は、複数のトランザクションにわたるものであり、ステートフルファジングはこれらのパスを攻撃者より前に発見するほぼ唯一の信頼できる方法です。
不変条件のテストを使用して、ファジャーが生成できるすべての呼び出しシーケンスで属性が成立していることをアサートします。形式検証と組み合わせることで、属性が到達可能なすべての状態で成立していることを証明できます。あなたの冠不変条件は、このような取り扱いを絶対に受け入れるべきです。
複雑さはセキュリティの敵です。すべての外部依存関係は攻撃面を拡大させます。原語を設計する際には、信頼する対象と信頼する内容の選択権をユーザーに委ねてください。依存関係を取り除けない場合は、それらを多様化し、単一障害点が存在しないようにしてください。
監査範囲を拡大して、オラクルや依存関係の模倣が失敗する可能性のある方法を検証し、その失敗がもたらす悲劇の程度に対してレート制限を課します。
最近のKelpDAOの脆弱性はその一例です:彼らはLayerZeroのデフォルトのrequiredDVNCount=1構成を継承しましたが、この構成は彼らの監査範囲外でした。最終的に攻撃を受けたのは監査範囲外のオフチェーンインフラストラクチャでした。
DeFiにおける多くのサーフェス攻撃がすでにリストアップされています。各カテゴリを1つずつチェックし、それがあなたのプロトコルに当てはまるかどうかを尋ね、その攻撃ベクトルに対するコントロールを実装してください。Red Teamスキルを磨き、あなたのAIエージェントが積極的にプロトコル内で脆弱性を見つけるようにします。これは現在では基本的な要件です。
投票ベースのガバナンスでは、権力は最初にチームのマルチシグに集中し、時間がかかって拡散します。たとえトークンが広く分散していても、デレゲーションはしばしば権限を少数のウォレットに集中させます(時にはn=1ですらあります)。これらのウォレットがハッキングされると、ゲームオーバーです。
「ガーディアンウォレット」を展開し、厳密で狭い権限を付与します:それらはプロトコルを一時停止するだけであり、>=4/7のしきい値で、危機的状況で損傷したデレゲーションを事前に定義された代替ウォレットに切り替えることができます。ガーディアンは治理提案を決して実行できません。
これにより、常にガバナンスの安定性を回復できる救済層を持ち、ガバナンスを転覆する権限を持ちません。>=4/7のガーディアンを失う最悪の場合の確率は非常に低く(所有者の多様性を考慮すると)、一度ガバナンスが成熟し分散化されると、この層は段階的に廃止することができます。
マルチシグウォレットは基本要件であり、最低限 4/7 です。1 人がすべての 7 つのキーを制御していてはいけません。頻繁に署名者を交代し、かつ静かに行う必要があります。
キーは常に日常的に使用されるデバイスとはやり取りしてはいけません。サインインデバイスを使用してインターネットを閲覧したり、メールの送受信をしたり、Slack を開いたりすると、その署名者はすでに侵害されているものと見なすべきです。
複数のマルチシグを所有し、それぞれが異なる目的を持つようにします。少なくとも 1 つの完全なマルチシグが侵害されることを想定し、そこから計画を立てるようにします。どの個人も、極限の状況(誘拐、拷問など)でもプロトコルを侵害するための十分な制御権を持つべきではありません。
もし資源を持っている場合、プロトコルの TVL に対して高額のバグバウンティを設定することは非常に価値があります。プロトコルが比較的小規模であっても、バグバウンティはできるだけ寛大に設定すべきです(例:最低でも 7-8 桁)。
国家行為主体からの攻撃に直面している場合、彼らは交渉しない可能性がありますが、それでも「ホワイトハットセーフティハーバー」プランに参加し、ホワイトハットに行動を代行させ、資金を保護し、バグ報酬の一定割合を手数料として受け取ることができます(実際にはデポジット者が報酬を支払うことになります)。
以前に述べたように、大規模な言語モデルがより賢くなるにつれて、監査人を雇うことの増分価値が低下すると考えています。私はこの考え方を支持していますが、最近の見解は変わってきています。
まず第一に、優れた監査人は最先端を行きます。何か新しいことに取り組んでいる場合、コードとそのバグがトレーニングデータに含まれていない可能性があります。トークンの数量を単純に増やすだけでは、新しい種類のバグを見つけるのに効果的であることが未だ実証されていません。あなたは、独自のバグの最初のサンプル点になりたくはありません。
次に、過小評価されている利点は次のとおりです:監査人の雇用は彼らの評判を担保するために行われます。彼らが署名を承認し、あなたが攻撃された場合、彼らは助ける強い動機づけを受けます。セキュリティに関して専門的な人々との関係を築くことは非常に大きな利点です。
オペレーションセキュリティを成功の尺度と見なします。フィッシングの訓練を実施し、(信頼できる)レッドチームを雇い、チームに対してソーシャルエンジニアリング攻撃を実施してもらいます。必要に応じて、バックアップハードウェアウォレットやデバイスを準備しておき、全マルチシグを交換できるようにします。D-day に急いでこれらのアイテムを購入することがありません。
プロトコルから価値を移動する任意の経路の上限サイズは、その経路が脆弱性を悪用された場合の最大理論的損失です。簡単に言えば: ブロックごとの上限のない鋳造関数は、無制限の鋳造の脆弱性に空白の小切手を提供します。週ごとの上限のない償還関数は、資産残高の損失に空白の小切手を提供します。
退出経路の具体的な数値を慎重に考えてください。この数値は、耐えられる最大の損失とユーザーの最も極端なUXニーズとのバランスを取る必要があります。問題が発生した場合、これはあなたを完全な破壊から救うものです。
ほとんどのプロトコルには呼び出す、取引する、または受け取ることができるリストと絶対に行ってはならないリストがあります。これらは信頼の境界であり、形式化されるべきです。
これを形式化すると、2段階セッターを設定し、意味のある摩擦を生み出すことができます。攻撃者はまずホワイトリストに追加する(および/またはブラックリストから削除する)必要があり、その後できることが限られます。両方を持っていることは、攻撃者が新たなベクトルを静かに導入しようとする場合、両方のプロセスを同時に侵害する必要があることを意味します。市場にはアクセスできなければならず(統合/上場)、そのアクションは禁止されてはいけない(セキュリティレビュー)。
誰も監視していなければ、キルスイッチはまったく役立ちません。オフチェーンモニターは不変式を継続的に監視し、問題が発生すると自動的に警告をアップグレードする必要があります。最終的な経路は、護衛者のマルチサイン人間の手に到達し、数分以内に決定を下すための十分な文脈が提供されるべきです。
攻撃を受けた場合、判断を下す前に出血を止める必要があります。プロトコルにとっては、これはキルスイッチです(UIにも表示されている必要があります):1つのトランザクションですべての価値移動パスを一時停止できるボタンです。すべてを一時停止するための補助スクリプトを用意し、一時停止可能なすべてのコンポーネントを列挙し、それらを個別に一時停止します。
キルスイッチを解除できるのはガバナンスだけであり、キルスイッチはガバナンス契約自体を一時停止することはできません。護衛者レイヤーがガバナンス契約を一時停止できる場合、攻撃された護衛者レイヤーは恒久的に復旧処理がロックされます。
凍結し、出血を止め、信頼できる全員(小さなサークル、事前に合意)をコミュニケーションチャンネルに招待します。情報漏洩を防ぐために、できるだけ小さく見えるように努めることが重要です。攻撃者、一般大衆、または悪意のあるアービトラージャに情報を漏らさないようにします。
チームの必要な役割を演じるためのロールプレイを行います: 決定を下す人、防衛スクリプトを実行し操作を一時停止するスキルを持つオペレータ、脆弱性を再構成し原因を特定する人、主要関係者と連絡を取る人、観察、イベント、および意思決定のタイムラインを記録する人。
すべての人が自分の役割を理解し、訓練を受けているとき、あなたは手際よく対応し、最悪の瞬間に混乱することなく手順に従うことができます。
あなたの攻撃者が非常に巧妙であると仮定しましょう。最初の脆弱性はおとりか、あるいは後続の攻撃のために種を蒔くものかもしれません。攻撃はあなたが完全に間違ったことをさせることで、本当の脆弱性を引き起こす可能性があります。
ポーズは慎重に研究され、完全にコントロール可能であり、それ自体が悪用されない必要があります。ポーズはすべてのプロトコルを凍結するものでなければなりません:あるコンポーネントのポーズに誘導されて他のコンポーネントが開放されるのは避けたいです。一度にすべての影響範囲と攻撃ベクトルを特定したら、隣接する露出面と連鎖反応を探り、一度に修正してください。
後任者を事前に知っている場合のみ、交代は安全です。私は事前にコミットした後任者登録所という考えが好きです:これにより、攻撃者が正常なガーディアン/ガバナンスウォレットをハックされたものに置き換えることがより困難になります。これは「ホワイトリスト/ブラックリスト」の概念と整合しています。
重要な各役割について後任者アドレスを登録してください。緊急時の唯一の交代原理は、「役割 X をその後任者と置き換える」です。これにより、平和時に後任者を評価できるようになります:ゆっくりと、慎重に調査し、リクエストを提出する人と会ってください。
根本原因と影響範囲を特定したら、アップグレードをリリースする必要があります。これは、デプロイする可能性のある最も危険なコードかもしれません:プレッシャーの下で書かれ、プロトコルを十分に理解し、脆弱性を見つけた攻撃者を対象としています。
十分なテストが行われていない場合はリリースを遅らせてください。監査の時間がない場合は、ホワイトハットの関係に頼るか、デプロイメントの前に48時間の競争を設定して、新たな対抗的なレビューを受けることができます。
盗まれた資金は半減期を持っています。脆弱性が発生すると、それらは迅速に資金洗浄の流れに入ります。Chainalysisなどのブロックチェーン分析プロバイダーを即座に準備して、攻撃者のアドレスクラスターにリアルタイムでタグを付け、それらがクロスチェーンで移動するときに取引プラットフォームに通知して追跡できるようにします。
中央集権型取引所のコンプライアンス部門、クロスチェーンブリッジの管理者、カストディアンの管理者、および特定の進行中のデポジットを凍結できる管理権限を持つ他の第三者のリストを事前に準備してください。
はい、それは痛い出来事ですが、それでも攻撃者と話を試みるべきです。人生には交渉で解決できることがたくさんあります。期限付きのホワイトハットバウンティを提供し、全額の返金が期限までに行われれば法的手続きを取らないことを公に表明します。
もし国家主体に対処している場合、幸運がないかもしれませんが、あなたが直面しているのは経験の浅い攻撃者かもしれません。彼らは単にあなたを標的とした方法を見つけ、低コストで逃れようとしているかもしれません。
こうした場合には、必ず法務顧問を同席させてください。
ハッカー攻撃は止まりません。AIがより賢くなるにつれて、攻撃はますます増えるでしょう。防衛側を「より敏感にする」だけでは不十分です。攻撃者が使用する同じツールを使用し、プロトコルをレッドチームテストし、継続的に監視し、損害に対してハードリミットを設定する必要があります。最悪の状況でも生き残ることができるように。
Original Article Link
BlockBeats の公式コミュニティに参加しよう:
Telegram 公式チャンネル:https://t.me/theblockbeats
Telegram 交流グループ:https://t.me/BlockBeats_App
Twitter 公式アカウント:https://twitter.com/BlockBeatsAsia