過去2週間(2026/09/21 - 2026/10/04)において、8件のブロックチェーンセキュリティインシデントが発生し、推定損失総額は約4億1,840万ドルに達しました。
| 日付 | インシデント | 種類 | 推定損失 |
|---|---|---|---|
| 2026/09/23 | Meter Passport | ブロック検証の欠陥 | ~230万ドル |
| 2026/09/24 | Payy Network | 証明システムの健全性に関する欠陥の疑い | ~190万ドル |
| 2026/09/24 | Limit Break | 不適切なCalldata検証 | ~770万ドル |
| 2026/09/24 | Duelbits | 根本原因は非公開 | ~700万ドル |
| 2026/09/24 | Bitget | サードパーティセキュリティ製品の脆弱性 | ~3億8,750万ドル |
| 2026/09/27 | DYORSwap | ネットワーク構成検証の不備 | ~210万ドル |
| 2026/09/30 | NEAR Intents | 不適切な返金検証とロールバックの欠落 | ~390万ドル |
| 2026/10/04 | 名称非公開のBase Vault | 不適切なアクセス制御 | ~600万ドル |
選定理由
- Bitget: このインシデントは当該期間の損失の大部分を占めており、偽造された送金指示によるオフチェーンでの侵害が、正当なオンチェーン送金につながった経緯を追跡できるものです。秘密鍵やスマートコントラクトの侵害は確認されていません。
- NEAR Intents: 返金検証の欠陥とステートロールバックの欠落により、失敗したクロスチェーンデポジットの解決処理が、通常の送金パスを通過しうる裏付けのない内部残高へと変化しました。
Best Security Auditor for Web3
Validate design, code, and business logic before launch
Bitget
9月24日、約3億8,750万ドルがBitgetのホットウォレットおよびウォームウォレットインフラの一部から、Ethereumおよびその他のEVMネットワーク、XRP Ledger、Zcash、TRONを通じて流出しました。オンチェーン上の取引には有効なウォレット署名が付与されていました。Bitgetによると、攻撃者はサードパーティセキュリティ製品の脆弱性を悪用して社内ネットワークへのアクセス認証情報を取得し、送金指示を偽造したとのことです。一方、秘密鍵およびコールドウォレットは安全な状態が保たれていました[1][2]。
インシデントの概要
独立した調査報告書により、攻撃経路の詳細が明らかになっていますが、影響を受けた2つのセキュリティ製品の名称は明示されていません。SlowMistは、製品Aにおける最も早い不正活動を8月31日まで遡って特定し、あるノード上のサービスに影響を与えるゼロデイを確認しました。Mandiantは、2つのセキュリティアプライアンスへの特権アクセス、製品B上のWebシェルおよびC2(コマンド&コントロール)接続、そして本番ウォレットジョブサーバーへの横展開を発見しました。
SlowMistは別途、攻撃者が内部従業員のIDを使用して製品Bの管理プラットフォームにアクセスしたことを発見しました。調査員はまた、リスク管理パラメータを偽造し、送金リクエストを構築し、送金プロセスを呼び出すカスタマイズされた送金ツールを回収しました。攻撃者が関連するすべてのシステム間をどのように移動したかについては、調査が続けられています。パブリックチェーンに記録されたのは最終的に署名された送金のみであり、これらの上流の操作は記録されていません。
オンチェーン記録によると、最初の資金移動はUTC18:31に行われた93 TRXと、その11秒後の0.84 ETHでした。Bitgetの現在のタイムラインでは、照合による検知がUTC19:05に、そして最高レベルの緊急対応の起動がUTC19:14に記録されています[1]。別の2,059万TRXの送金が攻撃者が管理するTRONアドレスに到達したのはUTC19:16で、Chen氏は他の8つのネットワークにわたる17件のより大規模な送金について、総額約3億6,100万ドルに及んだと説明しています[3]。被害の抑制はUTC19:40に開始され、ウォレットの送金・署名サービスはUTC21:44に停止されました[1]。
資金の状況とコミュニティの対応
9月29日UTC16:35:28時点で、Bitgetの公式資金追跡ツールによると、攻撃者が現在保有する資金は3億2,267万ドル、凍結済みの資金は約63万2,700ドル、発行者により凍結可能なステーブルコインが31万2,500ドル、移動中または分析中の資金が5,587万ドルと報告されています。別のアドレス表示では、残高はBTC(2億8,851万ドル)、ZEC(2,891万ドル)、ETH(717万ドル)に集中していることが示されていますが、この表示は概要とは異なる分類範囲を使用しています。
Binanceは情報を共有し、資金追跡を支援しました。一方、BybitはLazarusBountyを更新し、支援を申し出ました[4][5]。インフラプロバイダーはそれぞれ異なる対応を取りました。Bitgetは、既知の盗難資金の流通を分散化によって保護すべきではないと主張し、THORChainに対して、リストに掲載された攻撃者のアドレスへのサービス提供を拒否するよう要請しました[6]。THORChainは選択的なブラックリスト化を拒否し、同社の管理機構は単一のアドレスや取引ではなく、より広範な活動またはチェーンルート全体を停止できるのみであると述べました[7]。
NEAR Intentsは、重複をフィルタリングした後、SHIELDが攻撃者に関連する試行フローとして5,000万ドル以上を特定・ブロックしたと報告しています。実行中に約50万3,000ドルが凍結され、約16万6,000ドルが通過しました。なお、この5,000万ドルという数字は試行されたフローであり、凍結または回収された金額ではありません[8]。追跡ツールは後に、NEAR Intentsにおける凍結分を29万3,507ドルと分類しましたが、公開情報ではこの差異について明確な説明はなされていません。
教訓
- 攻撃者はサードパーティセキュリティ製品を通じて侵入し、ウォレットジョブサーバーに到達し、偽造した送金リクエストを有効な署名付きトランザクションに変換しました。そのような到達範囲を持つサードパーティ製品は、実質的な資産セキュリティの境界に含まれます。各機関はこれを分離し、ID・権限を制限し、動作を監視し、署名前に送金意図を独立して検証する必要があります。
- 復旧権限は取引所、ステーブルコイン発行者、ルーティングサービス、ベースプロトコルの間に分散していたため、単独で対応を管理できる当事者は存在しませんでした。被害を受けた機関は検証済みのアドレスおよびトランザクションデータを迅速に共有する必要があり、一方でインフラプロバイダーおよびセキュリティチームは、それぞれの技術的・ガバナンス上の制約の範囲内で、追跡、凍結、トランザクションスクリーニング、復旧を調整する必要があります。
- 本インシデントから導かれた予防的対策については、Bitget's $387.5M Off-Chain Breach: Beyond Keys and Contractsを参照してください。本記事では、特権アクセス、送金意図、資産フロー監視、緊急対応に関する多層防御フレームワークを展開しています。
NEAR Intents
9月30日から10月1日の間に、NEAR Intentsは約387万ドルを失いました。これは、intents.nearにおける返金検証の欠陥とステートロールバックの欠落により、対応する資産の裏付けを持たない内部残高が生成されたことが原因です。攻撃者はこの残高を利用して有効なHOT MPC送金署名を取得し、プロトコルのBNB Chainボルトから実際のUSDTを流出させました[9][10]。
背景
NEAR IntentsはNEAR上で動作するインテント実行システムです。そのコアコントラクトであるintents.nearは、オムニアセットを保持し、ユーザーの内部残高を記録し、署名されたインテントに基づいて資産の交換および送金を処理します。
クロスチェーンデポジットの場合、ソースチェーン上のボルトが実際の資産をロックします。Omniは対応するオムニアセットをNEAR上で生成し、それをintents.nearに転送します。intents.nearはユーザーの内部残高にこれを反映します。
送金の場合、intents.nearはOmniに対して対応するオムニアセットのバーンと送金記録の作成を要求します。HOT MPCはその記録を検証し、署名を発行します。送金先チェーンのボルトは、実際の資産を解放する前に署名を検証します。このプロセスでは、intents.nearが記録する内部残高が、コントラクトが実際に保有するオムニアセットによって常に裏付けられている必要があります。
脆弱性分析
デポジットのパスでは、クロスコントラクト転送が完全に解決される前に、受信者の内部残高にクレジットが付与されていました。解決処理中、resolve_deposit_internal()は受信者が制御するrequested_refundを、そのトークンに対する受信者の総残高によって制限していましたが、現在解決中のデポジットで実際に転送された金額であるdepositedによる制限はかけていませんでした。総残高はアカウントが支払い可能な金額を示すに過ぎず、depositedはこの転送によって許容される返金額を定義するものでした。この第二の制限が欠けていたため、既存の残高が大きい受信者は、現在のデポジットを大幅に超える返金を要求できました[10]。
長いトークンIDを多数含むバッチデポジットの場合、不正な返金値によりシリアライズされたMtBurnEventが肥大化しました。その結果、check_refund().unwrap_or_panic_display().emit()パスが、イベントがNEARの総ログ長制限を超えた際にパニックを起こし、mt_resolve_depositレシートが失敗しました。
内部残高は、それより前のレシートで既にクレジットされていました。パニックによってコールバックレシートが試みた残高および供給量の減算はロールバックされましたが、以前のクレジットは取り消されませんでした。その後、Omniは転送された資産を送信者に返却し、その結果攻撃者には、intents.nearが保有するオムニアセットとは一致しない、送金可能な内部残高が残されました。この脆弱性は、返金検証の欠陥と、非同期レシートのシーケンス全体にわたるステートロールバックの欠落が組み合わさって発生したものです。
攻撃分析
以下の再構成は、公開されている情報に基づいています[11]。
フェーズ1: NEAR上で裏付けのない内部残高を生成
-
ステップ1: 攻撃者はBNB Chain Omni/HOTボルトを通じて10
USDTをデポジットし、悪意のある受信者アカウントにNEAR上でゼロではないオムニアセット残高を持たせました。 -
ステップ2: 攻撃者は
v2_1.omni.hot.tg上でmt_batch_transfer_call()を呼び出しました。mt_on_transfer()内で、intents.nearはまずdeposit()を通じて受信者にクレジットを付与し、その後悪意のある受信者に通知を行い、その応答をmt_resolve_deposit()に渡しました。 -
ステップ3: 悪意のある受信者は、現在のデポジットを大幅に超える
requested_refundを返しました。検証処理が受信者のトークン総残高を上限として使用していたため、この異常な値が返金処理へと進んでしまいました。 -
ステップ4: バッチ処理された複数のエントリにおいて、過大な返金値によってシリアライズされた
MtBurnEventがNEARの総ログ長制限を超えました。これによりmt_resolve_depositコールバックがパニックを起こし、その試みた返金に関する減算はロールバックされましたが、以前のレシートによって確定された内部クレジットはロールバックされませんでした。Omniは転送された資産を返却しましたが、intents.near上にはクレジット済みの残高がそのまま残されました。このシーケンスを繰り返すことで、攻撃者は送金可能な裏付けのない残高を生成することができました。
フェーズ2: BNB Chainボルトから実際の資産を送金
- ステップ5: 9月30日のUTC18:57および20:05に、攻撃者は有効なHOT MPC認証を使用して、10
USDTおよび11USDTの送金によりBNB Chainボルトをテストしました。最初のテストトランザクションにより、ボルトが上流の認証を受け入れることが確認されました。
- ステップ6: 9月30日UTC23:54から10月1日UTC06:08にかけて、攻撃者は80万
USDT、120万USDT、150万USDT、33万USDT、3万5,000USDTの5回にわたるより大規模な送金を行いました。これらのトランザクションにより、ボルトから総計386万5,000USDTが流出しました。
結論
NEAR Intentsは、不適切な返金検証と、デポジット解決失敗後のロールバックの欠落を通じて悪用されました。攻撃者は、過大な返金リクエストを利用して、裏付けとなる資産が返却された後も内部クレジットを維持し、その裏付けのない残高を使って送金をリクエストしました。Omniは対応する送金記録を生成し、HOT MPCがそれに署名し、BNB Chainボルトが実際のUSDTを解放しました。
返金処理では、各トークンの返金額を、現在解決中のデポジットにおける金額によって制限する必要があります。プロトコルはまた、可能な限り残高のクレジット処理と解決処理をアトミックに行うべきであり、失敗後には確実な補償ロールバックを適用する必要があります。送金署名を発行する前に、内部残高の合計と実際のオムニアセット保有量を照合し、不一致が検出された場合には送金を一時停止すべきです。また、イベント生成にも上限を設け、過大なログがステート上重要な解決処理パスを中断させることがないようにする必要があります。
参考文献
[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response
[2] https://x.com/GracyBitget/status/2104515761691939026
[5] https://x.com/benbybit/status/2103328213141508335
[6] https://x.com/GracyBitget/status/2103812967066439817
[8] https://x.com/GracyBitget/status/2104602301503816040
[9] https://x.com/near_intents/status/2105642219357241796
[10] https://github.com/near/intents/pull/362
[11] https://x.com/Phalcon_xyz/status/2105680009687957909
BlockSecについて
BlockSecは、ブロックチェーンセキュリティおよび暗号資産コンプライアンスをフルスタックで提供するプロバイダーです。私たちは、コードオーディット(スマートコントラクト、ブロックチェーン、ウォレットを含む)、リアルタイムでの攻撃阻止、インシデント分析、不正資金の追跡、AML/CFT義務の遵守支援など、プロトコルおよびプラットフォームのライフサイクル全体にわたって、お客様を支援する製品・サービスを構築しています。
BlockSecは、権威あるカンファレンスにおいて複数のブロックチェーンセキュリティ関連の論文を発表しており、DeFiアプリケーションにおけるゼロデイ攻撃を複数報告し、複数のハッキング被害を阻止して2,000万ドル以上の資金を救済し、数十億ドル規模の暗号資産を保護してきました。
-
公式ウェブサイト: https://blocksec.com/
-
公式Twitterアカウント: https://twitter.com/BlockSecTeam
