為什麼兩筆小額測試轉帳沒有觸發風控警報?
多數交易所的風控系統,核心邏輯是設定一個金額或頻率的閾值,超過閾值才會攔截或要求人工審核。攻擊者顯然清楚這套機制的存在,刻意把測試轉帳金額壓在閾值以下,等於是用一次「合法的小額提款」去試探系統反應,確認沒有觸發警報後,才在30分鐘內放大規模。
這也說明單純依賴「金額閾值」的風控邏輯本身有結構性弱點——它假設攻擊者不會耐心測試,但這起事件顯示,有能力取得內部系統存取權限的攻擊者,完全有條件先做偵察再出手。
用戶的私鑰沒有外洩,是不是代表個別用戶不需要採取任何行動?
就「保護自己錢包私鑰」這件事而言,確實不需要額外行動,因為問題不在用戶端。但如果你在 Bitget 上持有資產,比較務實的做法是持續關注交易所後續公布的調查報告與補償方案,並留意交易所後續是否調整提款審核流程(例如新增獨立的第二層審核)。
更廣泛來說,這起事件也是提醒:不管你用哪個交易所,了解該交易所的冷熱錢包比例、有沒有公開的準備金證明,會比單純相信「這家交易所很大、應該很安全」更有參考價值。
第三方安全產品出問題,責任應該算在誰頭上?
從用戶的角度,這個問題的答案其實不重要——不管最終是供應商的產品有漏洞還是交易所整合流程有疏失,用戶資產受損的事實不會改變,交易所仍然是用戶直接信任、託付資產的對象,責任鏈最終還是會回到交易所身上。
但從產業治理的角度,這起事件確實凸顯一個越來越普遍的問題:大型交易所高度仰賴外部安全廠商提供的基礎設施,而這些廠商本身的安全稽核標準、零日漏洞披露速度,外界很難直接檢視。這也是為什麼近年監理機構與產業自律組織,開始要求交易所揭露更多供應鏈風險管理資訊。
2026年9月24日,加密貨幣交易所 Bitget 證實遭遇重大資安事件,損失金額約3.88億美元。這起事件特別值得關注的地方在於:攻擊者攻破的不是 Bitget 自己開發的系統,而是交易所仰賴的第三方安全產品裡存在的一個零日漏洞。
根據 Bitget 執行長 Gracy Chen 的說法,攻擊者利用一款未具名第三方安全產品裡的零日漏洞,取得了公司內部管理系統的存取權限。拿到這個立足點之後,攻擊者並沒有直接對外部錢包動手,而是把偽造的提款指令插入到錢包相關的後端服務裡——這些指令在系統眼中,看起來跟正常的內部操作一模一樣。攻擊者利用竊得的高權限憑證,把自己的活動偽裝成例行的管理操作,同時清除行為痕跡,企圖讓整起入侵在事後也難以被完整追溯。
攻擊時程顯示出明顯的分階段操作。9月24日世界協調時間18:31,攻擊者先執行了兩筆小額測試轉帳,金額刻意壓在 Bitget 風控閾值之下,沒有觸發任何警報。大約30分鐘後,攻擊者才開始執行大額轉出,而這些大額交易成功繞過了原本應該攔截異常提款的風控機制。被盜資金最終分散流向以太坊/EVM系列鏈、XRP Ledger、Zcash 與 Tron 等多條區塊鏈上的地址,這種跨鏈快速分散的手法,也是近年大型交易所駭客事件慣用的洗錢前置動作。
值得慶幸的是,這起事件只影響了 Bitget 的熱錢包與溫錢包,也就是為了應付日常提款需求而保持連網或半連網狀態的錢包。冷儲存完全沒有受到波及,而且 Bitget 強調整起事件中沒有任何使用者的私鑰遭到竊取或外洩——攻擊者取得的是系統層級的管理權限,而不是直接拿到個別用戶的金鑰。這個區別很重要:代表問題出在交易所的內部架構與第三方供應鏈上,而不是用戶自身的操作疏失。
Bitget 懷疑此次攻擊與北韓駭客組織有關,可能是過去多次參與大型加密貨幣竊案的 TraderTraitor 集團,部分依據來自區塊鏈分析公司 TRM Labs 所識別出的資金流向與手法重疊。事件發生後,Bitget 隨即限制相關系統存取權限、撤銷可能已遭竊的憑證,並加入獨立的第二層提款審核機制,同時隔離受影響的系統,等待第三方供應商修補其安全產品裡的漏洞。
如果你把資產放在中心化交易所,這起事件提醒你:交易所本身的程式碼有沒有漏洞,只是風險的一部分,交易所仰賴哪些第三方安全廠商、這些廠商的產品有沒有獨立稽核紀錄,同樣是你難以直接看到、卻實際影響資金安全的一環。你可以留意的具體線索包括:交易所是否公開揭露過安全事件應變流程、是否有獨立的提款審核層(不是單一系統說了算)、以及冷熱錢包的資產配置比例——這起事件裡冷儲存完好無損,正是多層防禦發揮作用的例子。