OmakaseテックブログPublicationへの投稿
💵

米政府押収の暗号資産約60億円に流出疑惑 - 過去の監査で「スプレッドシート」管理を指摘

kiyo
に公開
idea

1. 委託先のCEO息子に疑惑

「Lick」の別名で知られる John Daghita 氏が米政府の押収暗号資産アドレスから複数回にわたって約 4,000 万ドル超相当を盗んだと指摘されています。

この疑惑は、Telegram 上で John 氏が別のハッカーと資産を誇示しあう口論の中でウォレットを公開し、約 2,300 万ドル相当の暗号資産を保有していることを明かしたことがきっかけでした。この様子が録画されており、その後オンチェーン調査員 ZachXBT 氏がオンチェーン分析を通じて資金の出所を追跡したという経緯です。

John 氏の父親は、米連邦保安官局（USMS）から押収暗号資産の管理・処分業務を受託する Command Services & Support（CMDSS）社の最高経営責任者で、父親経由でアクセス権限を取得したのではないかと推測されています。
なお、この指摘の後、CMDSS 社は SNS アカウント、ウェブサイトなどの公式アカウントを閉鎖しており、米当局は捜査を開始しました。

複数回にわたる盗難があったにも関わらず、なぜ米政府は二度目以降の流出を防止できなかったのでしょうか。

ウォレットの秘密鍵の管理が不十分だったことは言うまでもないのですが、過去の監査で指摘されていた USMS の押収暗号資産管理の統制不備に注目して深堀していきます。

サムネイル

2. USMS の管理が"統制として弱い"と監査で指摘されていた

「米政府（USMS 側）の押収暗号資産管理が強固だった」とは言いにくい材料が、監査報告として公開されています。

米司法省監察総監室（DOJ OIG）の監査は、USMS が押収暗号資産の管理・追跡において、DOJ 公式の資産追跡システム（CATS）では日常運用に必要な機能が足りず、補助的にスプレッドシートを複数運用していたと書いています。さらに、そのスプレッドシート運用について、編集履歴を追えない／詳細な運用手順がない／CATS との定期照合要件がないといった統制不備を明確に指摘しています。

3. なぜ「スプレッドシート管理」が致命的なのか

ここで勘違いが起きがちですが、論点は「秘密鍵の保管（カストディ）」だけではありません。
鍵が強くても、台帳（インベントリ）が弱いと破綻します。

DOJ OIG が問題視したのはまさにここで、USMS が使っていたスプレッドシートは、以下のような問題がありました。

  • 編集履歴を追跡できない（改ざん・削除が検知しづらい）
  • 運用を"公式在庫"として扱うための詳細ガイドラインがない
  • CATS との定期照合が必須になっていない

監査観点で見ると、"事故が起きて当然"の条件が揃っています。

台帳がスプレッドシートなら、誰かが行を削除したり数値を書き換えたりしても、その痕跡（監査ログ）が残りません。

実際、監査報告によると、スプレッドシート側にある押収暗号資産の記録のうち、CATS 側に存在しないものを 28 件特定し、その差分の一部は「追跡ミス」と整理されています。

4. 委託先ガバナンスの構造的欠陥

米政府は、押収資産の処分や管理を民間企業（CMDSS や Coinbase Prime 等）に委託しており、ここには「委託したつもり」が生む致命的な死角が存在します。

4.1 CMDSS は「Class 2–4（流動性が低い／マイナー側）」を担う契約だった

米会計検査院（GAO）の決定文書によると、USMS は Class 2–4 cryptocurrencies の管理・処分支援のための RFP を 2024 年 4 月に出し、CMDSS へ契約を発注しています。移管されるポートフォリオの市場価値は 7,710 万ドルと記載されています。

この調達は抗議を受けたものの、調達評価が不合理とは言えない、という結論から GAO は最終的に抗議を退けています。

また同文書上、評価観点として SOC 2 Type II や保険などが出てきます。つまり「書類上はセキュリティを見ていない」わけではないということです。

4.2 Coinbase Prime は「Class 1（大口・大手側）」で契約

