幣安熱錢包使用了 MPC：為什麼攻擊者仍能轉走資產？

2026 年 10 月 29 日，幣安發生一起涉及約 63.4 億美元資產的安全事件（幣安披露口徑；TRM Labs 估算約 63.6 億美元）。攻擊者獲得內部錢包簽名服務的未授權訪問，在正常提現流程之外發起交易，從多條區塊鏈上的熱錢包轉出資產。[1][2]

涉事熱錢包使用了 MPC（安全多方計算）。幣安在 10 月 30 日的公告中表示，目前尚未發現錢包私鑰泄露的證據。[3]

私鑰沒有被證實泄露，資產卻已經被轉走。這次事件值得思考的是：如果員工電腦、生產服務器，甚至 MPC 簽名協調入口被攻破，還有什麼能夠阻止攻擊者動用資產？

01 事件復盤：從員工電腦到錢包簽名服務

根據幣安 11 月 3 日發布的初步調查報告，這是一次持續數月的多階段入侵。[1]

6 月，一名錢包運維工程師為安裝 AI 編程工具，下載了被篡改的 Homebrew 安裝程序。安全團隊隨後更換設備並輪換相關憑證，但部分錢包團隊成員的身份和職責資訊已經暴露。

9 月，另一名工程師在虛假的招聘面試中運行了包含惡意代碼的項目，惡意程序當時未被終端安全工具檢出。

10 月 20 日，攻擊者利用失陷電腦及內部 AI 工具，進一步控制其他錢包工程師的設備，並竊取了另一名錢包運維工程師的容器部署憑證。

10 月 29 日，攻擊者使用竊取的憑證部署容器、執行惡意腳本，最終獲得內部錢包簽名服務的未授權訪問。

隨後，XRP、Solana、Optimism、比特幣等網路相繼發生異常轉賬。據 TRM Labs 的鏈上分析，此次事件涉及十條區塊鏈。[2]

在以太坊上，攻擊者同樣利用失陷的簽名服務，提前取得了 50 份 EIP-7702 授權簽名，並通過一筆鏈上交易提交。這些授權覆蓋連續的帳戶 nonce，其中一份因 nonce 匹配而生效，將熱錢包的執行邏輯委託給攻擊者控制的合約。此後，攻擊者能夠利用這項鍊上權限持續轉移資產，而不必經過正常提現流程。[1][2]

截至 11 月 3 日，幣安披露約 28.5 億美元的相關資產已被凍結或攔截。[1]

這次攻擊的關鍵路徑是：

員工終端失陷 → 內網橫向入侵 → 部署憑證被盜 → 簽名服務遭未授權訪問 → 資產轉移。

圖 1：幣安安全事件完整攻擊路徑

目前沒有證據表明 MPC 簽名算法遭到破解。MPC 讓多個參與方協同生成簽名，避免完整私鑰集中儲存，降低單點密鑰泄露的風險。但 MPC 算法本身不會判斷一筆交易是否經過合法的業務授權。如果攻擊者能夠讓滿足門限要求的參與方接受惡意請求，即使沒有取得完整私鑰，也可能生成有效簽名。

保護私鑰和控制私鑰的使用權限，是兩個不同的安全問題。

幣安尚未公開各個 MPC 簽名參與方的具體校驗機制，因此目前無法判斷其內部具體哪一環出現了問題。但可以確定的是，攻擊者獲得了內部錢包簽名服務的未授權訪問，並成功轉移了資產。這說明機構錢包除了保護私鑰，還必須嚴格控制籤名權限，確保每次簽名都經過合法授權。

此次攻擊從員工電腦開始，而惡意程序當時並沒有被終端安全工具檢出。[1] 針對這類攻擊，企業首先需要加強終端防護，並提高員工的安全意識：

員工不應隨意下載、運行來源不明的開發工具、開源項目和腳本；企業應加強軟體安裝管理和第三方依賴審查，並通過殺毒軟體、EDR 等工具監測異常行為。

內部 AI Agent 也應遵循最小權限原則，嚴格限制其訪問生產系統、敏感憑證及執行高風險操作的權限。

通過日常安全培訓、安全考試和釣魚演練，來提高員工識別虛假招聘、惡意項目及供應鏈攻擊的能力。

但終端防護無法保證攔截所有攻擊。如果員工電腦已經被攻破，如何阻止攻擊者進一步進入內網、竊取權限，最終控制錢包簽名服務？

