← 記事一覧へ

暗号資産の被害、3カ月で約2,000億円:最大のBitget事件はセキュリティ製品のゼロデイが入口だった。

CertiKの集計で2026年7〜9月の被害は248件・約1,999億円、前期比54%増。ただし返還分などを差し引くと10%増にとどまります。約610億円が流出したBitget事件の侵入経路と、セキュリティチームが見直すべき点を整理します。

事案の発生時期: 2026年7〜9月。Liquid Networkは9月6日、Bitgetは9月25日(日本時間)出典確認日: 2026/10/3

30秒でわかる要点

要点
CertiKは第3四半期の暗号資産損失を12.7億ドルと集計。Bitgetの事例は、セキュリティ製品の権限とアクセス可能な秘密情報の見直しを促します。
対応するチーム
EDR、SIEM、IT運用、委託先リスク、メールセキュリティ
最初のアクション
セキュリティ製品が扱える認証情報・実行権限を把握し、重要な署名権限を分離します。
不確実性・注意点
Bitgetの対象製品・脆弱性は未公表。損失総額と返還分を調整した金額は区別が必要です。
展示会のBitgetのブース。ディスプレイの壁の上に光るBitgetのロゴ。
写真:Harris de Weerd、CC BY-SA 4.0(Wikimedia Commons、トリミング)
実務への示唆

自社のセキュリティ製品が明日侵害されたら、その製品はどの秘密情報を読めて、管理画面からほかのシステムに何を実行させられるでしょうか。

確認されていること

ブロックチェーンのセキュリティ企業CertiKは、暗号資産のセキュリティ事案を集計したダッシュボードを公開しています。2026年10月3日時点で、7〜9月(第3四半期)の数字は次のとおりです。CertiK Security Dashboard(英語)。金額はNADA NEWSと同じ1ドル=157.4円で換算しています。

概要図:「3カ月で約2,000億円。うち56%が2件。」の見出しの横に、CertiKによる2026年第3四半期の被害額の内訳。Bitget約610億円(30.5%)、Liquid Network約502億円(25.1%)、その他の246件約887億円(44.4%)。返還分などを差し引いた額は約1,369億円

概要:この記事のために作成した図です。

  • 被害額(総額):12.7億ドル(約1,999億円)。 第2四半期の8億1,940万ドル(約1,290億円)から54.4%増。
  • 返還分などを差し引いた額:8億6,960万ドル(約1,369億円)。 第2四半期の7億9,070万ドルから10.0%増。返還・回収された資金を差し引いた数字です。
  • 件数:248件。 第2四半期の219件から13.2%増。NADA NEWSは10月2日更新時点の249件を報じています。NADA NEWS。
  • 9月:7億7,240万ドル(約1,216億円)。 四半期の約6割。うちエクスプロイトが7億3,950万ドルで95.7%を占めます。
  • 最大の事案:Bitgetの3億8,750万ドル(約610億円)。 四半期の約3割。2番目はLiquid Networkの3億1,870万ドル(約502億円)です。

BitgetとLiquidの2件で、四半期の被害額の約56%、9月の約91%を占めます。

棒グラフ。2026年第2四半期は総額約1,290億円、返還分などを差し引いた額約1,245億円。第3四半期は総額約1,999億円、差し引いた額約1,369億円。総額は54.4%増、差し引いた額は10.0%増。第3四半期の差額約630億円には、TRM LabsによるとLiquidに返還されたビットコイン約428億円が含まれる。右側に件数が219件から248件へ13.2%増、NADA NEWSが引用した10月2日更新時点では249件という注記。

図1:被害額は54%増、返還分を差し引くと10%増。この記事のために作成した図です。

Bitget:2つのセキュリティ製品を経由した侵入

Bitgetは海外の暗号資産取引所です。公表ページによると、日本時間2026年9月25日3時31分(UTC 9月24日18時31分)、一部のホットウォレットとウォームウォレットからの不正な送金を検知しました。Bitget 公表ページ。9月30日更新の内容は次のとおりです。

  • 影響範囲: 約3億8,800万ドルが12のウォレットアドレスから流出。すべてホットウォレットかウォームウォレットで、秘密鍵は漏れておらず、資産の大部分を保管するコールドウォレットにも影響はありません。
  • 手口: 第三者製のセキュリティ製品の脆弱性を悪用して内部ネットワークの認証情報を盗み、ウォレットシステムに偽の出金命令を書き込んだ。システムはこれを通常の出金として処理し、リスク検証を回避した。
  • 一般的なマルウェアは使っていない: 攻撃者は正規の身元と通常の運用手順を装って活動し、送金後に痕跡を消したと説明しています。
  • 対応: 脆弱性を修正し、内部の認証情報をすべてリセット。高い権限へのアクセスを絞り、ベンダーに通知して該当機能を停止し、出金の独立した検証を強化した。
  • 利用者への影響: 損失は5,500BTC(4億6,400万ドル超)を保有する保護基金で補填し、利用者の残高には影響しないとしています。出金は9月28日から段階的に再開し、残りの資産は10月2日に再開予定でした。

Mandiantとともに調査しているSlowMistは、9月29日に中間報告を公開しました。SlowMist 中間報告(PDF、英語)。2つの製品を「製品A」「製品B」と呼び、時刻はUTC+8で記載しています。日本時間に直すと次のとおりです。

  • 8月31日から(UTC+8の日付): 製品Aのあるノードで動くサービスがゼロデイ脆弱性の影響を受けた。攻撃者はサービスのプロセス配下で隠しスクリプトを実行し、DBパスワードを保持する環境変数を読み出してデータベースに接続した。9月23日と25日には、ほかの2ノードでも同様の活動があった。
  • 9月25日1時7分から: 社内の従業員のIDで製品Bの管理プラットフォームにアクセス。タスクのパラメーター経由でシステムコマンドを注入する試みを3回行い、続いてWeb実行用のエンドポイントからコードを送信して、サーバー設定の変更、通信の中継ファイルの書き込み、不正プログラムのアップロードを試みた。GIGAZINEは、Mandiantの調査としてWebシェルと外部の指令サーバーとの通信経路の確保を報じています。GIGAZINE。
  • 2時49分: ウォレットシステムの出金ロジックに合わせて作られた出金ツールが、ウォレットアプリケーションのホストで動き出した。ツールはコードの中でリスク管理のパラメーターを偽装し、出金リクエストを作って出金処理を呼び出した。
  • 3時31分〜6時23分: 複数のチェーンで攻撃者のアドレスへ送金。約2時間52分。
  • 6時22分以降: ウォレットDBの出金記録を直接書き換えようとし、偽装したBTC出金2件は処理に入ったもののエラーになった。SlowMistは攻撃者が削除したファイルから出金ツールを復元しています。

攻撃者がシステム間をどう移動したかは、SlowMistが引き続き調査中です。

Bitget事件の6つの段階と、それぞれを断つ対策。製品A(第三者製のセキュリティ製品):8月31日から、ゼロデイを悪用した隠しスクリプトが環境変数からDBパスワードを読み出した。対策:セキュリティ製品をティア0として扱い、DBの認証情報はボールトから短期間だけ発行し、DBは既知のホストからの接続だけを受け付ける。破線の空白:システム間の移動は調査中。対策:すべてのセキュリティ製品のログをSIEMに送る。製品Bの管理プラットフォーム(9月25日1時7分から):従業員のIDでアクセスし、タスクのパラメーターからのコマンド注入とWeb実行用の窓口からのコード送信。対策:コマンド実行機能の無効化か承認制、初めてのユーザーとIPの組み合わせの検知。ウォレットアプリケーションのホスト(2時49分):専用ツールがリスク管理のパラメーターを偽装。対策:出金を別のシステムで1件ずつ検証。ホットウォレットとウォームウォレット(3時31分〜6時23分):12アドレスから約3億8,750万ドル。対策:残高の上限と、送金と承認のリアルタイムの突き合わせ。痕跡の隠蔽(6時22分以降)。対策:ログをホストの外の改ざんできない保存先に送る。

