BitgetのオフチェーンでのUSD 3億8,750万ドル流出:鍵とコントラクトを超えて

2026年9月24日、Bitgetの一部の運用ウォレットから、Ethereumおよびその他のEVMネットワーク、XRP Ledger、Zcash、TRONにわたり、約3億8750万ドルが送金されました。Bitgetは影響を受けたウォレットをホットウォレットおよびウォームウォレットであると説明しました。オンチェーン取引には有効なウォレット署名が付与されていました。Bitgetは侵入経路をサードパーティのセキュリティ製品の脆弱性に起因するものとし、秘密鍵とコールドウォレットは侵害されていないと述べました [1, 2]。

2026年9月29日16:35 UTC時点で公開されている情報とオンチェーンの証拠に基づき、第1部では公表された攻撃の経緯、その後の資金移動、サービス復旧、そしてエコシステム参加者のさまざまな対応をまとめます。第2部では、これらの観察結果と私たちのセキュリティ経験を組み合わせ、暗号資産機関向けの多層防御フレームワークと実践的なセキュリティ推奨事項を提示します。

1. オフチェーンアクセスからオンチェーンの損失・回復まで

Bitgetは侵入経路をサードパーティのセキュリティ製品の脆弱性に起因するものとしていますが、当該製品、影響を受けたコンポーネント、または技術的な悪用の仕組みについては公表していません [1, 2]。同社の公式説明では、その後の経路として、内部アクセス、出金コマンドの偽造、リスク検証の回避、有効な署名、オンチェーン送金が挙げられています。

1.1 攻撃のタイムラインと帰属

Bitget CEOのGracy Chen氏が報告したタイムラインと、オンチェーン記録から、事件の展開が明らかになっています [3]:

• 9月24日18:31 UTC:最初の移動は0.84 ETHと93 TRXでした。いずれも取引所のリスク管理しきい値を下回っていました。
• 18:58-20:09 UTC:Chen氏は、Ethereum、XRP Ledger、Zcash、BNB Chain、Base、Arbitrum、Optimism、Avalancheにまたがる17件のより大規模な送金があり、合計で約3億6100万ドルに達したと説明しました [3]。オンチェーン記録は、19:16 UTCにTRONで2059万 TRXの送金があったことも示しています。
• 最初の大規模送金から7分後:Bitgetの照合システムが不一致を検出し、ユーザーが開始する出金を停止しました。Bitgetのタイムラインでは、この対応と、21:44 UTCに行われたウォレットの出金・署名サービスのその後の停止とを区別しています [1]。

Chen氏は、攻撃者が不正コマンドの痕跡を削除したと述べました [3]。暫定的な帰属について、同氏はIPアドレスの挙動とオンチェーンのパターンが既知の北朝鮮のハッキンググループと高い一致を示していると述べました [4]。これはあくまで暫定的な帰属であり、最終的な結論ではありません。Bitgetの公式インシデントページでは責任のあるグループは名指しされておらず、調査は現在も継続中です [1]。

1.2 資金フローと業務復旧

Bitgetの公式トラッカーに反映されたオンチェーン記録によれば、盗まれたステーブルコインは数分以内に ETH に変換されました [5]。USDTやUSDCとは異なり、ETHのようなネイティブ資産には発行者が制御する凍結機能がありません。この挙動は、発行者による凍結のリスクを減らそうとする試みと整合していますが、それによって攻撃者の身元や熟練度が特定できるわけではありません。

Bitgetがより網羅的な集計を行い、ZcashとTRONを含めたことで、公式の影響額は後に約3億8750万ドルに上方修正されました [1]。Bitgetは攻撃者のアドレス、回復報告用のポータル、アドレスAPIを公開し [1, 6]、リアルタイム追跡サイトも公開しました [5]。同サイトの保有状況ビューは現在の分布状況を報告し、資金フローグラフは下流のアドレス、サービス、ブリッジ、クロスチェーン経路を可視化しています。

9月29日16:35:28 UTC時点で、公式トラッカーは攻撃者の現在の保有額を3億2267万ドル、8件にわたって凍結された金額を約632,700ドル、発行者が凍結可能なステーブルコインを312,500ドル、送金中または分析中の金額を5587万ドルと報告しました [5]。凍結総額の内訳は、NEAR Intentsでの293,507ドル(実行時に約503,000ドルが凍結されたと同社は報告しています [12])、Tetherによる239,242ドルの凍結、Circleによる99,990ドルの凍結でした。公開情報ではNEAR Intentsの数値の整合性は確認できていません。

