摘要

本報告針對用於傳遞 PureHVNC Remote Access Trojan (RAT) 的多階段感染鏈，提供詳細的技術分析。分析著重於 HijackLoader 元件所使用的複雜規避機制，包括 DLL side-loading、shellcode 注入到系統函式庫、進階資料解密方法，以及間接 API 呼叫和記憶體 unhooking 等複雜的anti-analysis 技術。瞭解這些機制，對於開發針對現代、專注於匿蹤的惡意軟體攻擊之穩健防禦策略至關重要 [1]。

不只 DLL 側載：PureHVNC 惡意軟體規避偵測的複雜三階段技術分析 | 資訊安全新聞

1. 簡介

Threat actor 正不斷採用日益複雜的方法來繞過安全控制並傳遞 payload，網路威脅的環境持續在演變。PureHVNC RAT 是一個現代、市售惡意軟體的典型範例，它依賴於高度混淆且多層次的 loader，稱為 HijackLoader，來成功部署。本報告剖析了這個感染鏈的技術流程，突顯了從初始執行到最終 payload 傳遞的關鍵階段，特別強調實現其匿蹤和持續性的技術元件和程式碼層級操作。主要目標是深入探討惡意軟體的運作機制 [1]。

2. 感染鏈的技術剖析

2.1. 第 1 階段：初始執行和 DLL Side-Loading

感染的初始階段利用了一種經典而有效的技術：DLL side-loading [1]。此方法利用了 Windows 作業系統用於定位可執行檔所需的動態連結函式庫 ( DLL ) 的可預測搜尋順序。惡意軟體始於一個合法的 Windows 可執行檔，特別是 javaw.exe ，它被重新命名為一個具有欺騙性的、與Context 相關的名稱（例如， 02 BOLETA FISCAL.exe ）以誘使執行 [1]。

javaw.exe 的合法性被濫用，因為它對 JLI.dll 存在依賴性。藉由將一個 malicious payload 版本的 JLI.dll 放在與被重新命名的 javaw.exe 相同的目錄中，作業系統被騙而首先載入這個 malicious payload 函式庫。這個 malicious payload JLI.dll 的核心功能極小：將下一階段的 payload，即 MSTH7EN.dll ，載入到程序的位址空間中。這是透過標準的 Windows API 呼叫 LoadLibraryW() 實現的 [1]。

以下 pseudocode 闡述了 malicious payload JLI.dll 進入點的概念性操作： 

  1. // Malicious JLI.dll Entry Point Pseudocode
  2. function DllMain(hinstDLL, fdwReason, lpvReserved) {
  3.     if (fdwReason == DLL_PROCESS_ATTACH) {
  4.         // Load the second-stage payload
  5.         hModule = LoadLibraryW("MSTH7EN.dll"); // [1]
  6.         
  7.         if (hModule != NULL) {
  8.             // Proceed to execution of the loaded module
  9.             // ...
  10.         }
  11.     }
  12.     return TRUE;
  13. }

2.2. 第 2 階段：HijackLoader 和 Shellcode Injection

第二階段由 MSTH7EN.dll 驅動，負責核心 HijackLoader 模組的複雜載入和注入程序。此階段優先考慮匿蹤和反分析措施。它動態解析所有必要的函式庫和 API，並對工作目錄執行關鍵檢查，以確保其位於預期的位置 [1]。

一個重要的技術層面是第三階段 payload 的處理，它包含一個 加密的惡意軟體設定 。此設定規定了後續的操作，包括用於 hollowing 的目標 DLL、shellcode chunk 大小，以及反分析驗證位元組 [1]。注入的常見目標是系統函式庫 vssapi.dll 。shellcode 被載入到目標 DLL 的記憶體空間中，其記憶體保護會立即被修改以允許執行，使用 VirtualProtect() API，將保護旗標設定為 PAGE_EXECUTE_READWRITE [1]。

shellcode 本身充當一個複雜的 loader，透過對系統程序名稱進行 hash 並將其與設定中的數值進行比較，來執行反分析檢查，如果找到匹配項則引入延遲 [1]。

然後，loader 讀取檔案 Plagkeg.zk ，其中包含加密的 HijackLoader 模組。資料被分割成 chunk，每個 chunk 前面都有一個特定的標記 ( IDAT ) 和一個檢查值 ( 0xC6A579EA ) 用於完整性驗證 [1]。解密程序涉及一個簡單的 XOR cipher ，然後進行 LZNT1 decompression 以產生最終的、可執行模組結構 [1]。

2.3. 第 3 階段：模組執行和最終 Payload

解壓縮的模組包括名為 ti64 的主要 shellcode 和最終的 payload 模組 rshell [1]。 ti64 模組是 HijackLoader 的操作核心，負責透過一個被稱為 DLL hollowing 的程序，在指定的 DLL（例如， pla.dll ）上執行其他模組 [1]。此 hollowing 技術涉及 unmapping 或 overwriting 載入的 DLL 的合法程式碼，並將其替換為 malicious payload shellcode，從而從受信任程序的記憶體空間執行 payload。