図2:セキュリティ製品からホットウォレットまで。段階はSlowMistとBitgetの公表に基づき、対策は当サイトの分析です。この記事のために作成した図です。

Liquid Network:検証ソフトウェアの不具合と、85%の返還

Liquidは、Blockstreamが開発したビットコインのサイドチェーンです。準備金としてロックされたビットコインが、サイドチェーン上で使うトークンL-BTCの裏付けになっています。TRM Labsによると、2026年9月6日、攻撃者はLiquidの取引検証ソフトウェアの不具合を突いて裏付けのないL-BTCを作り、本物のビットコインと交換しました。準備金約4,200BTCのうち約4,000BTC、約3億1,900万ドルが引き出されています。TRM Labs(英語)。

Chainalysisは、キャッシュされたチェックの識別方法に欠陥があり、新しいデータが承認済みのデータと取り違えられうる状態だったと説明しています。Chainalysis(英語)。攻撃者はホワイトハッカーを名乗り、9月7日に約3,400BTC(約85%、約2億7,200万ドル)を返還しました。9月9日時点で約600BTC(約4,700万ドル)が攻撃者の手元に残っています。Blockstreamは修正したソフトウェアを展開しました。

セキュリティ態勢の見直し

合計額ではなく、事案ごとに読む

当サイトの分析: 暗号資産の被害額は、ごく少数の大型事案に左右されます。今期はその典型です。見出しの数字を決めたのは2件で、総額と調整後の差額約630億円のうち、約428億円はLiquidに返還されたビットコインだけで説明できます。調整後で比べれば、第3四半期は第2四半期より54%ではなく10%悪化したにすぎません。残る246件の合計は約887億円です。

経営層やリスク委員会にこの種の数字を報告するなら、次の4点を押さえます。

  1. 大型事案を分けて示し、その後に残りを示す。 1件で四半期の数字が数十%動きます。
  2. 総額か調整後か、どちらを使うかを明記し、 四半期をまたいで同じ基準で比べる。
  3. 日付を添える。 ダッシュボードは随時更新され、件数は10月2日に249件、3日に248件でした。
  4. 分類ラベルで脅威モデルを決めない。 CertiKはBitgetもLiquidも「エクスプロイト」に分類していますが、一方は取引所のネットワークへの侵入、もう一方はサイドチェーンのソフトウェアの不具合です。必要な防御はまったく違います。

件数で見ると、9月にはフィッシングが13件、秘密鍵の侵害が11件、ウォレットの侵害が7件ありました。自社のウォレットで暗号資産を保有する組織にとっては、プロトコルの不具合よりこちらのほうが現実的な脅威です。

2本の積み上げ棒グラフ。2026年第3四半期(約1,999億円):7月・8月が約783億円(39%)、9月が約1,216億円(61%)。9月の内訳:Bitget約610億円(50%)、Liquid Network約502億円(41%)、その他約104億円(9%)。下に9月の攻撃手法別。被害額:エクスプロイト約1,164億円、秘密鍵の侵害約22億円、ウォレットの侵害約16億円、フィッシング約10億円、詐欺約3億円。件数:エクスプロイト60件、フィッシング13件、秘密鍵の侵害11件、脅迫7件、ウォレットの侵害7件。CertiKはBitgetもLiquidもエクスプロイトに分類しているが、一方はネットワークへの侵入、もう一方はソフトウェアの不具合という注記。

図3:9月が四半期の61%、その9月の91%が2件。数値は2026年10月3日時点のCertiKのダッシュボードに基づきます。この記事のために作成した図です。

最初の足場はセキュリティ製品だった

当サイトの分析: 攻撃者がウォレットにたどり着くまでに使った2つのシステムは、どちらもセキュリティ製品でした。これは驚くことではありません。セキュリティ製品は広い権限で動き、ネットワークの多くを見渡せます。アプライアンスやベンダー管理のノードであることが多く、自社のEDRを入れられません。しかも管理画面は、ほかのマシンにタスクを送るために作られています。つまり、設計上リモート実行の仕組みそのものです。

確認すべき点は4つです。

  1. ティア0として扱う。 運用しているすべてのセキュリティ製品のノードと管理プラットフォームを洗い出し、ドメインコントローラーと同じ水準で守る。管理は専用の管理端末から、専用の管理者アカウントとフィッシング耐性のある多要素認証で行う。
  2. 管理画面で何が実行できるかを把握する。 スクリプト、コマンド、タスクの機能をすべて洗い出し、使わないものは無効化し、残りは承認制にして、使われるたびに検知する。
  3. ログを外に出す。 管理画面へのサインイン、タスクの実行、設定変更をSIEMに送り、十分な期間保存する。SlowMistが確認できた最も古い活動は、残っていたログの範囲で8月31日でした。実際の始まりはもっと前かもしれません。
  4. 自社では修正できないゼロデイを想定する。 ベンダーがどう知らせてくれるのか、修正までに何を止められるのかを確認する。製品のノードはネットワークを分け、侵害されても不要なデータベースには届かないようにする。

環境変数は金庫ではない

当サイトの分析: 製品Aからデータベースへの一歩に必要だったのは、環境変数を読むコマンド1つでした。Linuxでは、プロセスの環境変数は同じユーザーとrootから /proc/<pid>/environ で読めます。子プロセスにもそのまま引き継がれるため、脆弱性を突いてサービス配下で起動したスクリプトからも読めます。

  1. 秘密情報は実行時にシークレットマネージャーから取得し、 サービスごとに範囲を絞る。可能ならDBの認証情報は短期間だけ有効なものにし、プラットフォームが対応していればワークロードIDを使う。サービスの権限で動くコードは秘密情報を取得できてしまいますが、盗まれた認証情報は期限が切れ、取得のたびに記録が残ります。
  2. データベースはネットワークとアカウントの両方で絞る。 サービスアカウントは、そのサービスのホストからしか接続できないようにし、それ以外からの接続を検知する。
  3. 今どこに秘密情報があるかを調べる。 後述のシェルの例は、秘密情報らしい環境変数の名前(値ではない)をホストごとに一覧にします。

攻撃者が偽装できたリスクチェック

当サイトの分析: Bitgetの出金ツールは、リスク管理のパラメーターを自身のコードの中で偽装していました。つまり「この出金はリスクチェックを通過した」という記録を呼び出し側が渡し、ウォレットの処理がそれを受け入れていたことになります。リクエストを作るホスト上で動く、あるいはそのホストからの入力を信用するチェックは、そのホスト上のコードで回避できます。

Bitgetが挙げた対策、出金の独立した検証は、お金を動かすすべてのシステムに当てはまります。ERPの支払処理、全銀データなどの振込ファイル、財務システムも同じです。経理・財務の担当と一緒に、次の3点を確認します。

  1. 承認は、依頼側から届かない場所で検証する。 署名や送金の段階で、リクエストに含まれるフラグではなく、承認の正本となるシステムと照合する。
  2. オンラインに置く残高を小さくする。 Bitgetではコールドウォレットが無事だったため、損失はホットとウォームのウォレットの残高までに収まりました。
  3. 送金を常に突き合わせる。 すべての送金を承認済みのリクエストと照合し、一致しないものがあれば数分以内に担当者を呼び出す。SlowMistの記録では、最初の送金から3時間近く送金が続いていました。

「マルウェアなし」は「ツールなし」ではない

当サイトの分析: Bitgetは、攻撃者が一般的なウイルスやマルウェアを使わなかったと説明しています。それでも調査結果には、隠しスクリプト、中継ファイル、アップロードされたプログラム、Bitgetのシステム専用に作られた出金ツールが登場します。EDRの担当にとっては安心材料ではありません。既知のシグネチャーに一致するものが何もないからです。検知の手がかりは振る舞いにあります。サービスのプロセスがシェルを起動した、管理画面のアカウントが初めてコマンドのタスクを実行した、DBのアカウントが新しいホストから接続した、といった変化です。そして、承認のない出金という業務ロジックの異常です。