同時刻において、アドレスエクスプローラーでは帰属アドレスの残高がBTC(2億8851万ドル)、ZEC(2891万ドル)、ETH(717万ドル)に集中していることが示されました [5]。エクスプローラーは概要とは異なる分類範囲を用いているため、そのアドレスレベルの合計3億2769万ドルは、概要の現在の保有額3億2267万ドルと直接比較することはできません。

業務復旧も進展しました。Bitgetは9月29日08:00 UTCにETHの出金を再開しました。09:00 UTC時点で、流入は約9,674 ETH、流出は9,023 ETHと報告されており、流入が流出を約651 ETH上回りました [7]。

1.3 資金流出後:コミュニティの対応

資産が影響を受けた機関のウォレットを離れると、回復は元のセキュリティ境界の外側にある組織に依存することになります。Bitgetは追跡データを公開し、資金を凍結または回収する有効な支援に対して報奨金プログラムを開始しました [1, 6]。Binanceは、自社のセキュリティチームが情報を共有し、資金を追跡し、回復を支援したと述べました [8]。Bybit CEOのBen Zhou氏は支援を申し出て、LazarusBounty回復プラットフォームを更新し、2025年に発生した自社のインシデントの際にBitgetがBybitを支援したことに言及しました [9]。Bybitの対応は、両取引所間における相互支援のパターンを継続するものでした。

インフラ提供者は、それぞれの技術設計とガバナンスモデルの違いにより、異なる選択肢を持っていました。Bitgetは、公開されて積極的に追跡されている攻撃者アドレスへのサービス提供を拒否するようTHORChainに要請しました。Gracy Chen氏は「分散化は設計原則であり、既知の盗難資金の便宜を図るための盾ではない」と主張しました [10]。THORChainは、選択的なブラックリスト化をサポートしていないと説明しました。同社の緊急制御機能は、単一のアドレスや取引ではなく、より広範な活動やチェーン経路全体を停止できるものです。盗まれた資産の一部は、同ネットワークを通じてETHからBTCへの移動を続けました [11]。

NEAR Intentsは異なる対応を報告しました。同社のSHIELDリスクシステムは、重複した試行をフィルタリングした後、攻撃者に関連する5000万ドル超の送金試行を特定・ブロックしました。実行中に約503,000ドルが凍結され、約166,000ドルが通過しました。NEAR Intentsはまた、Bitgetの回復報奨金における自社の取り分を放棄しました [12]。この5000万ドルという数字は、システムが処理を拒否した試行的な送金額であり、凍結または回収された金額ではありません。

大規模なクロスチェーンの資金回復には、通常複数の参加者が必要です。取引所は預入や出金を保留でき、ステーブルコイン発行者はトークンを凍結できる場合があり、ルーティングサービスは設計上可能な場合には帰属フローを拒否でき、基盤プロトコルは監視と指標の共有しかできない場合もあります。効果的な連携は、各参加者が自らどのような行動を取れるか、どのような証拠を必要とするかを明示することから始まります。

介入にもリスクが伴います。誤った帰属は無実の利用者を阻害する可能性があり、恒久的なブラックリストはインシデント対応ツールからより広範な取引制限メカニズムへと拡大しかねません。正当性のある対応には、裏付けのある証拠、範囲を限定し期限を定めた制限、異議申立てプロセス、透明な行動記録、事後レビューが必要です。選択的制御を持たないシステムでは、透明な能力開示によって現実的な期待値を設定するのに役立ちます。裁量権がある場合には、公開された基準と説明責任を伴う意思決定が一貫した対応を支えることができます。

2. 悪用経路の遮断と封じ込め:体系的な多層防御セキュリティフレームワーク

第1部で示した事件の経路と対応、そして私たちの経験と専門知識をもとに、以下の2層フレームワークを提案します。コード監査と監視がなぜ資金取扱経路全体をカバーしないのかについては、暗号資産機関がブロックチェーン侵入テストを必要とする理由 [13] をご覧ください。

• 公表された悪用経路は、サードパーティのセキュリティ製品からオンチェーン送金へと至ります。
• フレームワークの防止・検知層には、最初の3つのセキュリティ手法が含まれます。2.1節と2.2節では、特権アクセス制御と独立した意図検証によって、インフラへの侵入拠点が署名にまで進行するのをいかに防げるかを検討します。2.3節では資産フローの監視について扱い、これは送金異常を検知・エスカレーションし、リスクのある入金を保留できます。
• 対応・回復層には4つ目の手法が含まれます。これは、防止・検知層のいずれかの箇所からの高信頼度シグナル、または運用上の障害によって発動される可能性があります。2.4節では、影響を受けた業務を独立して一時停止する能力、または露出した資産を検証済みの安全な送金先へ移動する能力について扱います。

