網路資安威脅
假「床蝨客訴」竟是攻擊！TONResolver RAT 鎖定日本 Booking.com 合作飯店
趨勢科技 TrendAI™ Research 觀察到一波於 2026 年 5 月出現、鎖定使用 Booking.com 之日本住宿業者的釣魚郵件攻擊活動。攻擊者假冒房客客訴與評論邀請，誘騙飯店員工執行惡意檔案，並利用 TON 區塊鏈平台作為「dead drop resolver」動態切換C&C伺服器，大幅提高偵測與下架的難度。本文將完整解析受害對象、攻擊手法與惡意程式特性。
Save to Folio
重點摘要
- 駭客的攻擊目標是 Booking.com 日本合作夥伴企業的員工，使用假扮成接獲客戶投訴以及要求飯店進行審查的網路釣魚郵件，誘騙飯店員工執行惡意檔案。
- 我們觀察到多種電子郵件散布方式，其中包括經由 Gmail 散布的大量網路釣魚郵件，此外還會在提供惡意網址之前先透過郵件往返來建立信任。
- 駭客使用的 TONResolver 惡意程式似乎是用來突破防線及執行指令以建立灘頭堡，後續觀察到的活動顯示駭客可能是為了竊取登入憑證並從事進一步入侵。
- 駭客將其幕後操縱 (CC) 伺服器網域儲存在 TON 智慧合約當中，因此，即使目前的 CC 伺服器被封鎖或下架，也能隨時換成另一台新的伺服器。
2026 年 5 月下旬，我們發現一些可疑的電子郵件被發送到 Booking.com 在日本的合作夥伴公司，郵件主旨為「重要：旅客住宿審查要求」(重要：ゲスト滞在レビュー依頼)。攻擊中使用了一個經由指向某個可疑網站的連結所下載的 ZIP 壓縮檔，當使用者點選壓縮檔中一個偽裝成照片檔案的捷徑檔 (LNK) 時，就會啟動感染程序。有別於傳統的網路釣魚攻擊，此惡意程式會利用 The Open Network (TON) 區塊鏈平台作為「祕密交換點解析器」(Dead Drop Resolver)，這樣駭客就能隨時更新幕後操縱 (CC) 伺服器的位址，不必將伺服器位址寫死在惡意程式中，這使得 CC 伺服器的偵測和下架都變得更加困難。
根據 TrendAI™ 的監測資料證實，當我們檢視網路釣魚郵件連結指向的可疑網站所屬網域 (.CFD 頂層網域) 的存取模式時，我們發現大多數存取都來自日本地區。遭上述惡意程式 (偵測名稱：TrojanSpy.JS.TONRESOLVER.A) 感染的端點，會隨時處於 Keepalive (保持連線) 的迴圈中，等候駭客下達指令，所以只要感染沒有去除，端點就會一直存在著憑證被盜以及被植入更多惡意程式的風險。
網路釣魚郵件的特徵
據觀察，這些針對日本的攻擊所使用的郵件主旨有兩種，郵件會假裝成「客戶投訴」並要求旅館業者點選網址來檢視隨附的照片，其意圖顯然是要誘騙旅館員工或老闆執行惡意內容。
這些電子郵件確認應該是利用某種排程工具服務所提供的通知功能來發送。所以，單靠 Sender Policy Framework (SPF)、DomainKeys Identified Mail (DKIM) 以及 Domain-based Message Authentication, Reporting, and Conformance (DMARC) 這類網域認證技術，並不足以防止業者收到這些電子郵件。
- 重要：ゲスト滞在レビュー依頼 (重要：旅客住宿審查要求)
- 【重要】お客様からの重大な苦情に関するご連絡 (重要：旅客嚴重投訴通知)
除了主旨之外，電子郵件中的超連結文字也有一些顯著的特徵，例如我們觀察到的以下幾個例子：
- Download Photos and Videos (下載照片和影片)
- 証拠写真・動画を確認する (檢視照片和影片證據)
- 添付資料を確認する (檢視隨附的資料)
圖 2 的日文電子郵件樣本翻譯之後內容如下：
Booking.com 合作夥伴支援
我們收到一名曾在 2026 年 5 月 11 日至 5 月 14 日期間下榻您飯店的旅客提出的嚴重投訴。懇請您務必立即審查此事，並採取必要的行動。
旅客投訴內容：
「房間裡發現有蟲，我女兒在我們入住期間被人叮咬了好幾次。基於健康風險，我們去看了一趟醫生。隨信附上床蝨的照片作為證據，我們強烈要求立即回應。」
旅客的姓名、聯絡資訊、訂房編號、確切住宿日期，以及所有投訴相關證據，請透過下方連結下載。
下載照片和影片
調查和迅速回應這起嚴重事件所需的所有資訊和材料，都已包含在附件當中，因此請仔細閱讀內容。
Booking.com 客戶服務團隊
另外，我們也觀察到了一封英文的電子郵件，儘管這起攻擊針對的是日本國內企業，但這封信應該是鎖定使用英文的人士。我們只發現一個主旨：「Urgent: Bed bug complaint from guest」(緊急：客戶投訴有床蝨)。
除此之外，我們在調查連結指向的目標基礎架構與惡意程式時，還發現了一些假冒 Gmail 名義發信的各種電子郵件與手法。
我們在這些攻擊當中觀察到一種「對話式攻擊」手法，其作法是：駭客會先發送一封不含網址的正常詢問郵件給飯店的聯絡人，等到對方回覆之後，再發送一封後續郵件並附上一個惡意連結。像這種先藉由初步書信往返來取得對方信任 (而非一開始就夾帶惡意網址) 的手法，正是進階持續性滲透攻擊 (APT) 的常見技巧。
以下列出我們在 Gmail 電子郵件中觀察到的一些主旨，其中完全沒用到日文。不過，有鑑於這類假扮成一般 Gmail 使用者的初步對話是為了取得信任，因此我們應小心也許同樣手法未來也會用於本次調查以外的攻擊。
以下是我們在互動式攻擊中看到的 Gmail 郵件主旨清單，其中的 {number} 代表任意數字，{English name} 則代表非日文的人名：
- Accommodation Inquiry – {number} (住宿詢問 – {number})
- Amazing Anniversary visit Extras Costs? (令人驚豔的週年慶行程額外花費？)
- Assessing Hotel Room Availability (評估飯店空房)
- Availability Confirmation Needed (需要確認空房)
- Checking Available Hotel Rooms (查詢飯店空房)
- Checking Hotel Availability for Stay (查詢飯店可供住宿的空房)
- Disappointed with Room Service (對客房服務感到失望)
- Hotel Accommodation Availability Inquiry (詢問飯店可供住宿的空房)
- Hotel Accommodation Request (飯店住宿詢問)
- Hotel Booking Availability Status (飯店可供訂房狀態)
- Hotel Booking Possibilities Check (查詢飯店是否有空房可訂)
- Hotel Booking Request (飯店訂房詢問)
- Hotel Reservation Availability Inquiry (飯店訂房狀況查詢)
- Hotel Rooms: Availability Status (飯店空房狀態)
- Hotel Stay Availability Verification (飯店住宿空房確認)
- Inquiry About Hotel Stay Options (詢問飯店住宿選項)
- Inquiry for Hotel Stay Availability (詢問飯店可供住宿狀況)
- Inquiry: Availability and Total Cost (詢問：空房與總價)
- Looking at Hotel Room Reservations (查看飯店訂房狀況)
- Looking for Hotel Vacancies (尋找飯店空房)
- Quick Availability Question (快速詢問空房狀態)
- Request for Booking Options (詢問訂房選項)
- Room Inquiry ({number}) (房間查詢)
- Short Stay Availability Check (查詢短期住宿供應狀況)
- Unacceptable Room Condition (房間狀況無法接受)
- Unacceptable Room service (客房服務無法接受)
- Very bad experience with room service (客房服務體驗非常差)
- {English name} {number}
駭客使用的幾種發送基礎架構
除了不同的電子郵件發送方式之外，我們也在散播初始惡意檔案的網域看到一些趨勢 (也就是駭客將受害者從電子郵件帶往的網域)。該名駭客 (或集團) 所使用的網域分布在四個頂層網域 (top-level domain，簡稱 TLD)，這些網域都提供相同的初始惡意檔案。
所有 TLD 都具備一項機制，那就是只要存取「http://{domain name}/v」這個網址，就會觸發某個 .ZIP 檔案被下載，此外我們也確認，要使用哪一個網域是根據目標電子郵件地址來挑選。
我們觀察到的這些網域使用了 Cloudflare 基礎架構，並使用了一對 Cloudflare 名稱伺服器：「galilea」和「moura」。Cloudflare DNS 固定會為每個帳號指派兩個名稱伺服器。由於兩個不同使用者收到同一對名稱伺服器的機率很低，因此，擁有相同一對名稱伺服器的網域可推測應該是屬於同一名駭客所有。
針對 6 月份之後產生的網域，這對伺服器已變成「brianna」和「roan」，顯示帳號或管理程序中的區域 (zone) 可能因為某種原因而更換。我們調查了一下電子郵件和網域所在的網址，結果如圖 4 所示。
如前面所述，.COM 頂層網域是唯一能識別網域註冊人特徵的網域。註冊人電子郵件 (Registrant Email) 所屬的「ghastlier」網域是一個拋棄式電子郵件網域，因此無法長期使用。註冊人名稱 (Registrant Name) 和註冊人電子郵件似乎是駭客預先設定好的數值。
仰賴使用者執行的感染鏈
當使用者經由電子郵件中的連結下載一個 zip 壓縮檔，然後執行壓縮檔內一個偽裝成照片 (PNG) 的捷徑檔 (LNK) 時，就會啟動感染程序。
LNK 檔案中的 PowerShell 指令會使用 [System.Numerics.BigInteger] 來處理兩個大型整數，計算兩者之間的差異。接著將得到的數值反覆除以 256，並將每次的餘數轉換成一個單一位元組 (single-byte) 字元 (Char)，透過這樣的方式重建出目標網域。然後，腳本會對重建出來的網域執行 Invoke-WebRequest，並將擷取到的 PS1 檔案 (PowerShell 腳本) 儲存在 %TEMP% 目錄底下，接著再用 PowerShell 來將它執行。[System.Numerics.BigInteger] 是從 6 月份之後才開始使用，5 月底前使用的是 [bigint]。
當腳本對外通訊來擷取 PS1 檔案時，使用 System.Numerics.BigInteger 所產生的網域名稱會連上壓縮檔所在的網址，並使用 Powershell.exe 來取得該檔案。此時，伺服器會確認 User-Agent 是否含有「Powershell」這個字串。如果不存在「Powershell」這串字 (例如使用瀏覽器的 User-Agent)，那就會回應「404 NotFound」；如果存在，那就回應「200 OK」並傳回 PS1 檔案腳本字串。下圖 8 所看到的 User-Agent 字串通常在網路上不會看到，因為基本上在正常情況下不可能出現「Mozilla」加「PowerShell」這樣的組合，但伺服器還是會傳回正常的回應。
擷取到的 PS1 檔案在被呼叫時會使用 ShowWindow 參數來隱藏 PowerShell 視窗。接著經由串接方式組合出「%USERPROFILE%\AppData\Local\Nodejs」這個資料夾路徑來儲存 Node.js 檔案，隨後的 JavaScript 惡意檔案也同樣是儲存這個資料夾路徑。惡意檔案的儲存位置如以下說明。接著再透過字串串接方式將 node-v24.13.0-win-x64 解壓縮至相同的資料夾。擷取 Node.js 時需要從底下描述的網站下載。
%USERPROFILE％\Appdata\Local\Nodejs\{filename}.js
%USERPROFILE％\Appdata\Local\Nodejs\node-v24.13.0-win-x64\
此外，腳本還設計了一套機制，利用 Get-Process 和 Where-Object 來避免重複執行，因此，如果端點上已經有同一個資料夾路徑的 node.exe 正在執行，處理程序就會結束並傳回「1」。
腳本執行時會從一個寫死的 Base64 數值復原出一個 32 位元組的 AES 金鑰和 16 位元組的初始化向量 (IV)，接著處理 Mutex 的名稱、執行後續的 JavaScript 惡意檔案，以及將參數解密。
使用 AES-CBC (Cipher Block Chaining) 來解開一個加密過的二進位大型物件 (Blob) (一大塊資料) 以取得 Mutex 的名稱。然後使用 Mutex 的名稱來建立避免重複執行機制。不僅如此，腳本的第 77 行還包含了一個極長的 Base64 字串。
如果 Node.exe 不存在，那就從 Node.js 官方網站 (nodejs.org) 取得「node-v24.13.0-win-x64.zip」並解壓縮至 「%USERPROFILE%\AppData\Local\Nodejs」目錄。利用字串串接方式來產生以下網址，此處的下載指定了 v24.13.0 版，而本次調查所檢驗的樣本也確認皆使用 v24.13.0 版。
https://nodejs.org/dist/v24.13.0/node-v24.13.0-win-x64.zip
位於第 77 行的 Base64 字串會在第 100–101 行時解碼，然後再透過 AES-CBC 演算法執行解密以產生 JavaScript 惡意檔案。此外，加密的 Blob 會被當成 JavaScript 惡意檔案執行時的參數，並在第 103 行透過 AES-CBC 演算法解密，以復原用來取得 PS1 檔案的網域名稱。最後的執行指令如下：
node.exe {JavaScript payload}.js {DomainName}
TONResolver 惡意程式靜態分析
當成 node.exe 的參數執行的 JavaScript 檔案 (偵測名稱：TrojanSpy.JS.TONRESOLVER.A) 是一個遠端存取木馬程式 (RAT)。這個 RAT 惡意程式採用虛擬機器 (VM) 式加密編碼手法，因此不可能單靠靜態分析來揭露其細節。藉由結合靜態分析與動態分析來驗證其行為，我們確認惡意程式使用了 TON 作為解析其目標 CC 伺服器的方式。TON 是一個 Telegram 當初以「Telegram Open Network」為名所開發的區塊鏈平台，目前主要由 TON Foundation 負責開發和營運。
這是一種利用合法服務作為掩護、被稱為「祕密交換點解析器」的通訊解析攻擊技巧，光靠簡單的靜態分析無法找出通訊位址。即使某個活躍的 CC 伺服器被某些方法所下架或封鎖，這項技巧也能輕易切換 CC 伺服器的通訊位址，因而成為駭客用來確保攻擊持續性的一種方法。
在 VM 式加密編碼手法中，其邏輯會轉換成自訂的虛擬指令集，解譯時會執行腳本中內嵌的客製化 VM 解譯器。經由這種解譯方式，分派器 (Dispatcher) 會根據虛擬操作碼 (opcode) 將運算交給腳本中的處理函式 (handler)，因此很難單靠靜態分析來重建其過程。
程式碼在經過整理之後可以看到，在 JavaScript 當中的 vme(0x...) 部分含有一個用來將字串解開的機制，而 vmn_22aed1 的部分則扮演 VM 解譯器的角色。藉由靜態分析該程式碼來執行字串解密，我們發現它實作了以下功能。
交給解譯器處理
該程式碼在經過靜態分析之後可看到，處理程序會經由一個結構來傳遞並由 vmn_22aed1 所呼叫，此處 vmn_22aed1 應該是扮演 VM 解譯器的角色，負責解譯被加密編碼的指令。
檔案操作與資訊蒐集相關的結構
我們觀察到，在將處理程序交給 vmn_22aed1 的「h」函式中，負責執行作業系統層次操作的模組，如「os」和「fs」都會被載入。
功能字串解密
由於原本的 JavaScript 已經過加密編碼，因此不容易看出它使用了什麼函式。因此，透過 vmz (負責傳回字串陣列) 和 vme (字串解密的入口) 的互相搭配，就能呼叫 vme(...) 來執行解密。藉由檢查 Base64 字串和已解密字串當中的純文字，我們找到了下列功能相關的字串：
- HKCU:\Software\Microsoft\Windows\CurrentVersion\Run
- Received message
- aes-256-cbc
- createCipheriv
- createDecipheriv
- fetch + https://google.com
- secp256k1
根據這些靜態分析結果顯示，惡意程式會被載入 Node.js 當中，並經由客製化解譯器來解譯並執行，然後經由 WebSocket (ECDH + HKDF-SHA256 + AES-256-CBC) 來加密。因此，想要在代理器 (proxy) 或網路資安服務當中根據封包內的字串來偵測可疑內容是極為困難的。
此外，我們也在 Base64 的字串和純文字當中發現以下 tonapi[.]io 網址：
hxxps://tonapi[.]io/v2/blockchain/accounts/ 0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9/methods/get_domain
在檢查過這個網址之後，我們發現惡意程式不會將 CC 伺服器的位址寫死在 JavaScript 中，而是經由 TonAPI 來擷取，這讓駭客很容易更換 CC 伺服器的位址。
Tonapi[.]io 通訊的位址是一個正常的網站和服務，我們確認駭客應該是在 TON 智慧合約當中實作了一段腳本，並且將 CC 伺服器網域內嵌在 methods/get_domain 當中。萬一 CC 伺服器遭到封鎖，那駭客就能發送一個新的字串給 TON 智慧合約，這樣就能自動啟用新的 CC 伺服器。
動態分析
動態分析的目的是要在前述靜態分析的基礎上，更精準地確認惡意程式的行為。以下是確認後的 JavaScript 執行流程：
- 執行 TONResolver (惡意程式的核心 JavaScript)。
- 經由 VM 式加密編碼在執行環境內初始化。
- 利用 Mutex 檢查是否重複執行。
- 檢查並設定用來常駐於系統的「Run」系統登錄機碼 (HKCU:\Software\Microsoft\Windows\CurrentVersion\Run)。
- 連上 Google.com 來檢查連線能力。
- 存取 TonAPI「methods/get_domain」。
- 從 TON 智慧合約取得 CC 網域。
- 經由 WebSocket 連上 CC 網域。
- 經由 ECDH secp256k1 交換金鑰。
- 經由 HKDF-SHA256 產生 AES 金鑰/IV。
- 經由 AES-256-CBC 加密發送訊息。
- 經由 AES-256-CBC 解密接收訊息 (CC 伺服器連線已建立)。
- 傳輸端點資訊。
- 每 20 秒發送一次 Keepalive (保持連線) 訊號。
- 若網路連線中斷就重新連線/重新交握。
- 從 CC 伺服器接收指令。
此外，從動態分析期間所發送和接收到的訊息可看到以下幾種功能 (類型 0 到類型 4)，它們應該是對應到 RAT 的各種操作。不過，類型 5 至類型 8 是我們根據靜態分析字串群組和程式碼分析結果所設定的暫時分類。
| 類型 | 頻率 | 功能角色 |
| 類型 0 | 執行期間每 20 秒一次 | Keepalive (ping)，從 CC 伺服器到用戶端。 |
| 類型 1 | 類型 0 之後立即發送 | Keepalive 回應，從用戶端到 CC 伺服器。 |
| 類型 2 | 開機時以及網路連線時 | 發送用戶端公開金鑰。 |
| 類型 3 | 開機時以及網路連線時 | 接收 CC 伺服器的公開金鑰和 salt。 |
| 類型 4 | 類型 2 和類型 3 之後立即發送 | 傳輸端點資訊。 |
| 類型 5 | 來自 CC 伺服器的指令。 | 解譯和執行任意 JavaScript 字串。 |
| 類型 6 | 來自 CC 伺服器的指令。 | 執行結果/回應處理。 |
| 類型 7 | 來自 CC 伺服器的指令。 | 檔案擷取/執行。 |
| 類型 8 | 來自 CC 伺服器的指令。 | 執行 PowerShell 指令。 |
類型 4 所傳輸的端點資訊經確認包含了以下資訊。「domain」會被當成擷取和執行 LNK 和 PS1 時的參數。其他的資訊包括端點的：使用者名稱、主機名稱、作業系統、CPU 核心數量、記憶體資訊，以及網路卡 MAC 位址。
在這個時間點，即使受害者執行了 LNK 檔案並經由 Node.js 執行 TONResolver，攻擊也不會立即從端點竊取檔案或登入憑證。不過，由於 Keepalive 通訊為駭客提供了執行其他指令和檔案的能力，因此可推測駭客會根據受害者的端點資訊與來源 IP 位址等環境資訊來選擇其他指令的攻擊目標。
從攻擊一開始到執行其他指令與後續惡意程式的整個過程如下：
- 駭客在 TON 上設定基礎架構與腳本，並更新 CC 網域。
- 發送網路釣魚電子郵件，使用者點選了隨附的連結。
- 連上惡意網站 photo-*****[.]cfd。
- 下載並解開含有惡意捷徑檔的壓縮檔。
- 使用者執行捷徑檔。
- 重新連上惡意網站 photo-*****[.]cfd 來下載 PS1 腳本。
- 執行 PS1 腳本。
- 擷取和解開 Node.zip (Node.exe)。
- 在 Node.exe 中載入並執行惡意 JavaScript (TONResolver)。
- 連線至 TON 平台 (tonapi[.]io)，存取「methods/get_domain」。
- 在回應中取得的 CC 網域。
- 連上 CC 伺服器、建立公開金鑰認證 (接著傳輸端點資訊)。
- Keepalive (保持連線) 開始啟動。
- 駭客挑選某些目標來執行其他攻擊並發送指令。
- 執行指令並部署其他惡意程式 (竊取機密等等)。
TON 區塊鏈合約與交易分析
當惡意程式從被當成祕密交換點解析器的 TON 合約取得 CC 伺服器位址時，是經由 WebSocket 連線至 tonapi[.]io 當中的「methods/get_domain」來取得網址，從該網址可解析出 CC 伺服器。任何人都能透過這個 tonapi[.]io 網址來查看 TON 合約的交易，但 CC 伺服器並非直接寫成一串純文字：
hxxps://tonapi[.]io/v2/blockchain/accounts/0:c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9/transactions
TON 合約的 raw_body 部分中的十六進位字串其實內含某種結構，其解讀方式如下：
| 結構 | 資料角色與解讀 |
| b5ee9c72 | TON 區塊鏈 (BOC) 格式神奇數字 |
| 0101201002100 | BOC 整體標頭、細胞 (cell，最小資料單元)、大小以及其他初始資訊 |
| 0110 | 第一個細胞的資料長度 |
| 17be49cf | op_code |
| 00000014 | 後續長度 |
| 01 | 下一個細胞的參照索引 |
| 0028 | 第二個細胞的資料長度 |
| 746f6e616a756b626875616b706f322e73686f70 | 網址 (實際資料)，CC 伺服器網域的十六進位字串 |
當 TONResolver JavaScript 執行時會存取「methods/get_domain」來取得通訊位址，確認該 CC 伺服器網域已經被處理過。發送請求至「methods/get_domain」所得到的回應會在「decoded.domain」中傳回 CC 伺服器網域，如下所示。
藉由檢查每個交易雜湊碼 (Transaction Hash) 的 utime (日期/時間) 和十六進位字串，就能確認駭客是何時將每個 CC 伺服器網域寫入 TON 合約。
| 交易雜湊碼 | utime (UTC) | 十六進位字串 | CC 伺服器網域 |
| 4ec8b349dec92720325aa4cd2637165283ef9b657efed25595d1127e13d9ed6c | 2026-06-02 02:53:50 | 746f6e616a756b626875616b706f322e73686f70 | tonajukbhuakpo2[.]shop |
| ad8a41329520983bd5b87610729aee7bc984a262df0a611efecc1e65d8122ac8 | 2026-02-20 15:19:03 | 7a6c6f61706f62696b61687932332e626f6e64 | zloapobikahy23[.]bond |
| 5853f2fb23c9824382a29e5094110cafa28cd8bb4b9ecbc6e7f890bf728a0d45 | 2026-02-09 19:17:05 | 68736165727479756f616e6733342e736273 | hsaertyuoang34[.]sbs |
| acf58e82c2716e3ca47eca715d318ab5c0fdf2d1bc50f4c89e7a8ad3324e244a | 2026-02-07 14:03:27 | 616d616e6f6875677574612e636664 | amanohuguta[.]cfd |
我們在整理 TON 合約 (0：c66119f0e5635c4380441d7a79baf0c02a0ab7ea6cd78de06507fc5dc2c1a5d9) 的交易時確認了以下過程。在檢查來源 TON 合約的匯入款項時，我們發現了一筆存款來自名為 Huobi 的 TON 合約，但並未發現其他有用的資訊。駭客用來更新 CC 伺服器的 TON 合約是 0：6d5b44d0678e6bd6703f2cabd2531ccf5a0b11cc081f8f7175bd679db4c12d41，而且所有交易都是來自這個位址。
| utime | UTC | 雜湊碼 | 摘要 |
| 1770471436 | 2026-02-07 13:37:16 | 540d78d1b48059f41d1e44f29bb255cfc4c3d628c2a4e2478fcca311c955c232 | 存入大約 5.99 TON (5.984)，合約從「不存在」變成「未初始化」。 |
| 1770473007 | 2026-02-07 14:03:27 | ed53b4d2adfe22d7e3852667834bb472c7963777c8468c7355d9cc5b08086a6c | 「get_domain」程式碼被初始化。合約從「未初始化」變成至「作用中」(初始化)，並寫入了 amanohuguta[.]cfd。 |
| 1770664625 | 2026-02-09 19:17:05 | bf72fbba31df1d3699ae7b72dd2737a22c80219e07055db607d17c12cf8ed760 | 經由交易寫入 hsaertyuoang34[.]sbs。 |
| 1771600743 | 2026-02-20 15:19:03 | 0fe5a035b02526ae1ecc1f212aea4564620103ce520532ed3dd6104abb6ac459 | 經由交易寫入 zloapobikahy23[.]bond。 |
| 1780368830 | 2026-06-02 02:53:50 | aea565f34dff268bbfea6d704d88ed7b198d0470f18a59e7e3468e64e4b9864f | 經由交易寫入 tonajukbhuakpo2[.]shop。 |
TON 合約的方法是由 TonAPI 呼叫並處理。透過一個使用 CRC16 的計算公式，「methods/get_domain」所呼叫的字串會轉換成一個數字，然後根據 TON 合約的實作方式來處理。因此，我們有必要確認駭客呼叫合約的「get_domain」是如何實作。如下所示，CRC16/XMODEM 計算公式會將「get_domain」轉換成 119378：
crc16(“get_domain”) | 0x10000
==> 119378
TON 合約內實作的功能，可在 assembly 層次上查看，方法是以二進位檔案方式取得「code」，然後使用一個用來處理 TON-Blockchain 的函式庫來將它反組譯 (tdisasm)。用來儲存駭客所用數值的「data」，同樣也可以二進位檔案方式取得。
反組譯的結果如下圖所示，其中第 3 行顯示的是第 0 號鍵值 (key 0) 的處理程序，第 40 行顯示的是第 119378 號鍵值 (key 119378) 的處理程序。此外，第 16 行也確認了 TON 合約交易當中所包含的 op_code：x{17BE49CF}。此 op_code 與表 2 中所描述的相符，代表實作這個 TON 合約的駭客也包括了這項處理程序。
此處的語言叫做 TVM Assembly，是構成 TON 的語言。我們可以閱讀 TON 文件中的 TVM 指令參考指南來解讀這個 assembly。解讀 TVM Assembly 時找到的 key 0 和 key 119378 處理程序分別說明如下：
Key 0：透過內部訊息來更新管理錢包的處理程序。
- 從管理錢包接收內部訊息 (交易)。
- 從資料細胞讀取已註冊的錢包位址。
- 比較內部訊息的寄件人地址與資料細胞中的錢包地址。
- 如果不相符，就拒絕處理並傳回 403。
- 如果相符，就檢查 body 的開頭是不是 0x17BE49CF。
- 如果開頭是 0x17BE49CF，那就將內部訊息中描述的新 CC 網域儲存到資料細胞。
Key 119378：經由「methods/get_domain」得到 CC 網域的處理程序
- 當呼叫「methods/get_domain」時，就會開始 119378 的處理程序。
- 從資料細胞讀取網域。
- 跳過最前面 128 位元的處理程序與管理錢包位址的處理程序。
- 讀取儲存在資料細胞內的網域長度。
- 讀取使用十六進位代表的網域字串 (儲存在資料細胞 ref[0] 當中)，然後使用「decoded.domain」將 CC 網域字串傳回。
TrendAI Vision One™ Services – Managed Detection and Response (MDR) 對這起攻擊的觀察
針對 TONResolver 之後部署的後續惡意程式，其攻擊鏈是根據 TrendAI Vision One™ Services – Managed Detection and Response (MDR) 的觀察發現。從 TONResolver 載入的 node.exe 處理程序開始，有一個執行檔會被部署到「%USERPROFILE%\AppData\Local\Temp」底下的一個目錄，後續還發現有試圖竊取登入憑證的情況。
根據觀察，被部署的執行檔會對以下資料夾進行一些操作，並涉及「C:\Windows\System32\lsass.exe」處理程序。這些資料夾含有瀏覽器儲存的密碼 SQLite 資料庫、Cookie 資料庫、瀏覽歷程記錄、自動填些資料、書籤資訊，以及其他資料，讓人懷疑駭客似乎會將資料外傳。
- C:\Users\<UserName>\AppData\Local\Google\Chrome\User Data\
- C:\Users\<UserName>\AppData\Local\Microsoft\Edge\User Data\
這是一起目前仍在持續當中的攻擊行動，TrendAI™ 將持續分析這起攻擊的細節與衝擊範圍，後續若有更多可對外公布的資訊，例如後續植入的惡意程式，我們會另外發文探討。
結論
這起行動專門攻擊 Booking.com 的合作夥伴企業，利用 TON 作為祕密交換點解析器，並透過 Node.js 來執行加密編碼。由於它濫用了 TON 區塊鏈平台並結合正常的 Node.js 環境，因而造成了許多傳統偵測機制可能失效的風險。
此外，隨著攻擊行動的持續發展，駭客還會註冊新的網域並更換 CC 伺服器，顯示駭客時時都在監控其攻擊趨勢與成功率。由於遭到 TONResolver 感染的端點隨時都在等著從 Keepalive 機制接收指令，所以，駭客想要的話隨時可對該端點發動攻擊，形成一項持續性的風險。
Node.js 是一個很便利的執行環境和平台，可輕鬆在端點上執行 JavaScript 以及應用程式。然而，這樣的環境有時卻能躲避偵測，進而成為駭客行動的幫兇。企業很重要的一點是必須持續監控其端點上執行的服務與處理程序，建置一些系統來建立資安基準，並持續偵測是否出現異常。
對於被針對的 Booking.com 合作夥伴企業，我們已確認受害者是由電子郵件管道遭到攻擊。採用現有的服務和功能，針對正常業務營運不會用到的通訊和應用程式加以管制，也有助於企業防範這類攻擊所帶來的相關威脅。當下我們建議企業重新檢視當前的組態設定、強化監控，並且重新評估資安事故應變程序。
資安建議
我們建議採取以下措施來防範上述攻擊：
管制與 TON 平台的連線
在對外連網的端點上部署一套代理器閘道 (proxy gateway) 並過濾連線，這樣就有可能防範某些祕密交換點解析器濫用的情況。在這起攻擊中，CC 伺服器網域是經由「tonapi[.]io」來取得。
正常來說，企業環境需要存取區塊鏈平台的情況應該很少。如果這類通訊並無必要，那麼預先設下連線管制，就能從中切斷攻擊鏈。
TrendAI Vision One™ Workbench 的偵測事件
Workbench 經由「Suspicious Autorun Entry Created by Node.js」模型偵測到可疑的 Node.js 使用方式，並將該事件列為高嚴重性。
TrendAI™ Apex One™ 與 TrendAI Vision One™ Endpoint Security
利用端點內建的防火牆功能，就能設置通訊管制來封鎖此次攻擊中擷取 PS1 檔案的通訊。從設定上封鎖 Powershell.exe 對外部 IP 位址的通訊，就能在中途攔截攻擊。這需要從 Vision One 主控台中的 Endpoint Security 選單進行設定。
TrendAI Vision One™ Zero Trust Secure Access (ZTSA)
如果從 TrendAI Vision One™ Zero Trust Secure Access (ZTSA) 提供的網際網路存取規則 (Internet Access Rules) 對含有「Powershell」字樣的 User-Agent 實施通訊管制，就能切斷 PowerShell 的對外通訊以及涉及擷取檔案的攻擊。這需要從 TrendAI Vision One™ 主控台中的 ZTSA 選單進行設定。
TrendAI Vision One™ Threat Intelligence Hub
TrendAI Vision One™ Threat Intelligence Hub 威脅情報中心提供了有關新興威脅與駭客集團的最新洞見、TrendAI™ Research 的獨家策略性報告，以及 TrendAI Vision One™ 平台的 TrendAI Vision One™ Threat Intelligence Feed 威脅情報來源。
新興威脅：TONResolver RAT：針對日本飯店業的攻擊行動
TrendAI Vision One™ Intelligence Reports (IoC 掃描)
追蹤查詢
TrendAI Vision One™ Services – Managed Detection and Response Data Explorer 應用程式
使用 TrendAI Vision One™ 的客戶可以使用 XDR Data Explorer 應用程式來尋找本文提到的惡意指標，看看是否也出現在自己的環境中。
eventSubId: 101 AND processCmd: (powershell.exe AND ps1) AND objectFilePath: AppData\\Local\\Nodejs\\node.zip AND parentCmd: ([bigint] OR BigInteger)
eventSubId: 901 AND processCmd: (SOFTWARE\\Microsoft\\Cryptography AND MachineGuid) AND parentFilePath: \\AppData\\Local\\Nodejs\\node-v24.13.0-win-x64\\node.exe AND processName: powershell.exe
eventSubId: 301 AND processFilePath: AppData\\Local\\Nodejs\\node-v24.13.0-win-x64\\node.exe AND processCmd: (node.exe AND .js) AND hostName: tonapi
入侵指標 (IoC)
如需完整的入侵指標 (IoC) 清單，請至此處。
特別感謝 JP Managed Service Team 工程師 Don Ovid Ladores (Advanced Cyber Defense Group 威脅事件回應與鑑識分析資深工程師) 與我們合作執行此次調查。