讓錢包空空的更新

Trust Wallet 事件究竟發生了什麼

---

步驟 1:發布了新的瀏覽器擴充功能更新

Trust Wallet 瀏覽器擴充功能的新更新於 12 月 24 日發布。

• 該更新看起來很常規。

• 沒有附帶重大安全警告。

• 用戶通過常規更新流程進行安裝。

在這個時候,一切都沒有可疑之處。

---

步驟 2:新代碼被添加到擴充功能中

更新後,研究擴充功能檔案的研究人員注意到一個名為 4482.js 的 JavaScript 檔案發生了變化。

關鍵觀察:

這很重要,因為瀏覽器錢包是非常敏感的環境;任何新的外發邏輯都會構成高風險。

---

步驟 3:代碼偽裝成「分析」

添加的邏輯看起來像是分析或遙測代碼。

具體來說:

• 它看起來像常見分析 SDK 使用的追蹤邏輯。

• 它並非一直觸發。

• 它僅在特定條件下啟動。

這種設計使其在日常測試中更難被檢測到。

---

步驟 4:觸發條件——匯入助記詞

社群逆向工程顯示,當用戶將助記詞匯入擴充功能時,該邏輯被觸發。

為什麼這很關鍵:

• 匯入助記詞使錢包獲得完全控制權。

• 這是一次性的高價值時刻。

• 任何惡意代碼只需要執行一次。

僅使用現有錢包的用戶可能沒有觸發此路徑。

---

步驟 5:錢包數據被發送到外部

當觸發條件發生時,代碼據稱將數據發送到外部端點:

metrics-trustwallet[.]com

引起警報的原因:

• 該域名看起來非常像合法的 Trust Wallet 子域名。

• 它僅在幾天前註冊。

• 它沒有公開記錄。

• 它後來下線了。

至少,這證實了錢包擴充功能存在意外的外發通訊。

---

步驟 6:攻擊者立即採取行動

在匯入助記詞後不久,用戶報告:

• 錢包在幾分鐘內被清空。

• 多種資產快速轉移。

• 無需進一步的用戶互動。

鏈上行為顯示:

• 自動化交易模式。

• 多個目標地址。

• 沒有明顯的釣魚批准流程。

這表明攻擊者已經擁有足夠的權限來簽署交易。

---

步驟 7:資金在多個地址間合併

被盜資產通過多個攻擊者控制的錢包進行轉移。

為什麼這很重要:

• 它顯示了協調或腳本化操作。

• 它減少了對單一地址的依賴。

• 它符合有組織攻擊中看到的行為。

根據追蹤的地址估計,數百萬美元被轉移,儘管總額各不相同。

---

步驟 8:域名下線

在關注度增加後:

• 可疑域名停止回應。

• 沒有立即發布公開解釋。

• 截圖和緩存證據變得至關重要。

這符合攻擊者在暴露後銷毀基礎設施的行為。

---

步驟 9:官方確認隨後發布

Trust Wallet 後來確認:

• 安全事件影響了瀏覽器擴充功能的特定版本。

• 行動用戶未受影響。

• 用戶應升級或禁用該擴充功能。

然而,並未立即提供完整的技術分析來解釋:

• 為什麼該域名存在。

• 助記詞是否被洩露。

• 這是內部、第三方還是外部問題。

這一空白加劇了持續的猜測。

---

已確認的事項

• 瀏覽器擴充功能更新引入了新的外發行為。

• 用戶在匯入助記詞後不久損失資金。

• 該事件僅限於特定版本。

• Trust Wallet 承認存在安全問題。

---

強烈懷疑的事項

• 供應鏈問題或惡意代碼注入。

• 助記詞或簽名能力被洩露。

• 分析邏輯被濫用或武器化。

---

仍然未知的事項

• 代碼是故意惡意的還是上游被攻破。

• 有多少用戶受到影響。

• 是否有其他數據被竊取。

• 攻擊者的確切歸屬。

---

為什麼這起事件很重要

這不是典型的釣魚攻擊。

它突顯了:

• 瀏覽器擴充功能的危險性。

• 盲目信任更新的風險。

• 分析代碼如何被濫用。

• 為什麼處理助記詞是錢包安全中最關鍵的時刻。

即使是短暫的漏洞也可能造成嚴重後果。