各サブセクションは同じ構成に従っています:セキュリティ上の目的、事件経路によって明らかになったリスク、そして機関が構築できる予防・検知・対応能力です。これらの手法は独立した権限と証拠に依拠する必要があります。これらを組み合わせることで、単一の保護策への依存を減らし、機関が損失を封じ込めるための準備された選択肢を得ることができます。

2.1 特権アクセスと出金コマンド

目的は、インフラまたは特権システムの侵害だけでは、信頼された出金コマンドを作成するのに十分な条件とならないようにすることです。

サードパーティ製品は、資産移動に影響を与えるために直接的な署名アクセスを必要としません。出金コマンドの内容を左右する認証情報やシステムへのアクセスがあれば、別のシステムが何に署名するかを決定するには十分な場合があります。このような製品は、機関レベルのWeb3攻撃対象領域に属します [14]。そのリスクは、それが影響を及ぼしうる価値と到達しうるシステムの範囲に依存します。

必要な制御手段には、最小権限の原則、ネットワークの分離、更新・管理経路の制限、短期間の認証情報、改ざん耐性のあるログ、テスト済みの権限取り消し手順が含まれます。内部アクセスがあるからといって、それだけで信頼された出金コマンドを作成できる権限が自動的に付与されてはなりません。すべてのコマンドには、認証済みの発信元、不変のリクエスト識別子、署名済みまたは他の方法で認証された構成バージョンが付随すべきです。コマンドの作成、承認、署名、ブロードキャストは別々の権限に属するべきであり、下流のシステムは、発信元が不明であったり、構成が古かったり、バインディングが不完全なコマンドを拒否すべきです。

2.2 出金の意図と署名

目的は、偽造または改ざんされた出金コマンドが、有効に署名された取引にならないようにすることです。

有効な署名は、対応する秘密鍵が取引データに署名したことを確認するものであり、元となる出金要求が正当であったこと、あるいは独立して承認されたものであることを証明するものではありません。

署名の境界では、独立した信頼できる記録から期待される取引を再構築し、価値を移動しうるすべてのフィールドを比較する必要があります。少なくとも、承認にはチェーン、資産、金額、受取人、送金元ウォレット、取引ナンス、手数料の上限、有効期限、元の出金または財務リクエストを紐付ける必要があります。

出金を構築するコンポーネントが、それを承認するために使用される唯一の情報源であってはなりません。ポリシー評価は独立したアカウントおよびリスクデータを利用すべきであり、一方、署名システムは最終的な取引データが承認された意図と一致することを検証すべきです。有効な署名者の集合、署名しきい値、取引ナンス、構成は、期待される本番環境の状態と一致していなければなりません。人によるレビュー担当者には、要求元のバックエンドから提供される変更可能な要約ではなく、署名対象となる正確なバイト列から生成された、正規化された取引表示が必要です。

2.3 出金・入金の資産フロー

目的は、実際の資産移動が独立して再構築された業務上の意図から乖離した場合にそれを検知することです。

暗号資産機関は、デジタル資産フローの送金元にも送金先にもなり得ます。出金の監視では、実際のチェーン上の活動と、独立して再構築された承認済み出金の集合とを比較する必要があります。独立性を保つため、監視は出金システムが生成したものと同じコマンドのみに依存すべきではありません。

監視は、期待されるチェーン、資産、金額、受取人、タイミング、ウォレットを、別の業務記録から導き出すべきです。また、取引ごとの上限では見逃される次元をまたいだ挙動を集計すべきです:

• 少額のテスト送金に続く急速なエスカレーション。
• 複数のアカウント、資産、チェーンにわたる新規受取人の再利用。
• 出金の速度または総露出額の急激な増加。
• 複数の運用ウォレット階層からの同時流出。
• 凍結が困難なネイティブ資産への移行。
• 承認済みリクエスト、署名済み取引データ、ブロードキャストされた取引の間の相違。

制御手段は、累積金額、速度、送金先が新規かどうか、ウォレットの階層、資産の換金しやすさ、一定の時間枠内でのクロスチェーンの挙動を評価すべきです。Bitgetの当初のETHおよびTRXの移動は、取引を孤立した個別の事象としてだけでなく、一連の流れとして評価することの重要性を示しています [3]。高信頼度の不一致が検出された場合は、2.4節で説明する緊急対応経路を発動すべきです。信頼度がより低い異常については、二次承認、送金先のクーリング期間、上限の引き下げ、または一時的な出金保留が必要となる場合があります。

入金の監視は、入金を反映する前にスクリーニングし、出金前に再スクリーニングすべきです。最初の攻撃者アドレスとの一致のみを確認するのでは不十分であるため、ブリッジ、分散型取引所(DEX)、意図ベースのルーティングサービス、中間アドレスを通じて資金を追跡すべきです。高信頼度の一致には、資金の保留、一致の調査、異議申立ての処理、法的手続きの引き渡しを完了するための文書化されたプロセスが必要です。

