弱い乱数で割れた「12/24語」の神話——“Ill Bloom”悪用で自己保管ウォレットから少なくとも310万ドル流出です

今日の深掘りポイント

• リカバリーフレーズの乱数生成（CSPRNG）に起因する構造的欠陥が、自己保管型ウォレットの根幹を揺らしている事案です。
• 影響は「古い／知名度の低い」ウォレットに偏在しやすく、ロングテールのユーザー資産が狙われやすい地合いです。
• 攻撃は「フレーズ空間の縮退」を前提に、候補リストを事前計算→常時監視→入金即スイープという産業化パターンが想定されます。
• 企業・組織の残高管理では「どのウォレットで“いつ”生成したシードか」を資産台帳に紐づけ、脆弱生成の可能性を棚卸すべき局面です。
• 即応は「照合→隔離→再生成→段階移管→モニタリング」の一筆書きオペレーションで、二次被害とフロントランを抑え込むことが肝心です。

はじめに

「12/24語を紙に書けば安心」——暗号資産ウォレットの通念は、十分な乱数が前提という“静かな約束”の上に成り立っています。今回の“Ill Bloom”は、その約束が破られたとき何が起きるかを教えてくれる事件です。問題は個々のユーザーに留まらず、長く放置された古いウォレット、内製スクリプトに埋め込まれた乱数の癖、そしてロングテールの資産に波及します。CISOやSOCマネージャーにとっては、暗号資産領域の「鍵生成」を、ゼロトラストの観点で再点検する好機でもあります。

深掘り詳細

事実整理（確認できていること）

• セキュリティ企業Coinspectが公表した“Ill Bloom”脆弱性を起点に、自己保管型ウォレットから少なくとも310万ドル相当が盗難されたと報じられています。乱数生成の弱さにより、リカバリーフレーズ（シード）を推測可能になったことが原因とされています。古い、または知名度の低いウォレット実装が影響を受けやすいとされています。
• 報道は、Coinspectが影響ウォレットの一覧と、ユーザーが自身のアドレスを照合できる仕組みを提供していると伝えています。ユーザーは該当すれば新規ウォレットへの移管が推奨されています。
• 一部報道では、2023年5月の攻撃で431ウォレットから約310万ドル、その後に約210万ドルの追加盗難が指摘されていますが、総額はソースごとに差異があり得るため、一次情報の確認が必要です。
• 出典（報道）：The Hacker News です。

注記：上記は報道に基づく整理です。Coinspectの一次資料や公開インジケータは、各自で直接確認することを強く推奨します。第三者サイトでリカバリーフレーズそのものを入力することは絶対に避けるべきです。

技術インサイト（なぜ起き、どこにボトルネックがあるのか）

• 乱数が縮むと「候補の事前計算」が可能になる、という構造的リスクです。BIP系ウォレットの多くは同等のフレーズ形式を採るため、実装が不適切だと「正しく見えるが実は狭いシード空間」を生成しがちです。典型的にはOSのCSPRNGを正しく呼んでいない、擬似乱数（例：Math.random相当）を混入、時刻・デバイスIDの偏りなどが原因になり得ます。
• 攻撃者は「脆弱実装で生成されうるフレーズ集合」を先に作り、対応するアドレス群を網羅して常時監視している可能性が高いです。入金が観測されるや否や、手数料上乗せの高速トランザクションで即時スイープする運用が自然体です。これは単発の偶発ではなく、「前処理（候補生成）」「監視」「即時移送」を分業化した産業化パイプラインとして成立しやすいです。
• ロングテール特有のリスクが顕在化しています。メジャーなハードウェアウォレットはCSPRNGや検証の厚みが比較的担保されやすい一方、年代物のモバイルウォレット、派生フォーク、個人開発の配布版などは、暗号強度よりUXを優先した実装逸脱が混入しがちです。企業の周辺でも「一度だけ使ったテスト用ウォレット」「キャンペーン配布」「業務委託先が作った内製クライアント」など、棚卸しが漏れやすい資産ポケットが危険域になります。
• 運用目線では、「シードをいつ・どこで・どの実装で・誰が生成したか」の不可逆ログを残していない組織が多く、移行判断が遅れやすいです。台帳と生成履歴のひも付けができないと、結局“全て移し替え”になりコストが跳ね上がります。ここはセキュリティだけでなく会計・監査のプロセス設計が効いてくる領域です。

脅威シナリオと影響

以下はMITRE ATT&CKのタクティクスに沿った仮説ベースのシナリオです。戦術・技法はブロックチェーン固有のドメインに完全一致しない部分もあるため、抽象度を上げて記述します。

• シナリオA：事前計算型スイープ

  • Reconnaissance：影響するウォレット実装・バージョンの収集、派生アドレスの導出規則（派生パス）を特定します。
  • Resource Development：脆弱実装の乱数分布を模倣し、推測可能なフレーズ候補と対応アドレスを大規模生成します。計算資源とストレージを準備します。
  • Credential Access：縮退したフレーズ空間から実用的に当たりを引く手法で、実質的に「シードの推測」を成立させます。
  • Collection/Command and Control：候補アドレス群をチェーン上で常時監視し、自動化されたボットで入金トリガーを検出します。
  • Exfiltration：入金直後に高い手数料を設定したトランザクションで一括スイープし、混合サービスやクロスチェーンブリッジを経由して追跡を困難化します。
  • Defense Evasion：アグリゲータアドレスの使い捨て、マルチホップ、少額分割などでヒートマップの可視性を下げます。
  • 影響：自己保管資産の即時喪失、会計上の損失計上、規制当局への報告義務、事業継続に影響する流動性低下が発生します。