02 縱深防禦之道：單一系統失陷不應直接導致資產損失

機構錢包不能假設員工電腦、內部網路或生產服務器永遠不會被攻破。當攻擊者突破其中一個環節後，是否還需要跨越其他獨立的安全邊界，才能獲得資產簽名權？

下面從三個逐步升級的攻擊場景展開：員工電腦失陷、生產部署權限失守，以及業務系統乃至簽名協調入口被控制。

假設員工電腦失陷：不要讓一台終端變成通往生產系統的跳板

攻擊者控制一台員工電腦，不應該因此獲得訪問整個企業內網和生產系統的能力。

首先，應儘可能縮小網路攻擊面。對外業務系統只開放必要的端口和接口；內部管理接口和生產運維入口原則上不直接暴露公網，應通過受控通道訪問，降低核心系統直接受到攻擊的風險。內部網路訪問也應遵循最小權限原則，根據人員角色、設備身份和業務需要授權。普通辦公設備不應隨意訪問生產環境，研發人員也不應默認擁有核心生產服務器的管理權限。不同業務系統及安全敏感區域之間，應建立獨立的網路訪問邊界，限制攻擊者橫向行動。

其次，需要隔離敏感權限。研發、生產部署、核心代碼授權和資金操作應由不同的權限體系管理，避免單個賬號掌握過多關鍵權限。部署憑證和生產訪問憑證尤其需要重點保護。此次事件中，攻擊者正是在一台失陷的工程師電腦上，使用從另一名錢包運維工程師處竊取的憑證部署容器、觸發惡意腳本。[1]

這類高權限憑證不應長期以明文或可直接復用的形式保存在日常辦公設備上，而應通過受控憑證管理、按需授權等措施降低暴露風險。生產部署操作也應通過受控環境發起，避免任意辦公設備都能直接操作核心生產系統。此外，還應持續監測異常登錄、跨系統訪問、敏感權限變更及高風險操作。一旦發現設備或賬號失陷，應及時隔離設備、撤銷相關憑證並阻斷異常訪問。通過網路隔離和最小權限控制，可以限制單個員工賬號或終端失陷後的攻擊範圍，降低攻擊者進一步獲取關鍵權限的風險。

但如果攻擊者還是竊取了生產部署憑證，能夠將惡意程序部署到生產環境，又該如何阻止它控制核心安全系統？

假設生產部署權限失守：部署權限和應用准入權限形成可信信任鏈

代碼經過安全審計，並不代表線上運行的就是經過審計的版本。如果攻擊者能夠替換核心程序，並讓惡意程序直接獲得原有的敏感業務權限，代碼審計就可能失去意義。

因此，像分發籤名計算任務的核心程序，需要建立從開發、發布、部署到運行的完整信任鏈。

首先，應通過可復現構建驗證，確保發布的程序與經過審計的源碼一致。核心程序的新版本還需要經過獨立的多人審核與授權，不能由構建系統或部署人員單方面批准。

對於承擔關鍵授權功能的程序，可以通過可信執行環境（TEE）的遠程證明機制驗證實際運行的代碼身份，並確認該版本是否經過授權。只有通過驗證的可信程序，才能獲得相應的敏感業務能力。

這樣，即使攻擊者將惡意程序部署到生產環境，未經授權的程序也無法通過可信執行環境校驗，無法冒充可信程序生成有效的交易授權結果。通過將生產部署權限與應用准入權限分開，可以防止攻擊者僅憑部署權限就替換可信程序、篡改核心安全邏輯。

圖 2：生產部署權限與可信程序准入隔離

假設業務系統乃至簽名協調入口被控制：簽名前獨立驗證授權與內容

再假設攻擊者控制了業務服務器或數據庫，能夠修改交易金額、收款地址、審批記錄或交易策略。如果簽名系統直接相信這些數據，就可能將攻擊者偽造的交易當作合法請求。因此，對於資產轉移等關鍵交易，應建立獨立的策略校驗系統，負責驗證交易授權、業務規則和風險控制要求。這類系統通常稱為策略引擎，可以基於 TEE 構建，避免業務服務器被攻破後直接影響授權校驗結果。

