Bitgetセキュリティ製品を踏み台にウォレットから資金流出

概要

• 暗号資産取引所Bitgetのホットウォレット・ウォームウォレットから約3億8750万ドル相当が流出した。SlowMistとMandiantの中間調査によれば、攻撃者は第三者製のセキュリティ製品（アプライアンス）2台を侵害し、そこから本番のウォレットジョブサーバへ横展開した。
• 最も古い不正活動はログ上8月31日まで遡り、送金開始（9月25日 02:31 UTC+8）のほぼ4週間前から足場があったことになる。秘密鍵の漏えいは確認されておらず、コールドウォレットは無事。攻撃者はカスタムの出金ツールで、取引所自身のシステムに「正当な出金」として処理させた。
• CEOのGracy Chen氏はIPの挙動パターンとオンチェーン分析を根拠に北朝鮮の関与を示唆している。悪用された製品名・ベンダー名は公表されていない。

この記事では、Bitget・調査会社・報道で確認できた内容を「事実」、筆者の推測や意見を「考察」として分けて書いています。報告書の時刻はUTC+8が基本で、日本時間（JST）を併記しています。

何が起きたか（時系列）

流出資産はETH、XRP、BNB、AVAX、USDT、USDCなどで、Ethereum、XRP Ledger、Arbitrum、Avalanche、Optimism、BSC、Baseの各チェーンが関わった。Bitgetによれば、流出はすべてホット・ウォームウォレットからだった。Bitgetは脆弱性は修正済みとしている。

技術的な問題点（根本原因）

事実

• 侵入の起点は、Bitget自身のシステムではなく、第三者製のセキュリティ製品だった。BleepingComputerは、2台のアプライアンスがゼロデイで侵害されたとするBitgetの説明を伝えている。ただしSlowMistの報告を見ると、ゼロデイとして明示されているのは製品Aで、製品Bの管理プラットフォームには内部従業員のIDでアクセスしている。
• 製品Aでは、サービスの環境変数にデータベースパスワードが平文で置かれており、攻撃者はそれを読んでDBに接続した。
• CEOのChen氏によれば、脆弱性を突いて「高位の内部認証情報」を得た攻撃者が、ウォレット基盤の重要なバックエンドシステムに侵入した。そこでトランザクションデータを偽装して取引所の承認プロセスを通し、偽の出金命令を発行した。
• 回収されたカスタム出金ツールは、ウォレットシステムの出金ロジックに合わせて作り込まれており、リスク管理パラメータを偽装して出金リクエストを組み立て、出金処理を呼び出していた。
• 秘密鍵の漏えいは確認されておらず、コールドウォレットは影響を受けていない（Mandiant、Bitget）。

考察

鍵を盗まずに資金を動かせたということは、署名・承認の仕組みが「上流から来た出金リクエストは正当」という前提で動いていたことを意味する。秘密鍵管理がいくら堅牢でも、署名を依頼する側（ウォレットジョブサーバ）が乗っ取られれば、システムは正規の手順で資金を送り出してしまう。2025年のBybit事件（北朝鮮による約15億ドルの窃取）でも、鍵そのものではなく署名に至る経路が狙われた点が共通している。

攻撃・侵入経路

flowchart LR
    A[攻撃者] -->|ゼロデイ<br/>8/31〜| B[第三者製品A<br/>隠しスクリプト]
    B -->|環境変数からDBパスワード| C[(製品AのDB)]
    A -->|9/24 特権アクセス| D[セキュリティアプライアンスB<br/>Webシェル＋C2]
    B -.->|認証情報など（推測）| D
    D -->|横展開| E[本番ウォレット<br/>ジョブサーバ<br/>悪性パッケージ]
    E -->|カスタム出金ツール<br/>リスク管理パラメータ偽装| F[出金・承認プロセス]
    F -->|9/25 02:31〜05:23 UTC+8| G[ホット/ウォームウォレットから<br/>複数チェーンで送金]

製品AとBの侵害の関係（A経由で得た情報がBの侵害に使われたのか）は、報告書でも明らかにされていない。図の点線は筆者の推測である。SlowMist・Mandiantともに、システム間の正確な経路はまだ調査中としている。

なぜ防げなかったか・構造的要因の考察

ここからは筆者の考察である。

1. セキュリティ製品は「信頼された特権ゾーン」にいる: 監視・アクセス制御・境界防御のための製品は、多くの場合、保護対象のネットワークに広く到達でき、強い認証情報を持つ。それ自体がゼロデイで落ちると、防御の要がそのまま攻撃者の最良の足場になる。NetScalerやSD-WAN Managerの件と同じ「エッジ・管理系機器が狙われる」構図が、暗号資産取引所でも起きた。
2. EDRの死角: アプライアンスには一般にEDRを入れられず、内部で隠しスクリプトが動いても気付きにくい。8月31日から約4週間、侵入が検知されなかったことがそれを示している。
3. 秘密の置き方: 環境変数に平文のDBパスワードという構成は、サービスプロセスを乗っ取られれば即座に資格情報が漏れる。ベンダー製品の内部実装であれば、利用者側では制御しにくい。
4. ウォレット環境とのネットワーク分離: セキュリティアプライアンスから本番ウォレットジョブサーバへ横展開できたことは、両者の間に十分な分離や通信制限がなかった可能性を示唆する（Bitgetは詳細を公表していない）。
5. 承認プロセスが「データの真正性」を検証していない: 偽装されたトランザクションデータで承認が通った。出金の妥当性を、リクエスト元とは独立した経路で検証する仕組み（独立した残高照合や、別系統でのユーザー出金要求との突き合わせなど）があれば、少なくとも被害規模は抑えられた可能性がある。
6. 製品名が非公表であることの影響: 同じ製品を使う他の組織は、自分が危険かどうか判断できない。調査中の非公表には理由があるにしても、ゼロデイの悪用が確定しているなら、ベンダーによる早期の告知と修正が業界全体にとって重要になる。

運用者向けの具体的な対策と検知ポイント

暗号資産事業者に限らず、高価値資産を扱うシステムの運用者向けに整理する（筆者の提案を含む）。

対策

• セキュリティ製品・管理系アプライアンスを「侵害されうる資産」として扱う: 資産台帳に載せ、管理インターフェースは管理専用ネットワークからのみ到達可能にし、ベンダーの脆弱性情報を最優先で追う。
• ウォレット（署名・出金）環境を強く分離する: セキュリティ製品を含むほかのゾーンから、ウォレットジョブサーバへの通信を必要最小限の許可リストに絞る。
• 出金承認の多層化: 署名側で、出金先の許可リスト、レート・金額の上限、時間帯による異常検知、ユーザーの元の出金要求と独立に突き合わせる照合を行い、上流のジョブサーバを無条件に信用しない。
• 秘密情報の管理: 環境変数に平文の資格情報を置かず、シークレットマネージャーと短命のクレデンシャルを使う。製品ベンダーにも同等の対応を求める。
• 特権IDの保護: 従業員IDでの管理プラットフォームへのアクセスにはフィッシング耐性のあるMFAとアクセス元制限を必須にし、深夜帯の管理操作は追加承認にする。

検知ポイント

• アプライアンス上での想定外のプロセス（サービスプロセスの子として動くスクリプト、シェル）、環境変数の読み取り、想定外のDB接続。
• セキュリティ製品・管理プラットフォームへのファイルのアップロードや設定変更、通常と異なる時間帯・アクセス元からの従業員IDログイン。
• アプライアンスからの外向き通信（C2）と、アプライアンスからウォレット系サーバへの通信。
• ウォレットジョブサーバでの新規パッケージ導入や、未知のバイナリの実行。
• 出金ログと元のユーザー出金要求の不一致、短時間に集中した複数チェーンでの大口出金、出金記録の改変。
• （Bitgetの事例から）ログ保存期間を十分に取る。今回の調査では送金の約4週間前まで遡る必要があった。

参考リンク

• BleepingComputer: Bitget hacked via zero-day in third-party security products
• Bitget: Bitget Security Incident (September 2026)
• Cointelegraph: SlowMist traces Bitget hack activity to Aug. 31 zero-day exploit
• The Crypto Times: Bitget $387.5M Hack: SlowMist and Mandiant Say Zero-Day Attack Began Weeks Before Theft