あなたの決済システムは資金を動かすために存在しています — だからこそ、ホットウォレット、署名フロー、管理者権限は攻撃者の直接的な標的となります。以下の事例が示すように、攻撃対象はスマートコントラクトのバグを超え、署名インフラ、鍵、そしてそれらを運用する人々へと移行しています。
これが2025年における暗号資産の決済関連インシデントのうち、最大規模の3件に共通するパターンです。私たちは各攻撃チェーンを詳細に分析しており、それぞれが異なる攻撃経路に対応しています:署名インフラへのサプライチェーン攻撃、管理者鍵の漏洩、そしてソーシャルエンジニアリングによる運用スタッフへの攻撃です。以下では、各ケースで何が起きたのか、暗号資産決済ハックが今後どこへ向かうかについて詳述し、さらにそれらの決済が動作するコントラクト層の一段深いところまで踏み込みます — スマートコントラクトが実際に決済システムのどこに登場するか、2大ステーブルコインが資金の凍結・発行権限においてどう異なるか、そして自己デプロイの決済コントラクトが稼働前後に何を必要とするかについて解説します。
Bybit、15億ドル:署名ツールが攻撃対象になったとき
2025年2月、Bybitは暗号資産史上最大の単一セキュリティインシデントに見舞われ、約15億ドル(ETH 401,347枚)を失いました。
攻撃者はBybit自身のコントラクトのバグを一切悪用しませんでした — 彼らは署名者が信頼していたサードパーティのSafe{Wallet}インターフェースを侵害しました。攻撃者はBybitが使用していたサードパーティのマルチシグ管理ツールSafe{Wallet}のフロントエンドコードに悪意のあるJavaScriptを注入しました。Bybitの署名者がSafe{Wallet}のウェブインターフェース上で通常の「内部送金」に見えるものを確認して署名したとき、実際にはマルチシグコントラクトのプロキシスロット0を攻撃者が制御する実装コントラクトに置き換えるdelegatecall操作に署名していたのです。署名が完了すると、攻撃者は数分以内にウォレット全体を空にしました。
これが成立するためには、4つのことが同時に失敗する必要がありました:
- エンドポイントセキュリティ — 署名者のウェブUIはサードパーティから提供されており、独立した検証がありませんでした。
- トランザクション検証 — ブラインド署名により、署名者は画面上で通常の送金とdelegatecallを区別できませんでした。
- コントラクト設計 — プロキシアップグレード権限にタイムロック保護がありませんでした。
- 運用上の分離 — 署名環境が日常のオフィス環境から物理的に分離されていませんでした。
最後の点は深く考える価値があります:複数のセーフガードが同時に失敗したとき — エンドポイントセキュリティ、トランザクション検証、コントラクト設計、運用上の分離 — 潤沢なリソースを持つ取引所でさえ15億ドルを失う可能性があります。署名環境自体の強化についてより詳しくは、鍵管理と署名インフラをご覧ください。
UPCX、7,000万ドル:管理者鍵1つの漏洩で完全掌握
2025年、決済プロトコルのUPCXは管理者秘密鍵の漏洩により約7,000万ドルを失いました。
ここでは攻撃者は誰かをだまして何かに署名させる必要がありませんでした。ProxyAdminの秘密鍵を入手し、コントラクトアップグレード機能を使って実装コントラクトを悪意のあるバージョンに差し替え、withdrawByAdminを呼び出してすべての資金を流出させたのです。
教訓は明快です:鍵の漏洩にコントラクトアップグレード権限が加わると完全掌握につながります。だからこそProxyAdmin鍵の管理にはMPCまたはマルチシグを使用しなければならず — 単一の保有者は絶対に避けるべきです — コントラクトのアップグレードにはタイムロック(例:48時間の遅延)が必要で、アップグレードが有効になる前に異常を検知できる時間的余裕をチームに与えます。この種の鍵管理の設計については、本シリーズの別の記事でより詳しく解説しています。
MoonPay、25万ドル:攻撃者がコードを完全にスキップしたとき
すべての暗号資産決済ハックがコントラクトや鍵システムに触れるわけではありません。2025年の米国司法省の没収申立書によると、暗号資産決済企業MoonPayのCEOとCFOは、1通のメールによって約25万ドルのUSDTをフィッシング詐欺で失いました。
攻撃者は著名人になりすまし、タイポスクワッティングを使って送信者アドレスを偽装しました — サンセリフフォントではほぼ見分けがつかない、大文字の「I」を小文字の「l」に置き換えることで — MoonPayの幹部を攻撃者が制御するアドレスへのUSDT送金に誘導しました。ここには技術的な脆弱性は一切なく、鍵システムにも触れていません。純粋なソーシャルエンジニアリングでした。
Tetherはその後、盗まれた資金のうち約4万ドルを凍結しましたが、残りは海外に送金されてDOJが追跡することになりました。
いくつかの点が際立っています:
- ソーシャルエンジニアリングは差別をしません — トップクラスの決済企業の技術に精通した幹部でも引っかかる可能性があります。
- 送金前には常に受取人アドレスをメールに表示されたアドレスだけに頼らず、独立した手段で確認してください。アドレス確認、ホワイトリスト、大額送金に対するクーリングオフ期間を組み合わせましょう。
- ステーブルコインの凍結能力は事後に損失の一部回復に役立ちましたが、回収できたのはほんの一部でした。事後の凍結よりも予防が重要です。
パターン:3つの攻撃経路、1つの教訓
この3つのケースを並べると、パターンが浮かび上がります — それぞれ異なる失敗ポイントですが、それぞれに明確な防御策があります:
| 攻撃パターン | ケース | 標的 | 主要な防御策 |
|---|---|---|---|
| サプライチェーン攻撃 | Bybit | 署名ツール / フロントエンド | 独立した検証 + 署名環境の分離 |
| 鍵の漏洩 | UPCX | 管理者秘密鍵 | MPC/マルチシグ + タイムロック |
| ソーシャルエンジニアリング | MoonPay | 運用スタッフ / 幹部 | アドレス確認 + ホワイトリスト + セキュリティ意識向上トレーニング |
攻撃対象は移行しています:もはやスマートコントラクトのバグだけではなく、署名インフラ、管理者鍵、そしてその周囲の運用スタッフが標的となっています。暗号資産決済システムを担当している場合、実践的な教訓は3つすべてを守ることです — 署名ツール、管理者鍵、運用スタッフ — それぞれを独自のコントロールを持つ独立した攻撃対象として扱いましょう。
とはいえ、コントラクトの権限はこの3ケースのうち2件に関与していました — タイムロックのないプロキシアップグレードはBybitの4つの失敗のうちの1つであり、UPCXのProxyAdmin鍵は攻撃の全体でした。したがって、一段深く掘り下げる価値があります:決済システムのコントラクト層が実際に何で構成されているか、そして何が必要かについて。
スマートコントラクトが実際に決済のどこに登場するか
暗号資産決済製品を構築している場合、スマートコントラクトのセキュリティとはDeFiレベルの複雑さを意味すると思いがちです:十数のプロトコルが相互作用し、複雑な経済的前提が絡み合い、守るべき巨大な攻撃対象があると。しかし、それが通常の決済企業の立ち位置ではありません。DeFiと比較すると、複雑な経済モデルのもとで十数のコントラクトが相互作用するシナリオと異なり、決済コントラクトのロジックは通常はるかに直接的です。複雑さの低いものから高いものへ、用途は4つの場所に集中します。
ステーブルコインコントラクト、ほぼすべての企業が使用。 USDCとUSDTはそれ自体がスマートコントラクトであり、mint、burn、blacklist、pauseなどの管理者機能を持っています。あなたはこれらのコントラクトのデプロイヤーではなくユーザーですが、それでも許可モデルと凍結機能を理解する必要があり、これについては次のセクションで説明します。
コントラクトマルチシグとアカウント抽象化、ウォレットとガバナンス層。 Safeのようなコントラクトマルチシグは資金とコントラクト権限を管理し、ウォレット層の中核に位置します。アカウント抽象化(ERC-4337)も決済シナリオへの参入を始めており、ガスレス決済(ペイマスターがガスを負担することでユーザーはネイティブトークンを保有する必要がない)、企業向け支出制限、セッション鍵を可能にしています。
自動分配、条件付きリリース、クロスチェーン決済 — 現在急速に拡大しているカテゴリ。 これこそ「プログラマブルマネー」がその名に値する領域です。CoinbaseとShopifyのCommerce Payments Protocolはオンチェーンでリアルタイムに受取金を分配します:キャプチャ時に、コントラクトはアトミックに手数料をfeeReceiverに、残りをマーチャントに振り向け、単一の承認を異なるレートで異なる受取人への複数のキャプチャに分割できます — 例えば、1,000 USDCを2回に分けてキャプチャし、異なる受取人に手数料を支払い、残りをマーチャントに決済するなど。同プロトコルはカードネットワークでおなじみの承認/キャプチャフローをオンチェーンに持ち込みます:バイヤーが承認した後にエスクローコントラクトが資金を保持し、マーチャントが後でキャプチャまたは返金できます。決済側では、CircleのCCTPがクロスチェーンUSDC転送にネイティブなバーンアンドミントを使用し、到着時にフォローオンコントラクトアクションをトリガーでき、クロスチェーンの移動と自動決済を連鎖させます。
自動利回りとトレジャリー管理 — まだ初期段階。 これは遊休準備金を低リスクのDeFiプロトコルに入れて利回りを得ること、またはコントラクトでトレジャリーの移動を自動化することを意味します。ほとんどの決済企業はこれを本格採用しておらず、それには理由があります:外部プロトコルへの依存関係が生じ、攻撃対象が広がります。
今日のほとんどの決済企業は最初の2つのカテゴリにとどまっており、3番目はちょうど拡大し始めており、4番目はまだ初期段階です。使用が単純であるほど攻撃対象は小さくなります — 「プログラマブル」であるためではなく、ビジネスが必要とする場合にのみコントラクトの複雑さを追加しましょう。
あなたが扱うすべてのステーブルコインの背後にある許可モデル
ステーブルコインのユーザーとして、コントラクト自体に組み込まれた許可設計を理解する必要があります。2大ステーブルコインは正反対のアプローチを取っています。
USDC(Circle) は権限分離モデルを使用しています:masterMinterがミンターの許容量を管理し、pauserがコントラクトを一時停止でき、blacklisterがブラックリストを管理し、ownerがロールの割り当てを管理します。各ロールは独立しており、権限の重複はありません(Circle stablecoin-evmのコントラクトソースを参照)。
USDT(Tether) は単一オーナーモデルを使用しています:1つのオーナーアドレスがすべての権限を一度に保持します — ミント、一時停止、addBlackList。設計はよりシンプルですが、より集中化されています。
どちらのモデルが厳密に優れているというわけではありません — それぞれ異なるトレードオフがあります。USDCの権限分離はより安全ですが運用が複雑であり、USDTの集中モデルは効率的ですが単一オーナーアドレスのセキュリティにより大きく依存しています。この違いは単なる学術的な問題ではありません:ステーブルコイン発行者があなたの資金に対して行動する必要が生じた場合の凍結リスクに直接影響します。
Web3最優秀セキュリティ監査人
ローンチ前に設計、コード、ビジネスロジックを検証します
自分でビルドするコントラクトのセキュリティ確保
独自の受取、決済、分配、またはエスクローコントラクトをデプロイする場合、デプロイ前に専門的な決済コントラクト監査と、組み込まれたセキュリティメカニズムのセットが必要です。
デプロイ前に、独立したサードパーティのセキュリティ企業による監査に加え、自動静的・動的スキャンを実施してください。レビューが権限管理、資金フロー、リエントランシー、分配比率のオーバーフローを具体的にカバーしていることを確認してください — 汎用的なコントラクトバグだけでなく、決済固有のリスクをカバーすることが重要です。
実行時には、4つのメカニズムが適用されます:
- タイムロック — コントラクトのアップグレードとパラメータ変更に遅延(例:48時間)を設け、有効になる前に問題を検知できる時間的余裕をチームとコミュニティに与えます。
- サーキットブレーカー — 異常が検知された瞬間にコントラクトの操作を自動的に一時停止します。
- ロール分離 — デプロイヤー、アップグレーダー、ポーザー、管理者はそれぞれ異なる鍵を使用し、単一の認証情報がすべてを制御しないようにします。
- アップグレード可能プロキシパターン — 透明プロキシまたはUUPS、アップグレードはタイムロックとマルチシグで保護します。
デプロイ後に、開発者の昇格された権限をすぐに取り消すことが内部者の脅威に対する中心的な対策であり、上記のUPCXインシデントからの直接の教訓です:管理者とオーナーの権限をマルチシグコントラクトに移転し、ProxyAdmin鍵をマルチシグとタイムロックで保護し、残存する開発者権限がないことを確認するためにコントラクトの権限状態を定期的にレビューし、すべてのオンチェーン権限変更がモニタリングと監査のためのイベントログを発行することを確認してください。
これらのいずれも監査自体の代替にはなりません — これらは、クリーンな監査がローンチ後に監視されず過剰な権限を持つコントラクトに劣化しないために必要なものです。
4つの対象を守り、4番目をできる限り小さく保つ
2025年のインシデントが露わにした対象のうち3つは運用上のものです:署名ツール、管理者鍵、運用スタッフ。4番目はコントラクト層であり、そこでの目標は異なります — DeFiの複雑さに合わせることではなく、実際の使用に合わせることです:触れるステーブルコインの許可モデルを理解し、ビジネスが許す限り自分のコントラクトをシンプルに保ち、監査をゴールラインではなく継続的な権限衛生管理の初日として扱いましょう。
これらの各対象がシステム全体のどこに位置するかについては、6層の決済アーキテクチャの解説をご覧ください。これらのコントロールがどのように組み合わさるかの完全な解説については、完全なプレイブック(PDF)をダウンロードしてください。メンプールの段階で攻撃トランザクションを自動的にブロックできるリアルタイムモニタリングについては、オンチェーンセキュリティモニタリングをご覧ください。
FAQ
2025年における最大の暗号資産決済ハックは何でしたか? 2025年2月のBybitで、約15億ドル(ETH 401,347枚)を失いました。攻撃者はサードパーティのマルチシグツールSafe{Wallet}のフロントエンドコードを侵害し、署名者を悪意のあるdelegatecallの承認に誘導しました。
UPCXハックはどのように発生しましたか?
攻撃者はUPCXのProxyAdmin秘密鍵を入手し、コントラクトアップグレード機能を使って悪意のある実装コントラクトに差し替え、withdrawByAdminを呼び出して約7,000万ドルの資金を流出させました。
MoonPayのインシデントはスマートコントラクトのエクスプロイトでしたか? いいえ。CEOとCFOが約25万ドルのUSDTをフィッシング詐欺で失ったMoonPayのインシデントに技術的な脆弱性は関与していませんでした。偽装されたタイポスクワッティングの送信者アドレスを使った純粋なソーシャルエンジニアリングでした。
Bybit、UPCX、MoonPayに共通することは何ですか? 各攻撃は決済システムの異なる層を標的にしていました — 署名ツール、管理者鍵、運用スタッフ — これは最大の脅威がスマートコントラクトのバグから署名インフラ、鍵、運用へと移行していることを示しています。
USDCとUSDTの許可モデルの違いは何ですか?
USDC(Circle)は権限分離モデルを使用しており、独立したmasterMinter、pauser、blacklister、ownerロールがあります。USDT(Tether)は単一オーナーモデルを使用しており、1つのアドレスがすべての権限 — ミント、一時停止、addBlackList — を同時に保持します。
自己デプロイの決済コントラクトにはどのようなセキュリティメカニズムが必要ですか? デプロイ前:権限管理、資金フロー、リエントランシー、分配比率のオーバーフローに焦点を当てたレビューを含む、独立したサードパーティ監査と自動スキャン。実行時:アップグレードのタイムロック、サーキットブレーカー、鍵をまたいだロール分離、タイムロックとマルチシグで保護されたアップグレード可能プロキシパターン。
デプロイ後に開発者権限を取り消すことがなぜそれほど重要なのですか? これは内部者の脅威に対する中心的な対策であり、UPCXケースからの直接の教訓です。管理者とオーナーの権限をマルチシグコントラクトに移転し、残存する開発者権限がないことを確認するために権限状態を定期的にレビューすることで、そのギャップを埋めることができます。