在採用 TEE 的設計中，策略引擎根據預先建立的成員權限、審批規則和交易策略，獨立驗證相關授權簽名。檢查通過後，生成帶有密碼學簽名的可信報告，記錄經過授權的交易關鍵內容。業務服務器可以傳遞交易請求，但不能僅憑修改數據庫或內部接口數據，就偽造有效的授權報告。

簽名系統還需要確認究竟簽署了什麼。

幣安此次事件中的 EIP-7702 授權，並不是一筆普通轉賬，而是允許帳戶將執行邏輯委託給其他合約。授權一旦生效，攻擊者就可能通過被委託的合約繼續轉移資產。[2][4] 類似風險還包括代幣授權、合約升級、權限委託，以及無法識別真實業務用途的原始哈希簽名。

因此，簽名系統不能只檢查普通轉賬的金額和收款地址，還需要識別簽名內容的真實含義，對高危授權設置獨立的審批和權限限制。對於無法確認具體用途的簽名請求，不應默認按照普通轉賬放行。

EIP-7702 只是此次攻擊的一條資金轉移路徑。比特幣、XRP、Solana 等網路上的異常轉賬並不依賴這項機制。僅僅攔截 EIP-7702，並不能解決簽名服務整體失陷的問題。

即使攻擊者進一步控制了 MPC 簽名協調入口，也不應因此獲得最終簽名權。

各個 MPC 參與方不能只相信協調服務下發的待簽名哈希，而應獨立驗證策略引擎簽發的可信報告，核對交易關鍵字段，並根據原始交易或授權數據確認最終待簽名消息。任意一個必要的簽名參與方校驗失敗，即可拒絕參與簽名，最大化利用 MPC 分布式計算的特點進行分布式校驗，進一步增加攻擊門檻。

此外，MPC 還可以通過客戶與服務商分別持有密鑰分片，進一步限制單方簽名權限。例如，在 3/3 MPC 架構中，客戶持有一份密鑰分片，另外兩份分別由服務商的兩個獨立節點管理。三方必須共同參與，才能生成有效簽名，服務商無法單方面完成簽名。

圖 3：生產部署權限與可信程序准入隔離

在人工審批場景中，客戶 App 還可以執行所見即所簽（WYSIWYS）校驗，在本地核對審批內容、原始交易數據和最終待簽名消息。例如，審批人批准向地址 A 轉賬 100 USDT，如果服務端隨後將收款地址替換成 B，客戶端及其他簽名參與方就能通過獨立校驗發現這種篡改。

自動化簽名的風險有所不同。客戶部署的自動簽名組件根據預先授權的業務規則參與審批和簽名。如果客戶業務系統與自動簽名組件同時失陷，惡意請求仍可能獲得有效授權。因此，兩者應通過獨立雲賬號、最小權限等措施隔離開，並通過獨立的交易策略和額度限制，降低惡意簽名風險。

從可信程序、可信准入到最終簽名，每個環節都需要獨立驗證。簽名協調入口可以負責組織 MPC 計算，但不能成為交易授權和簽名內容的唯一信任來源。

03 如果攻擊已真實發生，如何儘可能減少損失？

即使建立了多層防護，也需要考慮最壞的情況：攻擊者已經取得有效簽名，甚至已經在鏈上完成了惡意授權。

幣安此次事件中，暫停正常提現和關閉熱錢包服務，並沒有立即阻止全部資產轉移。原因在於惡意 EIP-7702 授權已經在鏈上生效，不再依賴正常提現流程。停止新的簽名請求，並不會自動撤銷已經生效的鏈上授權。

幣安披露，由於涉事熱錢包使用 MPC，沒有一把可以直接用於撤銷授權的完整私鑰，團隊需要臨時制定專門的撤銷流程，拖長了處置時間。[1] 這並不意味著 MPC 天然難以應急，而是說明機構錢包需要提前準備獨立於正常業務流程的應急簽名和資產恢復能力。

應急處置需要區分三種情況：

尚未簽名的交易： 通過緊急停簽、權限凍結等措施阻止新的惡意簽名。

已經簽署的交易： 已經生成的有效簽名不會因為簽名服務關閉而自動失效，需要根據具體區塊鏈及交易狀態處理。

已經生效的鏈上授權： 需要通過新的有效鏈上操作撤銷或替換授權，單純暫停提現無法收回已經授予的權限。

圖 4：攻擊發生後的應急止損與資產恢復

