Bybit事件は、これまでよく見られてきた「スマートコントラクトの脆弱性を突かれる」型のハッキング事件と、本質的に何が違うのか？
これまでの主要なハッキング事件の多くは（DAO Hackや各種DeFiプロトコルのフラッシュローン攻撃など）、攻撃者がコントラクトのコード自体に存在する論理的欠陥を悪用したものだった——コードが誤って書かれており、攻撃者はコントラクトに意図しない挙動をさせる方法を見つけ出した。Bybit事件はまったく異なる。Safeのマルチシグコントラクトには論理的欠陥は一切なく、形式的検証を経たコアコードは設計通りに正しく動作し続けていた。攻撃者が迂回したのはコントラクトではなく、「人がコントラクトに署名する前に、自分が何に署名しようとしているのかをどう知るか」という情報経路全体だった。
この違いは重要だ。なぜなら「コントラクトは監査を通過しているか」という問いが、この種の攻撃には完全に的外れになるからだ。監査が検証するのはコントラクトのロジックが意図通りに動作するかどうかであり、署名者が見るインターフェースがコントラクトの要求を忠実に表示しているかどうかは、どの監査の範囲にも含まれない——この二つはまったく独立した信頼の連鎖なのだ。
なぜBybitのような十分な資金力を持つ大手取引所が、マルチシグウォレットの管理を自社開発ではなくサードパーティサービスに依存するのか？
マルチシグウォレットの暗号学的ロジック自体はそれほど複雑ではないが、それを複数の署名者が安全かつ日常的に扱えるインターフェースシステムとして仕立て上げるには、取引シミュレーション、異常検知、複数デバイス間の同期といった機能を含む、相当なエンジニアリングとセキュリティへの継続的投資が必要になる。Safe（旧Gnosis Safe）がイーサリアムエコシステムで主流のマルチシグソリューションとなったのは、まさにこの基盤を業界で認められる成熟度まで作り込み、各機関がゼロから車輪を再発明する必要をなくしたからだ。
しかしこれは構造的なリスクも生み出す。業界全体が少数の基盤サービス提供者に高度に依存するようになると、その提供者自体が単一障害点となる。攻撃者はSafeを利用する機関を一つずつ攻撃する必要はなく、Safe自身の開発環境への侵入に成功しさえすれば、そのインターフェースに依存するすべての顧客に同時に影響を与えられる。事件後、業界の議論が「ベンダーのセキュリティ評判だけを信頼するのではなく、ベンダーから独立した検証層を持つべきだ」という方向にシフトしたのは、まさにこのためだ。
Bybitほど経験豊富なチームでさえ騙されたのだとしたら、他の機関や個人が実際にこの種のインターフェース層攻撃を防ぐために取れる具体的な方法は何か？
業界で現在議論されている手法は主に3種類あり、いずれも「取引内容の生成と確認を同一のインターフェースだけに依存しない」という原則に基づく。第一は署名前シミュレーション——主要な署名インターフェースとは完全に独立した、異なる出所のツールを使って、その取引が実際に何を実行するかを再シミュレーションする。シミュレーション結果と署名インターフェースの表示が一致しない場合、それ自体が警告サインとなる。第二はハードウェアデバイス上での生データ確認——一部のハードウェアウォレットはインターフェースが生成した要約ではなく取引の生の呼び出しデータを表示できるため、署名者に「もっともらしく見える」要約だけでなく、実際にその生データを読み解けるよう訓練すること。第三は署名インターフェースが依存するフロントエンドコードのサプライチェーン管理——インターフェースが依存するすべてのフロントエンドパッケージとクラウドストレージのアクセス権限を監査し、インターフェース自体を攻撃対象領域の一部として管理し、デフォルトで信頼しないこと。
一般個人にとって、これらの機関レベルの手法をそのまま再現することは難しいが、根底にある原則は共通している。取引への署名を求めるあらゆる画面は、改ざんされうる情報源として扱うべきであり、特に高額な操作については、公式アプリやブロックチェーンエクスプローラーなど第二の独立した経路で一度クロスチェックする価値がある。
私はマルチシグウォレットを使っていないが、この事件は一般の個人投資家と実際にどう関係するのか？
通常のソフトウェアウォレットやハードウェアウォレットで日常的な取引に署名しているだけだとしても、Bybit事件が明らかにした核心的なリスクパターンはあなたに直接関係する。取引に署名する前に見る画面——ウォレットアプリのポップアップ確認画面であれ、ハードウェアウォレットの画面に表示される要約であれ——は何らかのソフトウェア層によって生成されており、その層自体が侵害される可能性がある。これはまさに、市場でますます多くのウォレットが「取引シミュレーション」機能を主要な売りとして打ち出している理由だ。署名する前に、インターフェースが単に主張している内容ではなく、独立した情報源から「この取引によって実際にウォレットの資産がどう変化するか」を示すのである。
日常的な操作に落とし込むと、特に多額の資産や不慣れなスマートコントラクトとのやり取りが絡む署名要求に対しては、二つの習慣を身につける価値がある。一つは取引シミュレーション機能を内蔵したウォレット（署名後に資産がどう変化するかをプレビューできるもの）を優先的に使うこと。もう一つは、特に高額な操作については公式チャンネルやブロックチェーンエクスプローラーを通じて送金先アドレスを別途確認し、単一のインターフェースが表示する内容だけを頼りに最終判断を下さないことだ。
2025年2月21日、Bybitは本来ごく日常的なはずの操作を実行した——コールドウォレットから約40万ETHをホットウォレットへ移し、日次の出金に充てるためだ。3人の署名者は標準手順に従い、画面上で送金先アドレスと金額を確認しながら順に署名を完了させた。画面に表示されたすべてが正しく見えた——ただし、その画面自体がすでに改ざんされていた。取引がオンチェーンで実行された後、Bybitはこの「日常的な送金」が実際には40万枚を超えるETHとstETH（時価約15億ドル）を攻撃者が管理するアドレスへ送金していたことに気づいた。これは仮想通貨史上最大の単独窃盗事件となり、攻撃者は北朝鮮の国家支援ハッカー集団Lazarus Groupに高い確度で帰属するとされている。
この事件で最も直感に反する点は、マルチシグウォレットそのものの暗号学的ロジックは一切破られていなかったことだ。Bybitのコールドウォレットは3-of-6のマルチシグ構成を採用しており、6人の指定署名者のうち3人が承認する必要があった——単一障害点を防ぐ業界標準の手法である。問題はBybitがこのマルチシグウォレット管理に利用していたサードパーティのインターフェースサービスSafe{Wallet}側で発生した。攻撃者はSafeの開発者環境に侵入し、クラウドストレージへのアクセス権限を取得、Safeのフロントエンドが取引署名インターフェースを描画するために使用するファイルに悪意のあるJavaScriptコードを注入した。このコードは特定の条件に一致する取引を検知した時のみ偽装を作動させるよう設計されており、それ以外は沈黙を保つため、通常のセキュリティチェックでは異常を察知しにくかった。
Bybitの署名者が予定通りこの送金を実行しようとした際、改ざんされたインターフェースが画面上に表示した送金先アドレスと取引内容は、実際にオンチェーンで署名された内容とはまったく異なっていた。実際に送信された取引はSafeコントラクトのupgradeTo関数を呼び出し、マルチシグウォレット全体を支えるロジックコントラクトを攻撃者がデプロイした悪意あるコントラクトに置き換えていた——これは事実上、ウォレット全体の制御権を明け渡すことに等しい。3人の署名者は会社の規定通り画面上のアドレスと金額を確認しており、プロセスのどの段階も省略されていなかった。ただ、彼らが確認していた画面自体が、最初から嘘をついていたのだ。
この攻撃パターンは業界でブラインド署名、またはインターフェース詐称攻撃として知られている——マルチシグの安全性保証全体は、署名者が承認しようとしている内容を正確に判読できるという前提の上に成り立っており、その判読を頼りにしているインターフェース自体が侵害された瞬間、この前提は崩壊する。特筆すべきは、BybitがSafe利用時に依拠していたマルチシグコントラクトが、業界で高く評価される厳格な形式的検証を経ており、長年の実運用の中でプロトコルレベルの重大な侵害は一度も発生していなかった点である。今回の事件は最初から最後まで、コントラクトのコード自体が破られたわけではなかった——署名者がコントラクトが何を求めているかを理解するために依拠していたインターフェース層が改ざんされたのだ。オンチェーンで見えるすべて、十分な署名数や正しいフォーマットの呼び出しを含め、完全に正当なものだった。ブロックチェーン自体には、これを悪意ある取引だと疑う理由が一切なかった——暗号学的には、それは完全かつ有効に署名された取引だったからだ。
事件発覚後、Bybit CEOのベン・チョウ（Ben Zhou）は速やかにSNS上で状況を公表し、事件発生から3日以内にGalaxy Digital、Wintermute、FalconXなどのパートナーとのブリッジローン、大口預金、OTC取引を通じて12億ドル超のETHを確保、準備金比率を完全に回復させ、事件発生からおよそ12時間以内に通常の出金サービスを再開した。この対応の速さが実現できたのは、Bybitが事件発生初期に損失規模を公に認め、独立監査機関による準備金証明レポートを同時に公開するという選択をしたことが大きい——沈黙を保ちながら状況を見極めようとしなかった点は、損失を過小評価しようとした結果ユーザーの信頼がさらに崩壊した他の取引所事例としばしば対比される。一方、攻撃者は盗んだ資産を、発行者による凍結権限が及ばないネイティブETHへ迅速に転換し、それぞれ約1万ETHを保有する約50個のウォレットに分散、その後9日間かけて一つずつ資金洗浄を行った。ブロックチェーン調査員と複数の分析機関がその後の資金の流れを追跡し続けている。
Bybit事件後、マルチシグ業界は「インターフェース層」自体をどう独立して検証すべきかという課題をより真剣に議論し始めた——署名者が署名前に主要な署名インターフェースとは完全に独立したツールを使って取引内容を再シミュレーションすること、ハードウェアデバイス上で画面に表示された要約ではなく生の取引データを直接確認すること、フロントエンドコードの更新のたびに複数人によるレビューを行うことなどが含まれる。これらの手法に共通する論理は一つ——「インターフェースが表示する内容＝実際に署名している内容」という等式はもはや前提として信頼できず、能動的に検証されなければならない、というものだ。
一般ユーザーにとってBybit事件が示す最も直接的な教訓は次の通りだ。マルチシグウォレット、ハードウェアウォレット、監査を通過したスマートコントラクト——これらのセキュリティ機構を積み重ねても、防げるのは攻撃者が暗号学を直接破ったり単一の秘密鍵を盗んだりするケースであり、「画面に表示されている内容自体が改ざんされている」という攻撃経路を必ずしも防げるわけではない。取引所のマルチシグ署名者であっても、あなた自身がハードウェアウォレットで一つの取引を承認する場面であっても、真の防御線は同じだ——あなたが確認している内容が、本当に信頼できるデバイスや独立した情報源から来ているのか、それとも改ざんされうる何らかの中間インターフェース層から来ているのか。次にウォレットのポップアップで「確認」を押す前に、「この情報は誰が生成したもので、独立して検証できるのか」ともう一問加えることは、マルチシグや監査報告書の評判だけに頼るよりもずっと実践的だ。