於2026年9月24日，約3.875億美元從Bitget的部分營運錢包轉出，涉及以太坊及其他EVM網路、XRP Ledger、Zcash和TRON。Bitget將受影響的錢包描述為熱錢包和溫錢包。鏈上交易帶有有效的錢包簽名。Bitget將入侵點歸因於第三方安全產品中的漏洞，並表示私鑰和冷錢包未被入侵 [1, 2]。
根據截至2026年9月29日16:35 UTC可獲得的公開披露和鏈上證據，第一部分總結了已披露的攻擊序列、後續資金流動、服務恢復，以及生態系統參與者的不同應對方式。第二部分將這些觀察與我們的安全經驗相結合，為加密機構提出一個縱深防禦框架，並附上實用的安全建議。
1. 從鏈下入侵到鏈上損失與恢復
Bitget將入侵點歸因於第三方安全產品中的漏洞，但尚未披露該產品、受影響的元件或技術利用機制 [1, 2]。其公開說明將下游路徑描述為：內部存取、偽造提款指令、繞過風控驗證、有效簽名，以及鏈上轉帳。
1.1 攻擊時間線與歸因
Bitget CEO Gracy Chen報告的時間線，結合鏈上記錄，顯示了事件的發展過程 [3]：
- 9月24日18:31 UTC：首次轉移為0.84
ETH和93TRX。兩者均低於交易所的風控閾值。 - 18:58-20:09 UTC：Chen描述了跨以太坊、XRP Ledger、Zcash、BNB Chain、Base、Arbitrum、Optimism和Avalanche的十七次較大規模轉帳，總計約3.61億美元 [3]。鏈上記錄還顯示在TRON上於19:16 UTC發生了一筆2059萬
TRX的轉帳。 - 首次大額轉帳七分鐘後：Bitget的對帳系統偵測到差異並停止了使用者發起的提款。Bitget的時間線將此舉與後來在21:44 UTC關閉錢包提款和簽名服務區分開來 [1]。
Chen表示，攻擊者刪除了欺詐指令留下的痕跡 [3]。在初步歸因方面，她還表示IP位址行為和鏈上模式與已知的北韓黑客組織高度一致 [4]。這仍是初步歸因，而非最終結論；Bitget的官方事件頁面並未指名任何負責組織，調查仍在進行中 [1]。
1.2 資金流向與運營恢復
Bitget官方追蹤器反映的鏈上記錄顯示，被盜穩定幣在數分鐘內就被轉換為 ETH [5]。與 USDT或USDC不同，ETH等原生資產不存在發行方控制的凍結功能。此行為與試圖降低被發行方凍結風險的意圖相符，但並不能確立攻擊者的身份或其經驗水平。
隨著Bitget納入更完整的核算（包括Zcash和TRON），官方受影響金額後來上升至約3.875億美元 [1]。Bitget公布了攻擊者地址、恢復報告入口，以及地址API [1, 6]，並附上即時追蹤網站 [5]。該網站的持倉視圖報告了當前的分布情況，而其資金流圖則繪製了下游地址、服務、橋接及跨鏈路徑。
在9月29日16:35:28 UTC時，官方追蹤器報告攻擊者目前持有3.2267億美元，在八個項目中共凍結約63.27萬美元，發行方可凍結的穩定幣為31.25萬美元，5587萬美元仍在轉移中或尚在分析中 [5]。凍結總額包括：NEAR Intents凍結的29.3507萬美元（其報告在執行過程中凍結約50.3萬美元 [12]）、Tether凍結的23.9242萬美元，以及Circle凍結的9.999萬美元。公開資料來源未能核對NEAR Intents的數字。
在同一時間點，地址瀏覽器顯示已歸屬地址的餘額集中於 BTC（2.8851億美元）、ZEC（2891萬美元）及ETH（717萬美元） [5]。該瀏覽器所使用的分類範圍與概覽不同，因此其3.2769億美元的地址層級總額無法直接與概覽中的3.2267億美元當前持倉數字相比較。
運營恢復方面也有所進展。Bitget於9月29日08:00 UTC恢復了 ETH提款。到09:00 UTC，其報告約有9,674 ETH流入及9,023 ETH流出，流入超出流出約651 ETH [7]。
1.3 資金離開之後：社群的應對
一旦資產離開受影響機構的錢包，恢復工作便需依賴原有安全邊界之外的組織。Bitget開放了其追蹤資料，並針對協助凍結或恢復資金的合格援助推出賞金計畫 [1, 6]。幣安（Binance）表示，其安全團隊分享了情報、追蹤了資金，並支持恢復工作 [8]。Bybit CEO Ben Zhou提供了協助，並更新了LazarusBounty恢復平台，並指出Bitget曾在Bybit自身2025年事件中提供過協助 [9]。Bybit的回應延續了兩家交易所間互助的模式。
基礎設施提供者由於其技術設計和治理模式不同，擁有不同的選擇。Bitget要求THORChain拒絕向公開列示且正被積極追蹤的攻擊者地址提供服務。Gracy Chen認為「去中心化是一項設計原則，不應成為助長已知被盜資金流動的保護傘」 [10]。THORChain解釋稱，其並不支援選擇性黑名單：其緊急控制機制只能暫停更廣泛的活動或某條鏈路線，而無法針對單一地址或交易。部分被盜資產仍持續透過該網路從ETH轉入BTC [11]。
NEAR Intents報告了不同的應對方式。其SHIELD風控系統在過濾重複嘗試後，識別並阻止了逾5000萬美元與攻擊者相關的嘗試性資金流動；約50.3萬美元在執行過程中被凍結，約16.6萬美元則得以通過。NEAR Intents同時放棄了其在Bitget恢復賞金中應得的份額 [12]。這5000萬美元的數字是系統拒絕處理的嘗試性資金流動，並非被凍結或已恢復的金額。
大型跨鏈資金恢復通常需要多方參與者共同協作。交易所可以凍結存款或提款，穩定幣發行方可以凍結代幣，路由服務可以在其設計允許的情況下拒絕已歸屬的資金流，而基礎協議可能只能進行監控並分享指標。有效的協調始於每個參與者明確說明自己能採取何種行動，以及需要何種證據。
| 參與者 | 可用控制手段 | 適當行動 | 所需保障措施 |
|---|---|---|---|
| 交易所或託管方 | 存款入帳與提款 | 暫緩、調查並協調恢復工作 | 證據保存、申訴機制及法律程序 |
| 穩定幣發行方 | 代幣凍結權限 | 凍結高可信度的攻擊者餘額 | 有佐證的證據及糾正流程 |
| 橋接或路由服務 | 報價、路由或結算許可 | 在支援的情況下拒絕或暫緩已歸屬的資金流 | 公開的政策及有限度的干預 |
| 缺乏選擇性控制的基礎協議或基礎設施 | 監控及指標傳播 | 呈現風險指標並保留可追蹤性 | 準確的能力揭露 |
| 受影響機構及調查方 | 歸因及指標 | 發布已簽署、可供機器讀取的更新 | 可信度、時間戳、來源及有效期限 |
介入行動本身也帶來風險。錯誤的歸因可能會封鎖無辜使用者，而長期存在的黑名單可能從事件應對工具逐漸擴大為更廣泛的交易限制機制。可辯護的應對方式應運用有佐證的證據、範圍狹窄且有時限的限制、申訴流程、透明的行動記錄，以及事後審查。當某系統缺乏選擇性控制手段時，透明的能力揭露有助於建立合理的期望。當存在裁量空間時，公開的準則與負責任的決策機制可以支持一致的應對方式。
2. 阻斷並遏制利用路徑：系統性縱深防禦安全框架
基於第1節所記錄的事件路徑與應對措施，結合我們的經驗與專業知識，我們提出以下的雙層框架。關於程式碼審計與監控為何無法涵蓋整個資金處理路徑的更多內容，請參閱《為何加密機構需要區塊鏈滲透測試》 [13]。
- 已披露的利用路徑從第三方安全產品延伸至鏈上轉帳。
- 該框架的預防與偵測層包含前三項安全實踐。第2.1節和2.2節探討特權存取控制和獨立意圖驗證如何能防止基礎設施立足點進一步演變為簽名行為。第2.3節涵蓋資產流動監控，用於偵測並升級處理出金異常，並可暫緩存在風險的入金。
- 應對與恢復層包含第四項實踐。它可由預防與偵測層中任何位置的高可信度訊號觸發，或由運營故障觸發。第2.4節涵蓋暫停受影響操作或將受風險資產轉移至已驗證安全目的地的獨立能力。
每個小節均遵循相同的結構：安全目標、事件路徑所暴露的風險，以及機構可以建立的預防性、偵測性或應對性能力。這些實踐應依賴各自獨立的權限與證據。它們共同降低了對任何單一防護措施的依賴，並為機構提供了遏制損失的預備方案。
2.1 特權存取與提款指令
其目標是防止基礎設施或特權系統遭入侵時，足以單獨製造出可信賴的提款指令。
第三方產品並不需要直接的簽名存取權限即可影響資產轉移。獲取用於形成提款指令的憑證或系統存取權限，可能已足以決定另一系統將簽署何種內容。此類產品屬於機構層級的Web3攻擊面 [14]。其風險取決於它們所能影響的價值及所能觸及的系統。
所需的控制措施包括最小權限原則、網路分段、受限的更新及管理路徑、短效憑證、防篡改日誌，以及經測試的撤銷程序。內部存取權限不應自動賦予產生可信賴提款指令的能力。每筆指令都應帶有經驗證的來源、不可變更的請求識別碼，以及已簽署或以其他方式驗證過的設定版本。指令的建立、核准、簽名及廣播應分屬不同權限，下游系統應拒絕來源不明、設定過時或綑綁資訊不完整的指令。
2.2 提款意圖與簽名
其目標是防止偽造或被操控的提款指令變成有效簽署的交易。
有效簽名僅能確認相應私鑰對交易資料進行了簽署；它並不能證明底層的提款請求本身是真實的，或已經過獨立核准。
簽名邊界應從獨立、可信的記錄中重新構建預期的交易，並比對每個可能影響價值轉移的欄位。核准過程至少應綁定鏈、資產、金額、收款方、來源錢包、交易nonce值、費用範圍、有效期限，以及原始提款或資金調度請求。
構建提款指令的元件不應是用於授權該指令的唯一來源。政策評估應採用獨立的帳戶及風險資料，而簽名系統則應驗證最終交易資料是否與已核准的意圖相符。目前有效的授權簽名人集合、簽名門檻、交易nonce值及設定，都必須與預期的生產環境狀態相符。人工審核人員需要根據待簽署的確切位元組所生成的標準化交易視圖，而不是由請求方後端提供的可變更摘要。
2.3 出金與入金資產流動
其目標是偵測實際資產轉移與獨立重建的業務意圖之間的偏差。
加密機構既可以是資產流動的來源，也可以是目的地。出金監控應將實際的鏈上活動與獨立重建的已核准提款集合進行比對。為保持獨立性，監控機制不應僅依賴由提款系統自身產生的同一指令。
監控機制應從獨立的業務記錄中推導出預期的鏈、資產、金額、收款方、時間及錢包資訊。它應能跨多個維度整合行為模式，以捕捉單筆交易限額所無法偵測到的問題：
- 先進行小額測試轉帳，再快速升級規模。
- 跨帳戶、資產或鏈重複使用新的收款方。
- 提款速度或總曝險金額突然增加。
- 多個營運錢包層級同時出現資金流出。
- 轉向難以凍結的原生資產。
- 已核准請求、已簽署交易資料與已廣播交易之間存在差異。
控制措施應在一定時間窗口內評估累積金額、速度、目的地是否為新地址、錢包層級、資產轉換的容易程度，以及跨鏈行為。Bitget最初的ETH和TRX轉帳，說明了將交易作為一個序列而非僅視為孤立事件進行評估的價值 [3]。高可信度的不符情況應觸發第2.4節所述的緊急應對路徑。可信度較低的異常情況，可能需要進行二次核准、目的地冷靜期、降低限額，或暫時凍結提款。
入金監控應在入帳前對存款進行篩查，並在提款前重新篩查。它應追蹤資金經過橋接、去中心化交易所（DEXs）、基於意圖的路由服務及中間地址的流動情況，因為僅比對首個攻擊者地址是不夠的。高可信度的比對結果需要有明確記載的流程，用於暫緩資金、調查比對結果、處理申訴，以及完成任何法律移交程序。
交易所之間快速的情報共享，能將入金篩查轉化為一種網路效應。某個機構可能偵測到事件本身，而另一機構則可能看到相關的贓款流入。共享的機器可讀指標及最新聯絡方式，能夠縮短從歸因到採取行動之間的時間間隔。
2.4 緊急暫停與資產轉移
其目標是在識別出高可信度安全訊號或運營故障後，遏制剩餘的曝險風險。
訊號可能包括特權存取或指令完整性違規、提款意圖或簽名不符、異常的出金、入金或其他鏈上活動，以及對帳失敗。此時機構應能暫停受影響的簽名、廣播、提款或錢包操作。若資產仍存在曝險風險，機構也應能將其從疑似受侵的錢包轉移至預先設定的安全目的地。暫停能爭取調查時間；轉移則能降低剩餘的曝險風險。
- 獨立暫停權限： 即使主要管理系統遭入侵，暫停功能仍必須保持可用。在架構允許的情況下，其範圍應足夠狹窄，能夠針對特定鏈、錢包、資產或操作進行停止。啟動與解除均須有經驗證的權限、防篡改記錄、明確的恢復標準，以及在受限條件下進行的測試。
- 轉移路徑的連續性： 設定變更不得在新的替代路徑尚未部署、授權、簽署、儲存並測試完成之前，就使舊有的緊急路徑失效。
- 可執行交易的就緒狀態： 已儲存的緊急交易可能因nonce值變更、原生代幣餘額不足以支付手續費、來源資產餘額變化、費用市場變動導致已簽署的費用限額不再適用、有效期限過期，或設定更新等原因而失效。就緒狀態檢查應持續驗證這些相依項目。完全已簽署的交易資料應保持加密並受存取控制，直到緊急行動獲得核准且已準備好可立即廣播。
- 覆蓋範圍與容錯機制： 每個營運錢包、鏈、原生資產及所支援的代幣，都需要主要及備援轉移路徑。廣播及驗證基礎設施也需要在遠端程序呼叫（RPC）端點、運營系統及人工恢復工具之間具備冗餘性。
- 完成度檢查與演練： 緊急應對程序應透過已確認的鏈上執行、逐一資產驗證、剩餘餘額檢查，以及鏈上狀態與內部記錄之間的對帳來定義「完成」。程序還應能偵測鏈重組及失敗交易。應定期進行演練，測量從偵測到最終餘額確認的完整恢復時間。
經授權的區塊鏈滲透測試可以在約定範圍內對正在運行的環境進行實測，將跨層假設轉化為實際證據 [15]。對於生產環境測試，應在測試開始前制定書面的交戰規則（Rules of Engagement, RoE），明確授權範圍、允許的技術手段、停止標準、價值限制、溝通機制、證據處理方式，以及暫停權限 [16]。
區塊鏈滲透測試
找出入侵路徑——涵蓋合約、節點、API及雲端環境
結論
Bitget事件既非私鑰洩露，也非智能合約漏洞被利用。Bitget表示，攻擊者利用第三方安全產品中的漏洞取得了內網存取憑證，隨後偽造提款指令，而錢包系統將這些指令處理成有效簽署的鏈上轉帳 [1, 2]。資產離開受影響機構之後，恢復工作便成為整個生態系統共同承擔的努力。Bitget、Binance、Bybit、THORChain及NEAR Intents的應對方式表明，各方參與者可以採取不同的應對方式 [8-12]。當重大安全事件或威脅出現時，社群如何能夠迅速且負責任地協調這些能力，仍是加密產業面臨的一項更廣泛的挑戰。
已知的下游路徑為此處提出的系統性框架提供了依據，該框架將預防與偵測環節同應對與恢復環節相互連結。機構可以透過限制特權存取並驗證指令來源、在簽名時獨立重建已核准的提款意圖、監控出金序列與入金贓款，以及維持可獨立運作的暫停與轉移路徑，來降低對任何單一防護措施的依賴。託管仍然是不可或缺的一環，而上述這些實踐則在整個資金處理鏈中對其起到補充作用 [13, 15]。
參考文獻
[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026
[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026
[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045
[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736
[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track
[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607
[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508
[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629
[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335
[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817
[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin
[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040
[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing
[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing
[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing
[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement
