標題：基於雲的惡意軟件傳播：GuLoader的技術迭代過程

GuLoader又稱CloudEyE，是一種Visual Basic Script (VBS) 下載程序，用於在受感染的計算機上傳播遠程訪問木馬，最早於2019年被首次發現。 GuLoader是一個著名的基於shellcode的下載程序，已被用於大量攻擊，主要用於傳輸各類惡意軟件。 GuLoader已經活躍了三年多，目前仍在進一步開發中。最新版本集成了新的反分析技術，這使得檢測變得越來越困難。新的GuLoader樣本在VirusTotal上接收零檢測，確保其惡意有效負載也未被檢測到。

GuLoader的有效負載是完全加密的，包括PE標頭。這允許攻擊者使用知名的公共雲服務存儲有效負載，繞過安全保護，並保持有效負載長時間可供下載。

早期版本的GuLoader是作為包含加密shellcode的VB6應用程序實現的。目前，最常見的版本是基於VBScript和NSIS安裝程序。 VBScript變體將shellcode存儲在遠程服務器上。

GuLoader介紹“封裝”和“加密”服務是專門為抵抗安全產品而設計的。 GuLoader是攻擊者用來逃避安全檢測的最重要途徑。

過去6個月內使用GuLoader的攻擊次數

除了代碼加密之外，GuLoader還利用了許多其他技術，包括反調試和沙盒逃避技術。 GuLoader的一個顯著特徵是加密的有效負載被上傳到遠程服務器。潛在的攻擊者會獲得一個高度保護的基於shellcode的加載程序，該加載程序從遠程服務器下載負載，然後解密並在內存中運行它，而不會將解密的數據釋放到硬盤驅動器中。

儘管谷歌努力阻止GuLoader加密的惡意負載，但在大多數情況下，GuLoader仍然從谷歌硬盤下載負載。下圖顯示了GuLoader在過去一個月使用的不同託管服務的統計數據。

GuLoader在2023年3月至4月期間使用的不同託管服務

有分析表明，GuLoader目前被用來傳播以下惡意軟件：

Formbook

XLoader

Remcos

404Keylogger

Lokibot

AgentTesla

NanoCore

NetWire

早期的GuLoader樣本設法避免了安全產品的檢測，但後來不同的安全解決方案都能夠檢測到它。然而，在網絡安全供應商不斷提高同時，GuLoader的開發人員也在繼續改進他們的產品。

技術細節GuLoader的早期版本是作為包含加密shellcode的VB6應用程序實現的。 shellcode執行加載加密有效負載、解密和從內存啟動它的主要功能。

目前，最常見的版本是基於VBScript和NSIS安裝程序(Nullsoft Scriptable Install System)。

VBScript變體在2022年底介紹的早期版本中，shellcode存儲在VBScript中。

新版本的一個顯著特點是加密的shellcode託管在雲服務(通常是Google Drive)上。 VBScript本身只包含一個小的混淆的PowerShell腳本和大量的垃圾代碼。這使得GuLoader樣本保持非常低的檢測率。

以下是使用GuLoader的VBS變體的感染鏈示例：

使用GuLoader的VBS變體的感染鏈

讓我們考慮一個SHA256 5fcfdf0e241a0347f9ff9caa897649e7fe8f25757b39c61afddbe288202696d5的示例。在2023年3月3日上傳到VirusTotal (VT)時，它從未被檢測到：

上傳兩天后，59家供應商中只有17家將此樣本標記為惡意樣本。

在撰寫本文時，指定的樣本上傳到VT已有3週，下載GuLoader shellcode和下載惡意負載(Remcos)的url仍然很活躍：

讓我們來看看GuLoader VBScript的內部。它包含許多偽隨機註釋和一些無用的命令。清理之後，我們得到的代碼是這樣的：

清理過的GuLoader vbscript

這段代碼的目的是調用PowerShell解釋器，並將“pa0”變量中收集的腳本代碼作為參數傳遞給它。

如果我們在添加省略和連字符後查看“pa0”變量的內容，我們會得到以下腳本：

GuLoader混淆了PowerShell腳本

我們看到這個新腳本包含函數“Gothites9”，它實現了從第二個字符開始以3的步長剪切傳遞的字符串。因此，命令“$Tjene0=Gothites9'OIUlEDiXSa'；”的結果是“IEX”。

字符串$Parrotb以相同的方式轉換。從位置2開始，從該字符串中每隔三個字符獲取一個字符串，該字符串是另一個PowerShell腳本：

刪除第一層混淆後的GuLoader PowerShell腳本

該腳本可以通過使用IEX命令(如果操作系統是32位)調用，也可以作為參數傳遞給從SysWOW64文件夾調用的PowerShell解釋器(如果操作系統是64位)。這是因為GuLoader shellcode必須在32位進程中運行。