国内の事業者にとっての意味

当サイトの分析: 国内では2024年5月、DMM Bitcoinから4,502.9BTC(当時約482億円)が流出しました。警察庁はFBIなどと共同で、北朝鮮を背景とするTraderTraitorの犯行と特定しています。攻撃者はリクルーターを装ってウォレットソフトウェア企業Gincoの従業員に接触し、採用試験を装った悪意あるPythonスクリプトを渡しました。その後、セッションクッキーを悪用してその従業員になりすまし、Gincoの通信システムに侵入して、DMM Bitcoinの従業員による正規の取引リクエストを改ざんしています。警察庁 注意喚起。

入口の手口は違いますが、構図はBitget事件とよく似ています。

  • 入口は自社の外の製品や委託先だった。 DMM BitcoinではGinco、Bitgetでは第三者製のセキュリティ製品。
  • 実在の従業員の身元が使われた。 なりすましたセッションや、従業員のIDでのアクセスです。
  • 正規の出金・取引の流れの中で改ざんされた。 署名する段階で、承認の正本と独立して照合していれば止められた可能性があります。

国内の暗号資産交換業者は、内閣府令により利用者の暗号資産の95%以上をコールドウォレット等で管理することが求められています。暗号資産交換業者に関する内閣府令(e-Gov)。この規制はオンライン上に置く資産の割合を抑えますが、ホット側の金額そのものは事業規模に応じて大きくなりえます。そして、出金の仕組みを乗っ取られることは防げません。交換業者以外でも、暗号資産を扱う決済事業者やウォレットの委託先は、自社が使うセキュリティ製品と委託先の管理画面を、出金経路の一部として評価すべきです。

Liquid:1カ所に集まった準備金と、キャッシュされた承認

当サイトの分析: Liquidの準備金はL-BTCの裏付けとなるビットコインのほぼすべてを抱えていたため、1つの検証の不具合でそのほぼ全額が危険にさらされました。TRM Labsも同じ点を指摘しています。ブリッジやラップされた資産を保有・受け入れている組織は、どれが準備金に対する請求権なのか、誰がその準備金を運用しているのか、どう壊れうるのかを把握しておくべきです。

開発者にとって、このキャッシュの欠陥は一般的な教訓です。「承認済み」というキャッシュされた判断は、承認したデータそのものに厳密に結び付けておく必要があります。そうでないと、新しいデータが古いデータになりすまして通ってしまいます。

事件に便乗した詐欺

Bitgetは、資産の回収や出金の再開を名目に、送金やパスワード、秘密鍵、シードフレーズ、認証コードを求めることは決してないと注意を呼びかけています。顧客だけでなく、暗号資産を取引する従業員を抱える組織も、両事件を題材にした誘い文句を想定しておくべきです。

どのチームが確認するか

チーム 実務上の次の一手
EDR 運用しているすべてのセキュリティ製品のノードを洗い出す。エージェントを入れられる場合は、サービスのプロセスが起動したシェル、ダウンローダー、環境変数の読み出しを検知する。入れられない場合はログの外部出力を条件にする。
SIEM / SOC セキュリティ製品の管理画面へのサインイン、タスクの実行、設定変更を収集する。コマンドやスクリプトのタスク、初めてのユーザーとIPの組み合わせ、DBのサービスアカウントの新しいホストからの接続を検知する。
IT運用 サービスの秘密情報を環境変数から、短期間だけ有効な認証情報を発行するシークレットマネージャーに移す。DBへの接続を必要なホストだけに絞る。管理画面の使っていないリモート実行機能を無効にする。
委託先リスク セキュリティ製品のベンダーに、管理基盤をどう守っているか、自社のホストで何を実行できるか、どのログを出力できるかを確認する。利用している取引所やカストディアンには、ホットウォレットの上限と出金の独立した検証を確認する。
メールセキュリティ BitgetやLiquidの名前を使った「資産回収」「出金再開」の誘い文句を想定する。Bitgetは、パスワード、秘密鍵、シードフレーズ、認証コードを求めることはないとしている。

IOCとハンティング

Bitgetは、攻撃者が管理するアドレスを4つ公表しています。オンチェーンの指標なので、入出金を審査する取引所、決済事業者、コンプライアンス担当には役立ちますが、端末のハンティングには使えません。Bitgetはリアルタイムの追跡ダッシュボードも公開し、凍結・回収額の5%の報奨金を設けています。

チェーン 攻撃者が管理するアドレス(Bitgetが公表)
EVM 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
XRP Ledger rwNhefsz1UQEusxhCvHip3RANinWi4CTck
Zcash t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
TRON TBWNguTTgezw9dVorX441C6nDrZpRxYwKD

Bitgetも調査会社も、製品Aと製品Bの名称、脆弱性、ホスト上の指標は公表していません。推測で補うべきではありません。

役に立つのは、手口に対するハンティングです。いずれも例示で、実データでは実行していません。YOUR_ で始まる部分は自社の名前に置き換え、フィールド名はデータソースに合わせて調整してください。

Microsoft Defender for Endpoint が入っているセキュリティ製品のノードで、サービスのプロセスが起動したシェル、環境変数の読み出し、ダウンローダーを探します。

// 例示です。Microsoft Defender XDR の高度なハンティング、DeviceProcessEvents(Defender for Endpoint が入った Linux 端末)。
// 指定したホストで、常駐するサービスのプロセスが起動したシェル、環境変数の読み出し、ダウンローダーを一覧にします。
let ServiceHosts = dynamic(["YOUR_SECURITY_PRODUCT_NODE_1", "YOUR_SECURITY_PRODUCT_NODE_2"]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName in~ (ServiceHosts)
| where InitiatingProcessFileName in~ ("java", "node", "python", "python3", "php-fpm", "nginx", "httpd")
| where FileName in~ ("sh", "bash", "dash", "env", "printenv", "curl", "wget", "base64")
    or ProcessCommandLine has "/environ"
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName,
    InitiatingProcessCommandLine, FileName, ProcessCommandLine
| order by Timestamp asc

Microsoft Entra ID でサインインするセキュリティ製品の管理画面について、過去に見られなかったユーザーとIPアドレスの組み合わせを探します。

// 例示です。Microsoft Sentinel の SigninLogs。Entra ID でサインインするセキュリティ製品の管理画面が対象です。
// 直近7日間の成功したサインインのうち、その前の30日間に見られなかったユーザーとIPアドレスの組み合わせを一覧にします。
let Console = "YOUR_SECURITY_CONSOLE_APP";
let Known = SigninLogs
    | where TimeGenerated between (ago(37d) .. ago(7d))
    | where AppDisplayName == Console and ResultType == "0"
    | distinct UserPrincipalName, IPAddress;
SigninLogs
| where TimeGenerated > ago(7d)
| where AppDisplayName == Console and ResultType == "0"
| join kind=leftanti Known on UserPrincipalName, IPAddress
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AuthenticationRequirement
| order by TimeGenerated asc

Splunk に取り込んだDBの監査ログで、DBのサービスアカウントが想定外のホストから接続していないかを探します。想定する接続元はルックアップに登録しておきます。

index=YOUR_DB_AUDIT_INDEX user="YOUR_SERVICE_DB_USER" action=connect earliest=-30d latest=now
| stats count min(_time) AS first_seen max(_time) AS last_seen BY src
| lookup YOUR_EXPECTED_DB_SOURCES src OUTPUT expected
| where isnull(expected)
| convert ctime(first_seen) ctime(last_seen)
| sort first_seen

承認に対応しない出金のブロードキャストを探します。承認ログが、ウォレットのホストから書き込めないシステムのものである場合にだけ意味があります。

(index=YOUR_WALLET_INDEX sourcetype=YOUR_WALLET_BROADCAST) OR (index=YOUR_APPROVAL_INDEX sourcetype=YOUR_APPROVAL_LOG status=approved) earliest=-24h latest=now
| eval kind=if(sourcetype=="YOUR_WALLET_BROADCAST", "broadcast", "approved")
| stats values(kind) AS kinds min(_time) AS first_seen values(host) AS host values(asset) AS asset BY withdrawal_id
| where isnotnull(mvfind(kinds, "^broadcast$")) AND isnull(mvfind(kinds, "^approved$"))
| convert ctime(first_seen)
| sort first_seen

自社のLinuxホストで、秘密情報らしい環境変数を持つプロセスを調べます。表示するのは名前だけで、値は表示しません。

# 例示です。自社の Linux サービスホストで root として実行します。
# 秘密情報らしい環境変数の「名前」(値ではない)を、プロセスIDとプロセス名とともに表示します。
for f in /proc/[0-9]*/environ; do
  d=${f%/environ}
  names=$(tr '\0' '\n' < "$f" 2>/dev/null | cut -d= -f1 | grep -E 'PASS|SECRET|TOKEN|KEY' | sort -u | tr '\n' ' ')
  [ -n "$names" ] && echo "${d#/proc/} $(cat "$d/comm" 2>/dev/null): $names"
done

結果を読むときは、次の限界を踏まえてください。

  • ヘルスチェックや更新のために、通常の動作としてシェルを起動する製品もあります。検知の前にベースラインを作ってください。
  • 初めてのユーザーとIPの組み合わせは手がかりであって、証拠ではありません。Bitgetの攻撃者は実在の従業員のIDを使っていたため、本人に確認してください。
  • ホットウォレットからのオンチェーンの送金と、ウォレット自身のブロードキャストのログも突き合わせてください。どちらのログにもない送金が最悪のケースです。
  • ログを外部に出力しない、ベンダー管理のアプライアンスの中はどれも見えません。

未確認の点

  • 製品A、製品B、脆弱性。 名称は公表されていません。Bitgetは技術的な詳細を含む正式な報告書を公開するとしています。
  • 攻撃者がシステム間をどう移動したか。 製品Bで使われた従業員のIDをどう入手したかも含め、SlowMistが調査中です。
  • 検知と封じ込め。 SlowMistの記録では送金が約2時間52分続いています。この時間とBitgetの対応の関係は説明されていません。
  • 攻撃者。 Bitgetも調査会社も、攻撃者を特定していません。BitgetはBybitの「LazarusBounty」を資金回収の窓口の1つとして挙げていますが、これは攻撃者の特定ではありません。
  • 凍結・回収できた額。 Bitgetは金額を示さず、リアルタイムの追跡ダッシュボードを案内しています。
  • Liquid。 攻撃者が誰か、残る約600BTCが戻るかは不明です。
  • CertiKの調整額の内訳。 調整後の額を出すために何を差し引いたかは、ダッシュボードには示されていません。

編集メモ

公開情報の確認は 2026年10月3日 21:55(日本時間)/ 12:55(UTC) 時点です。四半期の数字は2026年10月3日時点のCertiKのダッシュボードに基づき、ダッシュボードの更新に伴って変わる可能性があります。この記事のきっかけは10月3日のNADA NEWSの記事で、同記事は10月2日更新時点の数字と1ドル=157.4円の換算を使っています。本文の円換算も同じレートです。Bitgetに関する事実は同社の公表ページとSlowMistの9月29日の中間報告に基づき、Mandiantの調査結果はGIGAZINEの記事を参照しました。Liquidに関する事実はTRM LabsとChainalysisに基づきます。DMM Bitcoinの事案は警察庁の注意喚起に基づきます。

これは公開情報に基づく独立した編集上の分析で、SecOpsNomadによる調査ではありません。また、投資に関する助言ではありません。

出典

記事一覧へ →Read in English ↗