Binance 加密貨幣盜竊事件據稱始於手提電腦：支付與交易系統的 7 項教訓

2026 年 10 月 29 日，全球最大的加密貨幣交易所 Binance 發生了一宗可能是有紀錄以來最大規模的加密貨幣失竊案。截至我在 10 月 30 日撰寫本文時，事件仍在發展。相關數字不斷變動，而 Binance 表示，待調查結束後才會發布完整技術報告。

我為金融科技和交易領域的客戶開發軟件。我不會猜測 Binance 內部出了甚麼問題。我能做的，是根據已確認的事實，探討這對其他人的意義：那些以小得多的規模建設支付基建、券商整合、交易機械人、錢包及帳本的團隊。

我的看法很直接：你真正的攻擊面可能不是智能合約或 API，而是工程師的手提電腦，以及這些手提電腦獲準存取的任何資源。

目前確知的事實（截至 10 月 30 日 PKT 上午）

本文所述內容均有來源依據。未經確認的內容均已標明。

Binance 確認發生安全事故。根據 TechCrunch 等媒體報道的 Binance 聲明，Binance 曾暫停提款，之後又暫停存款，以進行安全檢查。據 Cointelegraph 的即時報道，Binance.US 未受影響。
損失規模仍屬估算。Binance 表示，估計總影響金額約為 $6.3 billion（BBC、Cointelegraph）。Chainalysis 表示，目前估計被盜資產在遭竊時約值 $5.912 billion。較早前，加密貨幣觀察人士的報道指，熱錢包至少有 $2 billion 被轉走。
大量資產已遭凍結。Binance 表示，經核實的凍結資產總額約為 $3 billion，而數字可能進一步上升。TechCrunch 報道，Tether 凍結了約 $1.56 billion，Circle 則凍結了約 $800 million。Binance 聯席行政總裁 Yi He 表示，Ripple 凍結了約 $200 million 的 RLUSD（據 Decrypt 報道）。Arbitrum Security Council 表示，已凍結約 $30.5 million。
初步調查指問題源於一部手提電腦。Binance 表示，初步調查指向一名 DevOps 工程師的手提電腦遭入侵。這次入侵可能讓攻擊者存取一個服務容器，並提交未經授權的提款交易。Binance 表示，沒有發現錢包私鑰外洩的證據。這些仍屬初步調查結果，Binance 表示仍在調查攻擊手法。
外部觀點，未獲 Binance 確認。Blockaid 行政總裁向 Cointelegraph 表示，該公司的初步判斷是「金鑰遭不當使用」：簽署系統遭欺騙或入侵，因而授權交易，但金鑰本身並未被提取。這只是單一公司的初步評估。
Binance 表示會透過 SAFU 基金及公司資金向用戶作出全額補償。Binance 亦表示，補足資產後會重新發布儲備證明（TokenPost 引述 Binance 的説法）。

鏈上情況

目前最詳盡的公開時間線，來自 Aave 的風險服務機構 LlamaRisk 在Aave 治理論壇有關事件的帖文：

10 月 29 日 20:24 UTC，Binance 一個位於 Ethereum 的熱錢包在一筆交易中，向單一地址轉出約 167,464 ETH。Binance 的另一個熱錢包又轉出 28,006 ETH；數分鐘內，Arbitrum、Optimism 和 Avalanche 上的資金也相繼轉出。
23:04 UTC 出現 AVAX 資金流入，暗示兩個多小時後入侵活動仍在持續。
資金分散至 20 多個新錢包，UNI、LINK 和 AAVE 等代幣則在去中心化交易所兑換成 ETH。

你可能看過一則廣傳的説法，指攻擊者把盜取的 USDT 存入 Aave，以此借入 ETH，然後帶着無法凍結的資產離開。這説法的核心內容已獲確認，但涉及的金額比部分帖文所説的少。據 LlamaRisk 稱，攻擊者錢包羣中的一個錢包在 20:58 至 21:01 UTC 期間，向 Aave V3 存入 60M USDT，並借入 19,762 WETH（約 $44.6M）。這比 Aave 首次凍結市場早約 40 分鐘。Decrypt 查閲 Etherscan 紀錄後描述了同樣的模式：把可凍結的穩定幣兑換成 ETH，或以穩定幣作抵押借入 ETH；ETH 沒有可凍結它的發行方。Aave 表示其合約未遭利用，而且該頭寸屬超額抵押，因此其資金提供者不會面臨風險。

已確認的情況就是如此。如果我在開發涉及資金流動的軟件，以下是我會從中汲取的教訓。

教訓 1：將開發人員的手提電腦視同正式環境

如果初步調查結果成立，攻擊者無須利用交易所核心的零日漏洞。他們只需要一名工程師的電腦，以及該電腦能存取的任何資源。

我接觸過的大多數小型金融科技團隊都會加強伺服器保安，卻不管手提電腦。同一部手提電腦可能存有 kubeconfig、雲端 CLI 憑證和 SSH agent forwarding，同時又用來執行裝有大量擴充功能的瀏覽器、十多個 npm postinstall 指令碼，以及可存取 shell 的 AI 編碼工具。

我會這樣做：

將手提電腦納入裝置管理，啟用磁碟加密、自動更新及 EDR。
磁碟上不儲存長期有效的雲端或叢集憑證。使用與 SSO 綁定的短期權杖。
將用來「瀏覽及編碼」的電腦或設定檔，與用來「操作正式環境」的分開。加固的管理員虛擬機器或專用裝置，相比一個錢包的價值，成本很低。
在存取時檢查裝置狀態（device posture），而不只是登入時檢查。

教訓 2：任何人都不應長期擁有正式環境存取權

「一名 DevOps 工程師的手提電腦能存取一個可提交提款請求的服務容器。」無論最終報告怎樣説，你都應該問：是否有任何一個人的憑證可以存取負責轉移資金的系統？

採用即時授權存取。工程師須提交與工單關聯的限時角色申請，由另一人批准，並在限期屆滿時自動失效。可以設置緊急存取帳戶，但使用時必須觸發警報。如果某人星期二的日常工作不需要派款服務的寫入權限，那麼他星期二就不應擁有這項權限。

教訓 3：保護金鑰並不足夠，還要保護簽署決策

Binance 表示未發現私密金鑰外洩的證據，而 Blockaid 的分析則指向「金鑰遭濫用」。綜合來看，這再次説明瞭團隊不斷重新學到的一課：HSM 或 MPC 架構保護的是金鑰，而非簽署決策。如果遭入侵的服務可以要求簽署器簽署任何內容，即使金鑰安全無虞，資金仍然會被盜走。

將簽署器設計成政策引擎，而非自動販賣機：

它只簽署與獨立紀錄相符的交易：由面向用戶的流程建立，並有獨立稽核記錄的提款請求。
熱錢包轉冷錢包及金庫資金調動均採用目的地允許清單。
簽署器自行執行每筆交易及每個時段的金額上限，而非由呼叫方執行。
大額或異常轉帳須由多名審批者透過不同裝置，核對實際簽署的內容（金額、目的地、區塊鏈），而非只核對雜湊值。

第 4 課：速度限制和冷靜期是功能，不是阻礙

Aave 的時間線顯示，首次轉帳就在單筆交易中轉移了約 167k ETH，而兩個多小時後仍有活動。無論上游發生了甚麼，資金流出都又大又快。

任何轉移價值的系統都應具備：

流出速度限制，按每個錢包、每種資產及每個時間範圍設定總流出上限，並設有必須由人員解除的硬性停止機制。
冷靜期延遲，適用於新目的地，以及超過指定門檻的金額。國庫轉帳延遲 30 分鐘會令人煩惱；兩小時內被掏空則是致命的。
熱錢包規模。只保留應付日常提款所需的資金，並透過較慢且須另行核准的流程，從冷錢包補充資金。

如果你建立交易或付款系統，應在負責簽署及發送的程式碼路徑中加入這些限制，確保上游服務遭入侵時也無法繞過。

第 5 課：留意規模異常、但看似「正常」的請求

由內部服務提交的未經授權提款，對於只檢查「這項請求的格式是否正確並已通過身份驗證？」的系統而言，可能看起來完全有效。

在這類事件中，以下監察措施會有幫助：

按資產及區塊鏈監察流出金額，並與滾動基準比較，超出時發出警示。
當服務帳戶執行從未做過的操作時發出警示：使用新目的地、新區塊鏈或在新的時段操作。
關聯特權存取與資金流動的警示：「工程師工作階段登入了付款叢集，而 30 分鐘內資金流出量增加了 10 倍。」
安排值班人員在無須請示任何人的情況下按下緊急停止（見下一課）。

第 6 課：在需要之前先準備好凍結按鈕

看看 10 月 29 日誰有能力止住損失。Binance 暫停了提款和存款。Tether、Circle 和 Ripple 將地址列入黑名單。Arbitrum 的 Security Council 將資金轉移至凍結錢包。Aave 的 guardian multisigs 凍結了 V3 在 16 個網絡上的 175 項儲備，以及 V4 的 117 項儲備。LlamaRisk 表示，Aave 選擇凍結，是因為 guardian 可以撤銷凍結；若要下調上限，則須經治理投票，而恢復上限約需五天。

建構系統的人應記住兩點：