可以看到，腳本代碼包含指向Google Drive的URL。

但是，生成的腳本仍然嚴重混淆。腳本以一個用於解碼字符串的函數開始：

GuLoader PowerShell腳本中的編碼字符串

有趣的是，嵌套腳本中的所有行都以編碼形式存儲，除了包含URL的行。

腳本去混淆後，我們得到以下代碼：

GuLoader PowerShell腳本去混淆

現在我們可以看到，腳本分配了2個內存區域，將數據從鏈接下載到Google Drive，並將其保存到臨時文件“%APPDATA%\Umig.For”中。接下來，使用BASE64對下載文件的內容進行解碼。解碼數據的前654個字節被釋放在第一個存儲區域（本例中為“$Gamme2483”），其餘的被釋放在第二個存儲區域中（本例為“$Nulstille”）。前654個字節包含一個混淆的shellcode，它旨在解密第二個複制區域，其中包含加密形式的shellcode的主要部分。

通過使用CallWindowsProc回調函數將控制權轉移到解密器，該函數還接收加密shellcode的地址和NtProtectVirtualMemory函數的地址作為參數。

基於NSIS安裝程序的變體與VBS變體不同，基於NSIS的樣本包含GuLoader shellcode，儘管是以加密的形式。這允許安全研究人員在沙盒中運行示例並查看GuLoader的行為，即使沙盒沒有連接到互聯網。靜態分析NSIS腳本和加密shellcode也是可能的。

在上傳到VirusTotal後，此類樣本現在可以被檢測到。

基於NSIS安裝程序的GuLoader變體的檢測率

我們不會詳細描述這種變體，因為在GuLoader: The NSIS Vantage Point一文中已經對其進行了分析。

GuLoader shellcodeNSIS和VBS變體都使用相同版本的shellcode。與以前的GuLoader版本一樣，shellcode實現了大量的反分析技術：

沙盒逃避技術包括：

掃描內存中與vm相關的字符串；

使用CPUID指令檢查虛擬化環境位是否開啟；

使用RDTSC結合CPUID測量時間；

搜索QEMU相關文件：C:\Program files\QEMU ga\QEMU-ga.exe和C:\Program files\qga\qga.exe；

使用EnumWindows API函數統計Windows的數量；

使用EnumDeviceDrivers API函數檢查是否存在與vm相關的驅動程序；

使用MsiEnumProductsA和MsiGetProductInfoA枚舉已安裝的軟件；

反調試技術：

掛鉤函數DbgBreakPoint和DbgUiRemoveBreakIn，以防止調試器附加；

從使用ThreadHideFromDebugger調用NtSetInformationThread函數的調試器中隱藏主線程ThreadInformation類值；

了解了GuLoader shellcode所使用的技術，在動態分析過程中使用調試器可以很容易地繞過它們。然而，在新版本中，我們遇到了一種使調試和靜態分析都非常困難的技術。

一種新的反分析技術從2022年底開始，GuLoader shellcode使用了一種新的反分析技術，它通過故意拋出大量異常並在將控制權轉移到動態計算地址的向量異常處理程序中處理它們來打破代碼執行的正常流程。

為了拋出異常，代碼使用int3指令。可以實現一個腳本，將int3指令自動替換為跳轉到正確地址的指令：

用jmp指令替換int3指令

該技術在《恶意软件分析：GuLoader剖析揭示新的反分析技术和代码注入冗余》 一文中首次被公開。然而，在新版本中，這項技術得到了改進。 shellcode開始使用三種不同的模式來拋出異常併中斷正常的代碼執行流程。

訪問無效內存地址導致訪問衝突

這種模式非常簡單。首先，作為數學運算的結果，其中一個寄存器被設置為零值。然後shellcode嘗試將數據寫入由該寄存器尋址的內存：

訪問無效內存地址引發訪問違規異常

導致訪問違規異常(0xC0000005)。該異常在GuLoader中由註冊的VEH處理，該VEH計算新地址以繼續執行shellcode。所使用的數字和導致計算零值的數學運算總是不同的。

設置陷阱標誌以引發單步異常GuLoader使用以下指令組合來設置EFALGS寄存器中的TF：

設置陷阱標誌以引發單步異常

乍一看，這段代碼中發生了什麼並不清楚。然而，如果我們計算寄存器EDI中的值，則得到值0x100。接下來的幾個指令的組合旨在推動EFLAGS並將TF (陷阱標誌)位設置為“1”。然後，將堆棧中修改後的值設置回EFLAGS寄存器。

當在EFLAGS寄存器中設置了Trap標誌但未附加調試器時，處理器會在執行下一條指令後生成單步異常（0x80000004）。在GuLoader中，註冊的VEH在這種情況下被調用。但是，如果附加了調試器，則不會調用GuLoader的VEH，並且執行路徑錯誤。