• シナリオB：休眠トレジャリの狙い撃ち

  • Reconnaissance：公開台帳から長期未動作のアドレスを抽出し、過去のオンボーディング時期・派生規則から脆弱生成の可能性を推定します。
  • Persistence/Impact：資産が動くタイミング（資金調達、イベント、清算）を外形情報から推測し、動いた瞬間にスイープします。企業のキャッシュフローに直撃する可能性が高いです。

• シナリオC：内製ツール由来の二次被害

  • Development/Execution：社内スクリプトやエアドロップ請求ツールが不適切な乱数を用いてキーを生成しており、少額資産やNFT保管領域がごっそり抜かれるケースです。SASTやライブラリ選定のレビュー不足が原因になりやすいです。

組織への影響は、単なる個人被害の集合ではありません。財務上は損失計上と内部統制の見直し、規制面では消費者保護や不正流出時の説明責任、事業面ではサプライヤやコミュニティに対するトラスト毀損が累積します。とりわけ「自己保管」を方針として掲げるチームは、鍵生成プロセスの検証可能性を外部に示せる体制づくりが不可欠です。

セキュリティ担当者のアクション

• いま直ちに（24–72時間）

  • 影響調査の着手です。資産台帳に「ウォレット名／バージョン／生成日／生成環境（端末・OS）／生成者」を追記できるか確認します。古い・知名度が低い実装で生成した可能性があるアドレスをマークします。
  • 報道で案内されている照合手段（例：illbloom.org等）を参照しつつ、必ず“アドレスのみ”で確認します。リカバリーフレーズや秘密鍵を第三者サイトに入力しないよう徹底します。
  • 該当の疑いがある場合は、信頼できる最新のハードウェアウォレット等で新規フレーズを生成し、段階的に資産を移します。移管時は少額トランザクションでルートの健全性を検査し、スイープを誘発しないようガス設定やタイミングを調整します。
  • On-chain監視を強化します。自組織アドレスからの“予期しない一括送金”“新規先アドレスへの高速スイープ”“混合サービス／ブリッジ直行”を検知するルールを追加し、メンテナに24/7アラートを配信します。

• 近々（1–4週間）

  • 生成プロセスの標準化です。鍵生成はOSのCSPRNGを正しく利用する実装に限定し、可能ならFIPS適合のDRBGを採用します。レビューチェックリストに「乱数源の検証」「外部監査の有無」「再現ビルドの可否」を追加します。
  • 内製コードのSASTルールに「非暗号学的乱数APIの使用禁止」を導入し、CIでブロックします。脆弱な派生フォークの取り込みを防ぐため、暗号ライブラリのサプライチェーン管理を強化します。
  • 鍵管理方針を更新します。24語の新規生成を既定とし、シード分散（Shamir Secret Sharing）やマルチシグ／MPCウォレットの導入を検討します。ウォレット生成時は“生成式典”（複数人立会い・紙とデバイス双方の乱数投入・監査ログ保存）を定型化します。
  • ベンダ管理を見直します。カストディ／ウォレットベンダに対し、乱数設計のホワイトペーパー、外部監査報告、インシデント対応SLAの提示を求め、調達要件に組み込みます。

• 中長期（四半期〜）

  • 監査可能性を高めます。どの資産がどの生成系譜から生まれたかを追跡できる「キー・プロビナンス」の台帳化を進めます。将来のゼロデイ報道でも、対象範囲を即座に切り出せる体制を作ります。
  • 事業継続計画（BCP）に「ブロックチェーン資産の迅速なローテーション」手順を明文化します。テーブルトップ演習では“入金直後のスイープ”という最悪シナリオを採り、MTTD/MTTRの改善を測ります。
  • 教育とガバナンスです。個人デバイスでのウォレット生成を禁止し、承認済み手順とツールに限定します。報奨や経費精算で暗号資産を扱う部門にも、同じ統制を適用します。

最後に、スコアリングににじむ「即応の必要性」「現場での実行可能性の高さ」を、運用の意思決定に直結させることが大切です。技術の問題に見えて、じつは「プロセス」と「可視化」の勝負です。乱数は目に見えませんが、生成の履歴と責任の所在は見える化できます。今日の一手が、明日の資産を守る最短距離になります。

参考情報

• 報道まとめ：The Hacker News「Attackers Exploit ‘Ill Bloom’ Vulnerability to Steal Over $3.1 Million from Crypto Wallets」(2026-07-10) https://thehackernews.com/2026/07/attackers-exploit-ill-bloom.html

注記：一次情報（Coinspectの公表資料、影響アドレス照合サイト等）は、必ず公式チャネルで直接確認してください。第三者サイトにシードや秘密鍵を入力しないでください。