為每條資金流動路徑準備可逆轉、經預先測試的緊急停止開關：包括付款、提款、內部轉帳和交易。開關應可按資產及渠道分別操作，而不是隻能「全部關閉」。並要練習使用。
瞭解哪些資產不能凍結。已確認的 Aave 交易過程顯示，攻擊者把可凍結的穩定幣換成 ETH，而沒有任何發行方能控制 ETH。如果你的事故應變計劃假設「發行方會凍結資產」，那麼所有沒有發行方的資產都會令計劃留下漏洞。偵測速度比追回資金的選項更重要。

第 7 課：審計軌跡就是你的公信力

Binance 表示會補足資產後承擔損失，並重新發布儲備證明。不論你對交易所有甚麼看法，正確的次序就是先補足，再證明。

對規模較小的團隊來説，同樣的做法雖然平淡，卻不可或缺：

只可新增、不可修改的帳本，記錄每項餘額變動，並連結至經授權的請求、操作者及核准紀錄。
每天將內部帳本與鏈上或銀行餘額對帳，並在出現偏差時發出警示。
即使攻擊者入侵手提電腦，也無法修改的日誌：傳送至主機以外，並以只寫入一次的方式儲存。

當監管機構、合作銀行或用戶問「發生了甚麼事？我的資金還在嗎？」時，你應根據這些紀錄作答，而不是靠新聞稿。

一部遭入侵的手提電腦，是否令人質疑 Binance 的保安？

這個問題問得合理，留言區有不少人也在問。以下是我能給出的最坦白答案。

Binance 的初步調查結果是，一名 DevOps 工程師的手提電腦可能遭入侵。據報，攻擊者因此得以進入服務容器，並提交未經授權的提款請求。Binance 亦表示，尚未發現私鑰外洩的證據。這兩點都只是初步結果。

如果這個説法成立，那麼答案是肯定的：這確實令人產生疑問。在設計完善的資產託管系統中，單一端點遭入侵，不應足以轉移資金。縱深防禦的作用，就是確保單一環節失守時，例如一部手提電腦被盜、一名工程師遭網絡釣魚攻擊，或一個權杖外洩，下一層防線能夠將其攔截。任何安全工程師都會提出以下問題：

權限分離：為甚麼與一部手提電腦相關聯的身分，能夠存取可建立提款的容器？
提款審批設計：大額提款是否須經多方或硬件密鑰批准？提交提款請求是否與簽署提款分開，確保看似有效的請求仍須經獨立簽核？
網絡分段：可處理提款的服務容器，是否能從工程師的裝置存取？
異常限制：是否設有交易速率上限或自動暫停機制，理應在交易量如此異常時觸發？

另一方面，調查仍在進行。Binance 以外無人知道這些控制措施是否存在、哪些措施有效，或攻擊者如何突破它們。「手提電腦是攻擊入口」只説明攻擊從哪裏開始，並未解釋整個攻擊過程。這種規模的攻擊通常會利用多個弱點，有些控制措施也可能已發揮作用。這或許有助解釋為何一大部分資金得以凍結。

因此，我不會在此下定論。我只想問一個問題：如果今晚你公司的其中一部手提電腦遭入侵，攻擊者最多可以轉移多少資金？如果你無法回答這個問題，你面對的未解問題就與 Binance 一樣，只是規模較小。

我不會據此下的結論

我不會聲稱知道 Binance 所述內容以外的攻擊過程。「手提電腦，然後是服務容器，再然後是未經授權的提款」是初步調查結果。最終報告可能會改變目前的説法，而攻擊歸因亦尚未獲確認。請把相關金額視為仍在變動的估算值。如果 Binance 的技術報告改變以上任何事實，我會更新這篇文章。

但七項教訓都不取決於最終細節。對於任何一個系統，只要一部機器遭入侵就可能演變成九位數或十位數級別的問題，這些都是我希望系統具備的措施；當中也包括一間每天轉移首筆 $10k 資金的兩人初創公司。

檢查清單版本

受管理、已加密並已安裝修補程式的手提電腦；磁碟上不存放長期有效的正式環境憑證
即時按需、經批准且設有期限的正式環境存取權限，並就緊急存取機制的使用發出警示
能強制執行政策（允許清單、上限、多方審批）的簽署器，而非只負責保管密鑰
交易速率限制、冷靜期延遲，以及規模合適的熱錢包
就資金流出，以及與資金轉移相關的特權工作階段發出異常警示
經測試、可還原並按路徑配置的緊急停止開關，另須為無人能凍結的資產制定計劃
只增不改的帳簿、每日對帳，以及防篡改日誌

如果你正在開發支付或交易系統：以下哪一項是你的團隊目前實際欠缺的？是甚麼阻礙你們加入這項功能？