取引所間での迅速な情報共有は、入金のスクリーニングをネットワーク効果に変えます。ある機関が事件を検知する一方で、別の機関がその収益を発見することがあります。共有された機械可読な指標と最新の連絡先情報は、帰属分析から行動までの間隔を短縮します。

2.4 緊急一時停止と資産移動

目的は、高信頼度のセキュリティシグナルまたは運用上の障害が特定された時点で、残りの露出を封じ込めることです。

シグナルには、特権アクセスまたはコマンド完全性の違反、出金意図または署名の不一致、異常な出金、入金、その他のオンチェーン活動、照合の失敗などが含まれます。その場合、機関は影響を受けた署名、ブロードキャスト、出金、またはウォレット操作を一時停止できる必要があります。資産が依然として露出している場合には、疑わしいウォレットから事前に定義された安全な送金先へ資産を移動できる必要もあります。一時停止は調査の時間を確保し、移動は残りの露出を減らします。

• 独立した一時停止権限: 主要な管理システムが侵害された場合でも、一時停止機能は利用可能であり続けなければなりません。アーキテクチャが許す範囲で、特定のチェーン、ウォレット、資産、または操作を停止できるよう、その範囲は十分に狭く設定すべきです。発動および解除には、認証された権限、改ざん耐性のある記録、明確な再開基準、劣化した状況下でのテストが必要です。
• 移動経路の継続性: 構成変更によって、旧来の緊急経路が、その代替経路がデプロイ、承認、署名、保管、テストされる前に無効化されてはなりません。
• 実行可能な取引の準備状態: 保管されている緊急用取引は、ナンスの変更、手数料を支払うためのネイティブトークン残高の不足、送金元資産の残高変動、署名済みの手数料上限を使用不能にする手数料市場の変化、有効期限の切れ、構成の更新などにより、古くなる可能性があります。準備状態のチェックは、これらの依存関係を継続的に検証すべきです。完全に署名済みの取引データは、緊急対応が承認され、即座にブロードキャストできる状態になるまで、暗号化されアクセス制御された状態を保つべきです。
• カバレッジとフェイルオーバー: すべての運用ウォレット、チェーン、ネイティブ資産、対応トークンには、主経路とフォールバック経路の両方の移動経路が必要です。ブロードキャストおよび検証インフラにも、リモートプロシージャコール(RPC)エンドポイント、運用システム、手動回復ツールにわたる冗長性が必要です。
• 完了確認と訓練: 緊急対応手順は、確認されたオンチェーン実行、資産ごとの検証、残存残高の確認、オンチェーンの状態と内部記録との照合によって完了を定義すべきです。また、チェーンの再編成や失敗した取引も検知すべきです。定期的な訓練により、検知から最終的な残高確認までの完全な回復時間を測定すべきです。

認可されたブロックチェーン侵入テストは、合意された範囲内で稼働中の環境に対して実際に検証を行うことで、レイヤーをまたぐ前提を証拠に変えることができます [15]。本番環境でのテストでは、テスト開始前に、権限、許可される技術、中止基準、価値の上限、連絡方法、証拠の取り扱い、一時停止権限を定めた文書化された交戦規定(Rules of Engagement, RoE)を用意すべきです [16]。

結論

Bitgetの事件は、秘密鍵の漏洩でもスマートコントラクトの悪用でもありませんでした。Bitgetによれば、攻撃者はサードパーティのセキュリティ製品の脆弱性を悪用してイントラネットのアクセス認証情報を取得し、その後、出金コマンドを偽造し、ウォレットシステムがそれを有効に署名されたオンチェーン送金として処理してしまったとのことです [1, 2]。資産が影響を受けた機関を離れた後、回復はエコシステム全体で共有される取り組みとなります。Bitget、Binance、Bybit、THORChain、NEAR Intentsの対応は、参加者がさまざまな方法で対応しうることを示しています [8-12]。重大なセキュリティ事件や脅威が発生した際に、コミュニティがどのようにこれらの能力を迅速かつ責任を持って連携させられるかは、暗号資産業界にとって、より広範な課題であり続けています。

明らかになった下流の経路は、ここで提案されている、防止・検知と対応・回復を結びつける体系的なフレームワークに反映されています。機関は、特権アクセスを制限しコマンドの発信元を認証すること、署名時に承認済みの出金意図を独立して再構築すること、出金の一連の流れと入金の収益を監視すること、そして独立して運用可能な一時停止・移動経路を維持することによって、単一の保護策への依存を減らすことができます。カストディは依然として不可欠であり、これらの手法は資金取扱の全経路にわたってそれを補完するものです [13, 15]。

参考文献

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement