私鑰未遭竊，虛擬貨幣資金如何被盜？

提出付款請求的人已通過身分驗證。付款已獲核准，交易簽章也有效。這是否代表資金安全？

不一定。

2025 年，BigONE 損失約 2,700萬 USD，而 Bybit 遭受一起造成 15億 USD 損失的攻擊。2026 年 10 月，Binance 通報一起影響約 63.4億 USD 數位資產的安全事件。這些事件說明，光靠安全儲存私鑰，無法保證資金安全。

因此，機構不能只關注私鑰的安全儲存。付款的依據是什麼？簽署的究竟是什麼？由誰決定交易能否獲得簽署？執行後，系統又如何判定付款是否已完成？

本文中，BlockSec 透過公開通報的事件，檢視從發起付款到結算的整個流程中，容易被忽略的授權風險。

我們即將推出的技術系列文章 Beyond Secure Storage，將深入探討兩種攻擊路徑：

未取得系統私鑰，卻濫用其簽署能力。
利用密碼學實作中的缺陷還原私鑰。

加密貨幣付款可能在哪些環節遭到劫持？

透過錢包執行的付款通常涉及四個階段：

付款依據與授權。
交易建構與驗證。
簽署授權與金鑰使用。
執行與結算。

1. 付款依據與授權

簽署交易前，機構必須確認相關付款是否合法：

• 對於客戶出金，平台需要驗證客戶身分、確認可用資金充足，並檢查請求是否符合其業務規則。

• 內部轉帳也需要取得適當的資金管理核准。

但攻擊者可能竄改帳戶紀錄或風控邏輯。系統隨後可能依照正常流程，核准一筆原本不該發生的付款。

例如，2025年7月16日，BigONE 揭露一起熱錢包安全事件，估計損失為 2,700萬 USD。BigONE 表示，其私鑰仍然安全。SlowMist 的調查指出，攻擊者修改了與帳戶及風控相關的伺服器邏輯，從而得以進行未經授權的轉帳。

關鍵在於：用來核准付款的資訊與規則，在簽署前就已遭到竄改。

因此，對支付機構而言，僅確認請求來自內部服務並不足夠。每筆付款都應能追溯至可獨立驗證的客戶指示或資金管理決策。機構也需要檢查：單一身分遭到入侵後，是否就能偽造請求、竄改紀錄並變更核准規則。

2. 交易建構與驗證

你看到的，真的是你打算簽署的內容嗎？

付款獲得核准後，系統必須將收款地址、金額等業務細節，轉換為錢包可簽署的交易資料。

如果這個過程遭到入侵，介面可能顯示一筆轉帳，但送去簽署的交易實際上會改變錢包的控制權歸屬。

如此一來，即使你以為自己核准的是轉帳，簽章仍可能授權攻擊者接管錢包。

2025 年，Bybit 遭受約 15億 USD 損失的攻擊，便說明了這種風險。Bybit 原本打算將 ETH 從冷錢包轉至溫錢包。攻擊者入侵 Safe 介面，讓惡意交易看起來像例行轉帳。簽署者核准了交易，卻不知道自己授權了錢包控制邏輯的變更。

攻擊者利用有效簽章替換錢包的控制邏輯，接著透過新邏輯轉移資產；此後每次出金，都不必再取得原持有者的核准。詳細的鏈上分析請參閱BlockSec 對 Bybit 15億 USD 遭駭事件的分析。

教訓很明確：

簽署前的驗證必須涵蓋所簽署的完整交易，以及交易執行後的效果，不能只依賴介面顯示的內容。即使有多名簽署者，只要他們都依賴同一個遭到入侵的介面視圖，仍可能無法發現問題。

轉帳、錢包升級及出金權限變更，也應有各自不同的授權要求。一般轉帳的核准，不應被用來變更錢包控制權。

3. 簽署授權與金鑰使用

誰能簽署？誰又能變更簽署規則？

即使攻擊者無法直接簽署交易，也可能透過變更規則或替換系統執行的程式碼，取得等同的控制能力。

因此，管理簽署金鑰存取權限的行政權限，需要受到與簽署權限本身同等嚴格的審查。

根據 Resolv 對其 2026 年 3 月安全事件發布的官方事後檢討報告，攻擊者最初嘗試取得簽署權限並未成功。隨後，攻擊者利用特權角色變更金鑰的存取政策，授予自己簽署權限。憑藉該權限，攻擊者透過兩筆未經授權的交易鑄造了 80 million 枚 USR。

在另一起事件中，Binance 的初步事件報告描述了另一條取得簽署權限的途徑。攻擊者利用遭到入侵的員工裝置及內部 AI 工具，進一步觸及錢包工程師的裝置。攻擊者使用竊得的容器部署權杖部署容器，並執行惡意指令碼。隨後，對內部錢包簽署服務的未經授權存取，使交易得以繞過正常出金流程。

切入點雖然不同，但兩起事件都暴露了相同的根本問題：

保護金鑰，也意味著必須控管誰能變更金鑰存取政策、修改簽署環境，或授予簽署權限。

因此，支付機構需要檢視以下三個問題：

誰能呼叫簽署 API？
誰能授予呼叫該 API 的權限？
誰能部署或修改簽署服務？

業務核准、金鑰使用與管理變更之間的職責分離，也必須在特權身分遭到入侵時依然有效。

4. 執行與結算

交易一經簽署，風險就結束了嗎？

不一定。機構還必須考慮已簽署的交易何時可以執行，以及如何使其失效。

風險 1：已簽署的交易可能仍可執行

交易已經簽署，但尚未執行。之後還能提交執行嗎？

在某些機制下，可以。取消相關的業務請求，不會自動使已簽署的交易失效。

在發生於 2026年4月1日的 Drift Protocol 事件中，攻擊者利用 Solana 的 durable nonce 機制，使預先簽署的交易在一般交易短暫的有效期限過後仍保持有效。只要相關 nonce 尚未被使用或推進，這些交易之後仍可提交執行。

業務請求遭到取消或偵測到可疑活動時，機構需要有明確的方法，使已簽署但尚未執行的交易失效，也必須明定誰有權這麼做。

風險 2：內部轉帳可能遭到誤判，觸發額外退款

2026年9月12日，Chainflip 遭遇一起涉及 Tron USDT 的漏洞攻擊。攻擊者在驗證者已簽署的交易中附上精心設計的備註。Chainflip 的系統將該備註誤讀為另一筆兌換交易，認定該兌換失敗，因而發出退款。Chainflip 通報了六筆未經授權的付款，總額約為 73.64萬 USDT。

鏈上轉帳不一定代表一筆新的客戶付款，也不一定構成退款理由。在付款或發出退款前，系統還必須驗證資金來源、業務操作類型，以及對應的付款義務是否已履行。