勒索病毒
Agenda 勒索病毒擴充武器庫，新增 SmokeLoader 和 NETXLOADER強化攻擊能力
趨勢科技在監控 Agenda 勒索病毒活動的期間發現他們在攻擊行動中使用了 SmokeLoader 惡意程式以及一個我們命名為「NETXLOADER」的最新載入器。
重點摘要
- 本文詳細說明 Agenda 勒索病毒集團如何使用 SmokeLoader 和一個我們命名為「NETXLOADER」的最新載入器。由於新的載入器行為隱匿，因而提高了機敏資料失竊與裝置遭駭的風險。
- 2025 年第一季，我們在美國、荷蘭、巴西、印度和菲律賓的醫療、科技、金融服務以及電信業都觀察到 Agenda 勒索病毒的活動。
- Trend Vision One™ 已可偵測並攔截本文攻擊行動中使用的惡意元件，包括：Agenda 勒索病毒、SmokeLoader 和 NETXLOADER。此外，Trend Vision One 的客戶還可透過追蹤查詢、Threat Insights 及 Intelligence Reports 來取得有關 Agenda 勒索病毒的豐富資訊。
Agenda 勒索病毒幕後的 Qilin 駭客集團自 2022 年 7 月被發現以來便一直都是一項活躍而持續進化的威脅，該集團長期以來已展現了卓越的適應力與強化能力。他們用來開發 Agenda 勒索病毒的程式語言已從 Go 轉移到 Rust，並且加入了一些進階功能，例如：遠端執行、更強的虛擬環境內部擴散能力，以及精密的資安防護躲避技巧。
根據趨勢科技 2025 年第一季的威脅情報資料顯示，Agenda 勒索病毒的活動主要分布在美國、荷蘭、巴西、印度及菲律賓的醫療、科技、金融服務以及電信產業。
2024 年 11 月，我們發現了一起涉及 Agenda 勒索病毒和 SmokeLoader 的攻擊行動，該攻擊使用了我們命名為「NETXLOADER」的最新載入器 (使用 .NET 編譯)。這個名稱反映出它扮演著 .NET 惡意程式載入器的角色，用來啟動攻擊的「下一個階段」。這個載入器採用了 .NET Reactor 6 保護機制，大大增加了逆向工程的複雜度。
本文提供我們對 NETXLOADER 的完整分析，詳細說明其複雜的機制以及它所帶來的威脅。此外，我們也仔細介紹了這個載入器在 Agenda 勒索病毒和 SmokeLoader 相關攻擊行動中的使用方式。
NETXLOADER 技術分析
NETXLOADER 是一個新的 .NET 載入器，在網路攻擊當中扮演著關鍵角色。當它隱藏時，會暗中部署其他惡意檔案，例如：Agenda 勒索病毒和 SmokeLoader。NETXLOADER 採用了 .NET Reactor 6 保護機制，因此很難加以分析。本節說明其複雜的運作方式以及它所帶來的威脅，並提供有關駭客集團進階手法的重要洞察。
NETXLOADER 的背後是一個龐大的惡意網域基礎架構，它刻意利用了看似尋常的檔案命名慣例來躲避偵測。駭客使用動態產生的可拋棄式網域來散播惡意檔案，並且經常模仿一些正常的部落格相關服務來避免起人疑竇。他們使用了像 bloglake7[.]cfd、mxbook17[.]cfd 和 mxblog77[.]cfd 這樣的網域 (以及數十個其他網域)，它們其實都有一個明顯的規律，那就是：使用文字與隨機數字的組合，再搭配信譽不佳的頂層網域 (.cfd、.xyz) 來搭建暫時性的代管平台。這些網域扮演了短暫的散布中心，輪流散播不同的惡意檔案，並且在資安廠商找出其完整基礎架構之前就會消失。
這些惡意程式使用了乍看像隨機產生的檔案名稱，如：rh10j0n.exe 或 ldx39iy.exe，因此很容易混入正常的流量當中。但進一步研究之後，我們發現它們在植入系統之後會有一套系統化的重新命名規則。當檔案被植入受害系統之後，其檔名會去除後半段的隨機字元部分，只保留前面 2 至 3 個字母的前綴 (如：rh、 km、skx、ldx、mtx、pex)，然後再結合「111.exe」這串字。例如：
- rh10j0n.exe → rh111.exe
- ldx39iy.exe → ldx111.exe
這樣的命名規則有兩個目的：首先，它會製造出一種看起來像正常檔案的錯覺。相較於一些明顯可疑的檔案名稱，「mtx111.exe」或「ldx111.exe」這類看起來通用的名稱比較不容易讓人警覺。其次，這樣做可以消除惡意檔案與其檔名之間的關聯性。根據我們在某一起攻擊行動中所看到的，rh111.exe 負責在系統植入 Agenda 勒索病毒，而 ldx111.exe 則負責植入 SmokeLoader，然而，這些前綴並非特定惡意程式家族所獨有。而且未來的攻擊也可能出現相同的命名規則，但散布的卻是完全不同的惡意檔案，視駭客的目的而定。
使用 .NET 編譯的載入器會從解密的資源當中動態載入一個 .NET assembly。接著，它會逐一查看其類別，試圖利用反射 (reflection) 技巧來呼叫一個名稱已加密編碼的方法 (method)：
這個經過高度加密編碼的載入器，其方法 (method) 的名稱採用了毫無意義的字串，再配合隱藏的 MSIL 程式碼，因此幾乎不可能對它進行靜態分析。再加上它使用了 JIT 鉤掛 (hooking) 技巧，所以就更加複雜。確切地說，它會鉤掛 clrjit.dll 函式庫的 compileMethod() 函式。這樣就能在執行時期將預留的方法置換成實際的 MSIL 位元組碼 (bytecode)，進而有效避開傳統的偵測機制，讓資安研究人員的分析流程更加複雜。
之所以有這麼複雜的加密編碼，是因為它結合了 .NET Reactor 第 6 版，這套安全機制運用了控制流程混淆、防篡改、ILDASM 反組譯反制等這類進階技巧，使得逆向工程變得非常困難。
為了解開這套複雜的程式碼，我們使用了 NETReactorSlayer，這是一個開放原始碼的加密編碼解碼器 (deobfuscator) 與解封裝器 (unpacker)，專門針對使用 Eziriz .NET Reactor 保護機制的檔案而設計。藉由這套工具，我們就能克服精密的加密編碼技巧，深入了解載入器的真正功能。
樣本經過解碼之後，就能看到真正的 MSIL 位元組碼。
首先，它會擷取一個用來將惡意檔案解密的資源：
接著，它會將一份清單上的 Windows API 函式轉成一個個的 delegate (委派)，這讓分析變得困難：
以下是這個 NETXLOADER 樣本使用到的 API 函式：
| Delegate 0 | kernel32.SleepEx |
| Delegate 1 | kernel32.OpenProcess |
| Delegate 2 | kernel32.DeleteProcThreadAttributeList |
| Delegate 3 | kernel32.InitializeProcThreadAttributeList |
| Delegate 4 | kernel32.UpdateProcThreadAttributeList |
| Delegate 5 | kernel32.CreateProcessA |
| Delegate 6 | kernel32.GetThreadContext |
| Delegate 7 | kernel32.GetThreadContext |
| Delegate 8 | kernel32.ReadProcessMemory |
| Delegate 9 | ntdll.ZwUnmapViewOfSection |
| Delegate 10 | kernel32.VirtualAllocEx |
| Delegate 11 | kernel32.WriteProcessMemory |
| Delegate 12 | kernel32.SetThreadContext |
| Delegate 13 | kernel32.SetThreadContext |
| Delegate 14 | ntdll.NtResumeThread |
| Delegate 15 | kernel32.CloseHandle |
| Delegate 16 | kernel32.VirtualAlloc |
| Delegate 17 | kernel32.VirtualProtect |
| Delegate 18 | kernel32.VirtualProtectEx |
| Delegate 19 | kernel32.CreateThread |
| Delegate 20 | kernel32.WaitForSingleObject |
| Delegate 21 | ntdll.NtAllocateVirtualMemory |
| Delegate 22 | ntdll.NtCreateThreadEx |
| Delegate 23 | ntdll.NtWriteVirtualMemory |
| Delegate 24 | psapi.GetModuleInformation |
| Delegate 25 | kernel32.GetModuleHandleA |
| Delegate 26 | msvcrt.memcpy |
| Delegate 27 | kernel32.GetCurrentProcess |
| Delegate 28 | kernel32.FreeLibrary |
| Delegate 29 | kernel32.CreateFileA |
| Delegate 30 | kernel32.CreateFileMappingA |
| Delegate 31 | kernel32.MapViewOfFile |
| Delegate 32 | kernel32.DuplicateHandle |
| Delegate 33 | kernel32.CheckRemoteDebuggerPresent |
表 1：NETXLOADER 樣本使用到的 Windows API 函式清單，每個函式都會對應到一個 delegate，藉此達成混淆的目的。
表中包含了各種來自 kernel32.dll、ntdll.dll、psapi.dll 和 msvcrt.dll 的函式，它們大多用來支援處理程序操作、記憶體配置，以及其他系統層次的作業。接下來，NETXLOADER 會建立一個用來解開 AES 加密惡意檔案的解密器：
解密流程首先設定初始化向量 (IV) 和金鑰，然後再建立一個 ICryptoTransform 物件來執行解密。迴圈結構與條件檢查負責確保解密程序的正確設定與執行。解開之後是一個 Gzip 二進位檔案，前端會附上二進位檔案的大小：
NETXLOADER 使用 GZipStream 類別 (class) 來解壓縮二進位檔案。GZipStream 是透過 MemoryStream 來進行初始化，接著設定解壓縮模式 (CompressionMode.Decompress)，然後在迴圈內正確解壓縮資料。
解壓縮後的結果是 NETXLOADER 接下來要實際執行惡意檔案：
載入器會使用 Delegate 16 (VirtualAlloc) 來配置記憶體空間，然後將二進位惡意檔案複製到配置的記憶體內：
接著，它會呼叫 Delegate 17 (VirtualProtect) 來將惡意檔案的記憶體區塊保護設定變更成 PAGE_EXECUTE_READWRITE，讓惡意檔案在修改之後可以被執行。
接下來會呼叫 Delegate 19 (CreateThread) 來產生一個新的執行緒，並立即執行惡意檔案所指的函式：
它會利用 Delegate 20 (WaitForSingleObject) 來無限期等待執行緒終止。
最後，它會自行終止：
上述步驟執行完成之後，它會將其惡意檔案解密，並直接植入記憶體內 ─ 這會是一個勒索病毒、資訊竊取程式，或其他惡意工具之類的模組化惡意程式。NETXLOADER 就是透過這樣的動態 API 呼叫與記憶體操作來躲避偵測。就本文的案例來說，它會同時部署 Agenda 勒索病毒和 SmokeLoader 惡意程式。
Agenda 勒索病毒、SmokeLoader 和 NETXLOADER
下圖說明 Agenda 勒索病毒集團如何在我們觀察到的攻擊行動中使用 SmokeLoader 和 NETXLOADER。
躲避防禦
在第一階段的 .NET 載入器之後，第二階段的 SmokeLoader 就會出現一些類似其先前版本的行為，其中包括許多反制分析的技巧，但修改幅度不大。
T1027 - 加密編碼的檔案或資訊
第二階段的 SmokeLoader 採用了一種被稱為不透明表達式 (opaque predicate) 的反組譯反制技巧。乍看之下，該樣本似乎含有兩個條件式跳躍 (conditional jump)，但它其實只會跳躍到某個絕對位置。這項技巧會讓反組譯器在反組譯第二個條件式跳躍之後的程式碼時，產生不正確或「垃圾」的程式碼。
在這個階段，某些函式仍處於加密狀態，它們只會在需要時才被解密，完成之後會再重新加密。
T1027.007 - 加密編碼的檔案或資訊：動態 API 解析
SmokeLoader 會查看處理程序環境區塊 (Process Environment Block，簡稱 PEB) 來瀏覽 DLL 匯出表、計算每個 API 的雜湊碼，然後與樣本儲存的 API 雜湊碼做比對。當找到相符的項目時，它會從函式庫中取得 API 的位址，然後儲存在 API 對照表中。
T1480 – 執行限制
SmokeLoader 只能在使用 Windows Vista 或更新版 Windows 作業系統的電腦上執行。其作法是讀取 PEB 然後檢查 OSMajorVersion [PEB+0xA4] 旗標。
它會利用 GetKeyboardLayoutList 來找出系統的輸入語言，然後檢查輸入語言是烏克蘭文 (0x422) 還是俄羅斯文 (0x419)，如果是俄羅斯文，惡意程式就會終止。
當 SmokeLoader 以 6A90.vmt 的檔名執行時，它會略過其防除錯、虛擬機器反制、沙盒模擬分析反制等檢查，並將其下一階段惡意檔案注入 explorer.exe (Windows 檔案總管) 處理程序當中。
T1622 - 躲避除錯器
惡意程式會檢查 BeingDebugged [PEB + 0x2] (正在被除錯) 這個旗標的數值來決定接下來要執行哪一個指令。如果此旗標設為 true，就會跳到無效的記憶體位址。
此外，SmokeLoader 還會使用 NtQueryInformationProcess 來檢查處理程序除錯連接埠，看看它是否正在被除錯。
T1134.002 - 存取金鑰操弄：使用金鑰來建立處理程序 (也有可能正在提升權限)
惡意程式的處理程序會檢查自己是否至少擁有中等完整性等級的存取金鑰，如果沒有，則使用 Wmic 來將自己重新啟動。
T1622 - 躲避虛擬化/沙盒模擬分析：系統檢查
SmokeLoader 會利用以下方式來躲避虛擬化與沙盒模擬分析：
- 偵測沙盒模擬分析與資安模組。
- 搜尋已載入的 Sandboxie (sbiedll.dll) 和 Avast Antivirus (snxhk.dll、aswhook.dll 等) 相關 DLL。
- 搜尋虛擬化的痕跡。
- 掃描系統登錄當中是否有 QEMU、VirtIO、VMware、VirtualBox 和 Xen 相關的項目。
- 尋找虛擬化處理程序與硬體。
- 偵測虛擬環境相關的處理程序，並尋找虛擬的硬體元件，如：USB 控制器、滑鼠裝置、繪圖顯示卡，以及記憶體驅動程式。
T1055 - 處理程序注入
當前面提到的所有檢查都不成立時，下一階段惡意檔案就會被注入 explorer.exe (檔案總管) 當中。有別於先前版本的 SmokeLoader，此版本並非使用 PROPagate 來注入。注入程序首先是經由 GetShellWindow、NtOpenProcess 和 NtDuplicateHandle 來取得 explorer.exe 處理程序的代碼 (handle)。接下來，使用 NtCreateSection 在當前的處理程序與 explorer.exe 的處理程序之間建立兩塊共用的記憶體區段。將其中一個區段的屬性設為已修改，另一個區段則留給後續階段使用。
接下來，SmokeLoader 會使用 NtMapViewOfSection 將前面建立的區段對應到當前處理程序與 explorer.exe 的記憶體空間內。如此可確保這些區段所做的任何修改也會同步反映在 explorer.exe 的處理程序當中。最後，它會將下一階段惡意檔案寫入其中一個區段，並設定另一個區段的已修改屬性，然後再使用 CreateThreadEx 在 explorer.exe 的處理程序當中建立一個執行緒。
搜尋
SMOKELOADER 的最後一個階段就是將自己注入 Windows 檔案總管的處理程序中，這個動作是惡意程式執行的重要步驟。一旦注入成功，SMOKELOADER 就會使用 CreateThread API 來建立兩個不同的執行緒。
T1057：處理程序搜尋
第一個執行緒用來監控系統上正在執行的處理程序。它會計算每個處理程序名稱的雜湊碼，並與其程式內寫死的一些工具的雜湊碼做比較。如果惡意程式偵測到其中一個工具正在執行，就會立即終止對應的處理程序。
| 雜湊碼 | 處理程序名稱 |
| FFE73924 | Autoruns.exe |
| A5F0C29D | idaq.exe |
| A5F0C4B7 | idaw.exe |
| 9A412518 | idaw64.exe |
| 44F0F7D3 | OllyDbg.exe |
| A06B2518 | P idaq64.exe |
| 85D6E4EF | ProcessHacker.exe |
| 5ADED7D3 | procexp.exe |
| 8D3AFAC6 | procexp64.exe |
| 52FFD0DD | procmon.exe |
| 8E28921B | procmon64.exe |
| 4FD0CDDC | Tcpview.exe |
| 8EEA688B | Wireshark.exe |
| D99E88CF | x32dbg.exe |
| E79E85C8 | x64dbg.exe |
T1057：應用程式視窗搜尋
第二個執行緒會使用 EnumWindows 函式來檢查所有已開啟的視窗是否顯示特定的標題。如果發現了目標清單上的任何一個分析工具，就會使用 TerminateProcess API 來終止對應的處理程序。此程序需要掃描系統上所有已開啟的視窗，並與目標清單比對。
| 雜湊碼 | 視窗名稱 |
| C8FAD451 | Autoruns |
| 17E7EA18 | OllyDBG |
| D6C4192C | ProcessHacker |
| E4C7FE66 | ProcExpl |
| 3CD53CFF | PROCMON_WINDOW_CLASS |
| CBE1CEF9 | TcpViewClass |
| C3322209 | 目前不明 |
| CBE0E170 | 目前不明 |
表 3：SMOKELOADER 會終止的視窗名稱清單。
幕後操縱
幕後操縱程序首先會檢查系統登錄機碼 Software\Microsoft\Internet Explorer 的 svcVersion 和 version 兩個數值來取得 Internet Explorer (IE) 的 User-Agent。拿到的 User-Agent 會用於後續的 HTTP 請求。
在繼續連線之前，SmokeLoader 會先將 CC 網址解密，該網址使用以下格式來加密和儲存。
T1071.001 應用程式層通訊協定：網站通訊協定和 T1573.001 加密通道：對稱式加密
解密之後，SmokeLoader 會發送 POST 請求到 CC 伺服器。惡意檔案在傳輸之前會先使用 RC4 加密。
如果伺服器可以連上，那它會回應一個 HTTP 404 狀態碼。儘管這看起來好像發生了錯誤，但回應中卻含有指令。只不過，在我們分析的當下，CC 伺服器已經下線，使得我們無法擷取到任何指令。
此外，SmokeLoader 還會連線到以下網址來下載 Agenda 勒索病毒：hxxp[://]mxblog77[.]cfd/777/rh1jcr4[.]exe。
根據我們對 SmokeLoader 檔案的研究顯示它扮演了散布 Agenda 勒索病毒的角色。我們已觀察到 SmokeLoader 會散布 NETXLOADER，而這個載入器有一個版本會在系統上植入 Agenda 勒索病毒，所以 SmokeLoader 與 Agenda 勒索病毒之間有明顯的關聯。
使用 .NET 編譯的載入器會嘗試透過某個特定名稱來載入一個 .NET assembly。如果這個嘗試失敗，就會改用某個解密的數值來載入另一個替代的 .NET assembly。接著，載入器會逐一檢查 .NET assembly 當中的所有類別，並呼叫每個類別當中一個名叫 c0AqjVLHS 的方法 (method)。
它會建立一個批次腳本，將「rh」開頭的執行檔重新命名為「rh111.exe」，並且確保它在執行時指定了「--password」參數。
接下來，最終的惡意檔案 (Agenda 的 DLL) 會透過一種叫「DLL 反射式載入」(DLL reflective loading) 的技術被直接載入記憶體內。此方法可讓 DLL 在不寫入磁碟的情況下被執行。
如需有關最新 Agenda 勒索病毒的完整分析，請點選以下連結來取得詳細的病毒報告：https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/ransom.msil.agenda.thjcobd。
結論與資安建議
Agenda 勒索病毒集團一直在不斷演進並持續增加新的功能來干擾企業營運。其多樣化的攻擊目標包括：網域、已掛載裝置、儲存系統，以及 VCenter ESXi。由於改用了 Rust 來開發程式，因此該集團就能輕鬆攻擊各種作業系統。
它使用客製化的包裝程式，因此有助於躲避偵測並強化它避開掃描工具的能力。值得注意的是，使用 NETXLOADER 可說是駭客在惡意程式散播方面的一大躍進。它使用了一個經過高度加密編碼的載入器來隱藏實際的惡意檔案，這意味著，除非您可以在記憶體內執行其程式碼並加以分析，否則您無法確切知道它到底是什麼。即使是分析字串也沒有幫助，因為加密編碼會打亂一般用來判斷惡意檔案的線索。這樣一來，就很難確切知道惡意程式的散布方式，有時甚至無法正確偵測或將它歸類到某個已知的惡意程式家族。
要主動防範採用 Agenda 勒索病毒、SmokeLoader 和 NETXLOADER 的攻擊，企業應建置一套完整的資安策略，包含以下最佳實務原則：
- 存取控管：唯有在必要時才授予員工系統管理員的存取權限。定期重新檢視並調整權限，盡可能降低未經授權存取的風險。
- 定期更新與掃描：確保所有資安軟體都定期更新，並且定期掃描以發掘漏洞。採用端點防護解決方案來偵測及攔截惡意元件與可疑行為。
- 資料備份：定期備份關鍵資料並建立一套完善的復原計畫。這將是防範勒索病毒攻擊導致資料損失的一項保險措施。
- 電子郵件與網站安全：謹慎處理電子郵件和網站操作，避免下載附件檔案、點選連結或安裝應用程式，除非來源經過檢驗且值得信賴。建置網站過濾來防止使用者存取已知的惡意網站。
- 使用者教育訓練：定期舉辦員工訓練，教導員工如何辨識社交工程技巧，以及了解網路釣魚的危險。這樣的意識可大幅降低被這類攻擊所害的機率。
- 多層式防護方法：採用一套包括端點、電子郵件、網站及網路防護的多層式防禦策略。這套方法有助於防範系統的潛在入侵點，並提升整體威脅偵測能力。
- 沙盒模擬分析與應用程式控管：利用沙盒模擬分析工具在檔案執行之前預先加以分析，確保任何可疑檔案都經過掃描以確認是否有潛在的威脅。強制貫徹應用程式控管政策來防範未經授權的應用程式和腳本執行。
- 監控異常活動：建置資安事件管理 (SIEM) 工具來監控異常的腳本執行與對外連線。這樣的主動監控有助於在威脅升高之前預先偵測並加以防範。
趨勢科技威脅情報
為了隨時掌握不斷演變的威脅，趨勢科技客戶可透過 Trend Vision One™ Threat Insights 來取得 Trend™ Research 有關新興威脅及駭客集團的最新洞見。
Trend Vision One Threat Insights
新興威脅
Trend Vision One Intelligence Reports 應用程式 (IoC 掃描)
- Agenda 勒索病毒的演進：揭發它與 SmokeLoader 的關係以及 NetXLoader 的加密編碼手法
- 揭發 NETXLOADER：一個高度加密編碼的 .NET 載入器技術分析
追蹤查詢
Trend Vision One Search 應用程式
Trend Vision One 客戶可以使用 Search 應用程式來尋找或追蹤本文提到的惡意指標，看看是否也出現在自己的環境中。
在記憶體中執行 Netxloader 二進位檔案
eventSubId: 901 AND objectAppName: DotNet AND (tags: MITRE.T1055 OR tags: XSAE.F4193)
AGENDA 產生的記錄檔
(eventSubId: 101 OR eventSubId: 109) AND objectFilePath: /\\AppData\\Local\\Temp\\QLOG\\ThreadId.*LOG/
除此之外，Trend Vision One 客戶還可啟用 Threat Insights 權利來取得更多追蹤查詢。
入侵指標 (IoC)
如需本文提到的入侵指標完整清單，請至此處。