GuLoader shellcode中的代碼塊總是不同的，可以使用寄存器的各種組合。在無效內存地址的情況下，使用的數字和導致在EFLAGS寄存器中計算值0x100來設置TF的數學運算總是不同的。

使用int3引發斷點異常使用int3作為指令進行反分析技術已經在以前版本的GuLoader中實現。然而，它仍然被用於GuLoadershellcode的各個部分。當CPU在沒有調試器的情況下遇到int3指令時，它會生成斷點異常（0x80000003），並調用已註冊的VEH。但是，如果附加了調試器，則控制將轉移到調試器的中斷處理程序，該中斷處理程序通常會暫停程序的執行。 int3指令後面通常是隨機字節，這些字節會破壞shellcode的正常執行：

使用int3引發斷點異常

因此，如果不分析GuLoader VEH的代碼，我們就無法確定正確的執行路徑。

異常處理程序為了在出現3個指定異常的情況下計算新的跳轉地址，並將程序引導到新的執行路徑，GuLoader使用RtlAddVectoredExceptionHandler函數註冊向量異常處理程序（VEH）。

為了了解跳轉地址是如何計算的，讓我們看一下VEH代碼。

與代碼的其他部分一樣，VEH代碼也被混淆了。它包含垃圾指令，並且使用XOR運算動態計算重要值：

混淆的VEH代碼

然而，在IDA中反編譯之後，這段代碼看起來非常簡單：

反編譯的VEH代碼

如上所述，根據異常代碼的不同，VEH操作略有不同。在異常0x80000004 (EXCEPTION_SIGNLE_STEP)和0xC0000005 (EXCEPTION_ACCESS_VIOLATION)的情況下，它從發生異常的指令中獲取偏移量2處的字節值，並將該字節與某個常數值進行XOR（本例中為0x8B）。在異常0x80000003 (EXCEPTION_BREAKPOINT)的情況下，將獲取偏移量1處的字節，並使用常量進行XOR運算。需要注意的是，指定的常數在所有樣品中都是不同的。然後將得到的值添加到異常上下文中的EIP值中。因此，當退出異常處理程序時，控制權將轉移到新地址。

在所有情況下，異常處理程序還會檢查調試寄存器的狀態：

檢查VEH中的調試寄存器

如果設置了任何硬件斷點，異常處理程序將引用零地址而不是ContextRecord地址。這最終會導致應用程序崩潰。

在EXCEPTION_BREAKPOINT的情況下，異常處理程序還在舊EIP和計算出的新EIP值之間的地址空間中查找軟件斷點。

儘管可以使用各種各樣的代碼組合來觸發異常處理程序的執行，但它們都遵循3種模式，我們可以實現一個正則表達式來查找其中的大多數。不過，我們期望GuLoader開發人員在新版本中改變模式。

要修復一條引發異常的指令，並將其替換為跳轉到x32dbg中的正確地址，可以使用以下腳本(必須將0x8B替換為分析示例中的常量值)：

URL解密

所有字符串，包括下載最終有效負載的URL，都被加密並以特定形式存儲在shellcode中：

對於上面的示例，我們去混淆了代碼，清除了垃圾指令和跳轉。實際上，代碼中包含大量的垃圾和無效指令。為了幫助理解混淆的複雜性，這是與前面的示例相對應的原始代碼的一部分：

在嚴重混淆的GuLoader shellcode中合成加密字符串

與字符串不同，解密密鑰存儲為解密函數後面的常規字節序列：

字符串解密XOR密鑰

這個密鑰通常不是很長，最多64字節。

使用帶有解密密鑰的XOR運算對字符串進行解密。解密字符串後，我們可以找到一個看起來像URL但沒有架構的字符串：

很明顯，GuLoader的開發者已經發現了安全研究人員知道了其在已知明文攻擊中使用字符串“http://”或“https://”解密以前版本shellcode中的url的方法，以檢測解密密鑰的第一個字節。因此，在新版本中，他們用隨機字節替換了URL方案。

如果解密後的URL字符串的第5個字節等於“s”，則GuLoader將前8個字節替換為“https://”。否則，它將用“http://”替換前7個字節。

以下是從不同示例中提取的更多URL字符串的示例：

有效負載解密

有效負載解密密鑰也以與加密字符串相同的方式存儲，但是該密鑰沒有被加密。密鑰長度通常在800-900字節的範圍內。

例如，在MD5 40b9ca22013d02303d49d8f922ac2739的示例中，密鑰的長度為844字節。然而，另一個長度用於解密例程，並以混淆形式存儲：

用於解密有效負載的密鑰長度與密鑰存儲的長度不同

GuLoader使用不同的大小，而不是與密鑰一起存儲的大小，來欺騙自動分析。如果我們不考慮這一點，我們只能解密下載有效負載的前843字節，其餘的數據將被破壞。

與以前