一方、USMS が「Class 1（large cap）」を Coinbase Prime に委ねる動きも公開情報で確認できます。Blockworks は、この契約が数千万ドル規模ということを報じ、Coinbase ブログも USMS との契約を公表しています。

4.3 ガバナンスの課題

公開情報から読み取れるのは、マルチベンダー体制特有の「ガバナンスの希薄化」です。

責任境界の分断: 資産の種別（Class）ごとに委託先が分かれると、「台帳の正本（マスターデータ）」を誰が持つかが曖昧になります。どれが正本なのかが曖昧なままだと、事故時に確認作業が"電話リレー"になり、初動が遅れます。

ブラックボックス化する運用権限: 公開情報の範囲では、発注側が「委託先の承認フロー（誰が・何で・どの条件なら送金を確定できるか）」をどこまで可視化・監査できているかは確認できません。ここが不透明なままだと、事故時に"何が起きたか"の切り分けが遅れます。

5. 企業がカストディサービス選定で気を付けるべき「3つの原則」

企業が暗号資産の保有や取り扱いを行う際、法人向けカストディサービスを利用することで統制部分を強化できます。
しかし、ベンダー任せにするのではなく、発注側として以下の項目を「必須要件」として提示すべきです。

5.1 台帳は「書き換えられないシステム」かどうか

誰でも修正・削除が可能な Excel やスプレッドシートを正本にする運用は論外です。
選定するサービスが、いつ・誰が・何を更新したかという「監査ログ」が自動で残り、編集履歴が消せない（WORM 保管等で改ざん耐性がある）監査ログ設計を持っているかは、契約前の最重要確認項目です。
また、台帳上の数字とブロックチェーン上の実残高が常に一致している状態を、システム側で自動担保（常時突合、もしくは定期突合 + 差分アラート）しているかも確認すべきでしょう。

5.2 権限は「分散」され、単独実行が不可能か

社内か委託先かに関わらず、「一人の担当者」「1 つの端末」だけで送金が完結する設計は致命的です。
「起案」と「承認」を別人にするのはもちろん、承認端末を物理的に分ける（コールドウォレットや専用デバイスの活用）など、複数人の合意と複数の環境が揃わない限り、単独で送金が完結しない構造を提供できるベンダーを選定してください。

5.3 利便性を捨て、「時間」を味方につけられるか

即時送金の利便性は、ハッカーにとっても好都合です。
「指定アドレス以外は送れない（ホワイトリスト）」機能や、「送金指示から実行まで数時間待機させる（タイムロック）」といったあえて不便にする制約を実装できるか確認してください。万が一の際に攻撃を検知し、キャンセルできる「猶予時間」を確保できるかは、最後の防衛線となります。

6. まとめ：今回の事件の本質は「ハックの巧妙さ」ではなく「統制の弱さ」

今回の「約 4,000 万ドル流出疑惑」は、現時点ではオンチェーン調査起点の疑惑なので、当局の確定情報だけで断定できる範囲は限られます。
しかし、USMS の監査が示しているのは、ハッキング以前の明白な事実です。

  1. 公式システムが追いつかず、補助台帳（スプレッドシート）に依存した
  2. その台帳が編集履歴なし／照合なしで、記録の不整合も起きていた
  3. さらに委託が増えるほど、責任境界が割れやすい（CMDSS や Coinbase 等、役割が分かれる）

この構造のまま資産規模が増えれば、事故は「いつか起きる」ではなく「起きる前提」で備えるべき話になります。

「鍵」を守る体制が重要なのはもちろんですが、「台帳」と「権限」の重要性を再認識させられる事件でした。

主要参照ソース

GitHubで編集を提案
Omakaseテックブログ
OmakaseテックブログPublication

Omakaseは、SOC2 Type II認証およびISO 27001認証を取得した、日本国内のバリデータ運用事業者です。 2018年よりノード・バリデータ運営を経験しているインフラエンジニアと共に、国内最多数の対応チェーン数(2025年4月時点)を実現しています。

Discussion