rshell 模組包含 PureHVNC RAT ，這是感染鏈的最終目標。此 RAT 為Threat actor 提供了遠端存取能力，允許控制被滲透系統。整個程序流程總結在以下架構圖（圖 1）中。

Figure 1: PureHVNC Multi-Stage Infection Chain Architecture

graph TD     A[Initial Lure] --> B(Renamed javaw.exe)     B --> C(DLL Side-Loading)     C --> D(Malicious JLI.dll)     D --> E(LoadLibraryW API Call)     E --> F(MSTH7EN.dll - Stage 2)     F --> G(Initialize & Resolve APIs)     G --> H(Decrypt Configuration)     H --> I(Read Plagkeg.zk)     I --> J(Decryption & Decompression)     J --> K(HijackLoader Modules)     K --> L(DLL Hollowing)     L --> M(ti64 Shellcode - Main)     M --> N(rshell - PureHVNC RAT)     N --> O(Final Payload Execution)     subgraph Evasion Techniques         P(Anti-VM/Anti-Debug)         Q(TinyCallProxy64)         R(ntdll.dll Unhooking)     end     F --> P     M --> Q     M --> R     style A fill:#f9f,stroke:#333,stroke-width:2px     style N fill:#ccf,stroke:#333,stroke-width:2px     style O fill:#f99,stroke:#333,stroke-width:2px     style P fill:#ffc,stroke:#333,stroke-width:2px     style Q fill:#ffc,stroke:#333,stroke-width:2px     style R fill:#ffc,stroke:#333,stroke-width:2px        

3. 進階規避和反分析技術

HijackLoader 元件因其採用了多種複雜的反分析技術而引人注目，這些技術旨在使檢測和逆向工程變得複雜 [1]。這些方法確保惡意軟體僅在非監控環境中執行，從而顯著增加了其檢測所需的時間。

3.1. 透過 TinyCallProxy64 的間接 API 呼叫

為了掩蓋關鍵 Windows API 呼叫的來源，惡意軟體利用了一種間接 API 呼叫機制，特別是透過一個被稱為 TinyCallProxy64 的元件 [1]。此技術採用一個名為 mw_indirect_api_call() 的函式，它使用 shellcode proxying 來模糊 API 呼叫的真正來源。該程序高度複雜，涉及記憶體保護的動態操作、暫時 shellcode 的 swapping，以及在 API 呼叫執行後還原原始程式碼流程 [1]。這使得靜態分析變得困難，因為 import address table ( IAT ) 並沒有直接揭示正在呼叫的 malicious payload 函式。

API 呼叫遮罩程序的概念性表示如下： 

// Conceptual Flow of Indirect API Call
// 1. Save original memory protection of target API
// 2. Change memory protection to PAGE_EXECUTE_READWRITE
// 3. Inject TinyCallProxy64 shellcode stub
// 4. Call the shellcode stub (mw_indirect_api_call)
// 5. Shellcode executes the desired API (e.g., VirtualAlloc)
// 6. Restore original API code
// 7. Restore original memory protection
   

3.2. Anti-VM 和 Anti-Debugging 措施

loader 配備了廣泛的檢查，以檢測在虛擬化或 除錯器環境 中的執行 [1]。這些檢查包括：

  • Timing checks: 分析特定操作所需的時間，這在虛擬機器中通常不一致。
  • CPUID inspection: 透過 CPUID instruction 檢查 CPU 功能和 hypervisor 的存在。
  • System resource checks: 驗證可用 RAM 的大小和 CPU 核心數，這在分析環境中通常是最小的。
  • Host environment checks: 仔細檢查使用者名稱和電腦名稱是否為常見的 sandbox 或分析師識別符。
  • Process termination: 如果檢測到已知的分析程序，則終止執行 [1]。

3.3. Memory Unhooking

一項特別進階的技術是使用針對 ntdll.dll 的 unhooking routine [1]。安全產品通常會透過修改初始指令將執行重新導向到其監控程式碼來「hook」系統 DLL（如 ntdll.dll ）中的函式。HijackLoader 的 routine 透過將記憶體中的 ntdll.dll 版本與 DLL 的乾淨副本進行比較來對抗這一點 [1]。藉由檢測指令差異，惡意軟體識別出安全 hook，並將記憶體中的 ntdll.dll patch 回其原始位元組，從而在進行其核心 malicious payload 攻擊之前有效地關閉安全產品的監控功能 [1]。

4. 結論

由 HijackLoader 策劃的 PureHVNC 傳遞機制，代表了惡意軟體複雜性的一個重大進步。它對 DLL side-loading 等經典技術的依賴，結合透過 TinyCallProxy64 的間接 API 呼叫和主動的 memory unhooking 等高度進階的規避策略，對傳統端點安全解決方案構成了嚴峻的挑戰。多階段特性，加上模組的 XOR decryption 和 LZNT1 decompression ，確保了沒有單一階段會揭示最終 PureHVNC payload 的全部操作能力。未來的防禦研究必須側重於檢測這些低階記憶體操作和 API 混淆技術，以有效減輕由此和類似 loader 帶來的威脅。

References

  1. X-Force Threat Analysis Report: LATAM baited into the delivery of PureHVNC | IBM