如果發現某個錢包受到惡意委託控制，還應立即停止向該地址自動歸集資金，並停止將其作為新的充值地址使用，避免後續資金繼續進入失陷錢包。

除了及時止損，還需要考慮平台本身無法正常提供服務的極端情況。機構錢包應為客戶保留獨立於線上平台的資產恢復能力。例如，在持有完整有效恢復材料的前提下，客戶可以通過離線工具恢複錢包私鑰，再導入其他錢包，繼續管理或轉移資產，而不必依賴原有平台繼續正常運行。[6]

對於需要服務商協助的恢復場景，應建立明確的身份核驗、授權審批和密鑰分片恢複流程，並通過定期演練驗證可行性。

離線恢復和緊急撤權解決的是兩個不同的問題：前者用於在極端情況下重新取得資產控制權，後者用於儘快終止已經生效的惡意鏈上授權。兩者不能相互替代。

04 結語

幣安此次事件中，攻擊者利用內部錢包簽名服務的未授權訪問完成了異常資產轉移。目前沒有證據表明 MPC 密碼算法遭到破解；幣安也表示尚未發現錢包私鑰泄露的證據。[1][3]

這次事件說明，私鑰安全只是機構資金安全的一部分。從終端安全、網路訪問控制、人員權限隔離，到可信代碼發布、可信准入及 MPC 多方獨立驗證，每個環節都需要建立獨立的安全邊界。

員工電腦被攻破，不應直接導致生產權限失守；攻擊者取得部署權限，不應因此能夠替換可信程序、控制核心授權；簽名協調入口被控制，也不應繞過各個參與方的獨立驗證。

同時，機構錢包還需要提前準備緊急停簽、鏈上授權撤銷和獨立資產恢復能力，儘可能減少攻擊造成的損失。

縱深防禦的核心是避免單一系統或權限失陷直接導致客戶資產損失。

Safeheron 將縱深防禦應用於終端安全、內部訪問、核心程序授權、交易簽名和資產恢復等關鍵環節。

在終端與內部訪問層面，Safeheron 已部署終端安全防護並持續處理安全告警，同時開展員工安全意識培訓和考核。對於部分高敏環境，實施網路訪問限制；內部系統按照崗位職責分配權限，並通過專門的憑證管理措施降低敏感憑證暴露風險。

在核心程序層，可信程序准入需要經過安全、研發及關鍵人員的多人審批。可信准入與生產部署權限相互獨立，運維人員即使擁有部署權限，也無法單方面授權核心程序。經過審計的代碼通過獨立可復現構建驗證、多人授權簽名及基於 Intel SGX 的 TEE 遠程證明，確保關鍵業務能力只授予經過授權的可信程序。

在業務及簽名層，Safeheron 採用基於 TEE 的策略引擎，獨立驗證客戶授權、審批簽名和交易策略，並簽發可信報告。客戶側簽名組件與兩個相互隔離的雲端節點共同完成 3/3 MPC 簽名，各參與方在簽名前獨立驗證可信報告和交易數據。

在人工審批場景中，客戶 App 執行所見即所簽校驗；自動化場景則由客戶自行部署的 API Co-Signer 根據業務授權結果參與 MPC 簽名。[5]

在極端情況下，Safeheron 提供開源的離線私鑰恢復工具。客戶持有完整恢復材料時，可以脫離線上平台恢複錢包私鑰，並將其導入其他錢包管理或遷移資產。[6][7]

通過這些措施，Safeheron 將終端防護、權限隔離、可信代碼、業務授權、MPC 簽名和資產恢復結合起來，降低單個內部系統或權限失陷導致客戶資產受損的風險。

參考文獻

[1] Binance，2026-11-03：29 October 2026 Binance Security Incident: Initial Findings and Response Update

[2] TRM Labs，2026-10-29：North Korea Steals USD 6.36 Billion From Binance

[3] Binance，2026-10-30：Security Incident Update #2

[4] Ethereum Improvement Proposals：EIP-7702: Set Code for EOAs

[5] Safeheron：API Co-Signer

[6] Safeheron：Offline Private Key Recovery

[7] Safeheron GitHub：Offline Recovery Tool

來源：金色財經

發佈者對本文章的內容承擔全部責任
在投資加密貨幣前，請務必深入研究，理解相關風險，並謹慎評估自己的風險承受能力。不要因為短期高回報的誘惑而忽視潛在的重大損失。