本期講解嘉賓

近年來，無文件攻擊和基于內存的攻擊變得越來越火熱。根據研究機構的統計，2022年的無文件攻擊相較于2021年，其增長速度超過了900%。需要注意的是，無文件攻擊并不代表真的沒有文件，而是一種攻擊策略，旨在避免將真正的惡意代碼放在磁盤上以避免被安全檢測發現。所說的無文件，也未必是攻擊全程無文件，而是其中的一部分采用了基于內存的攻擊。

無文件攻擊給傳統安全軟件的檢測帶來了極大的挑戰，特別是對靜態檢測引擎來講，在整個攻擊過程中，能用于掃描的文件惡意代碼成分比較少，真正的惡意部分都直接在內存中執行，所以對抗類似的現代威脅需要新的思路和產品。

華為終端檢測與響應EDR團隊在實際運營過程中發現，遠控類無文件木馬已經成為現網中最大的安全威脅。這種木馬數量龐大，花樣繁多，部分高級樣本甚至借鑒了”三十六計”的軍事思想，想方設法地隱蔽自己，對抗文件和內存檢測。下面選取有代表性的樣本進行分析，以饗讀者。

白加黑遠控木馬是一種由黑產組織利用技術漏洞繞過終端安全軟件的攻擊手段，他們替換正常軟件安裝包并釋放白加黑遠控木馬，從而控制用戶的電腦。這種攻擊手段猶如“三十六計之李代桃僵”的實現，已經由來已久，但由于其繞過終端安全軟件的概率很高，所以仍然被廣泛使用。最近，黑產組織“銀狐”和“金眼狗”在國內用戶中變得越來越活躍，他們的攻擊行為對用戶的網絡安全構成了巨大威脅。

白加黑實際上是民間對一種DLL劫持技術（DLL Hijacking）的通俗稱呼。所謂的“白加黑”，其實來說是“可信EXE”加“惡意DLL”。可信EXE一般是帶有數字簽名的正常EXE文件，那么“惡意DLL”當然是指與EXE在同一個目錄下的惡意DLL文件。病毒借助那些帶數字簽名的知名程序去加載自己帶有惡意代碼的DLL文件，便繞過殺毒軟件的主動防御，從而達到正常加載運行的目的。如果第三方軟件在編寫時未對調用的DLL文件進行校驗，那就很容易被木馬利用產生DLL劫持。

那么，為什么會發生DLL劫持呢？當一個Windows可執行文件運行時，PE Loader負責將DLL加載到進程的地址空間中。加載器會分析可執行文件的輸入表，并找出其需要的DLL文件，并隨后將它們一一加載。由于輸入表中只包含DLL的名稱而沒有其完整路徑，因此加載程序首先會在磁盤上搜索DLL文件。它會從當前程序所在的目錄開始搜索，如果未找到，則會在Windows系統目錄中查找，最后會在環境變量中列出的各個目錄下查找。惡意程序利用這個特點，先偽造一個與正常DLL文件同名的DLL，并提供相同的導出函數。這樣，當程序試圖加載DLL文件時，它將優先調用當前目錄下偽造的DLL，并執行黑客提供的導出函數。這個過程用個形象的詞來描述就是，DLL文件被劫持了。

下文以華為終端檢測與響應EDR團隊在現網中發現的白加黑遠控木馬為例，分析木馬的主要流程。該木馬冒充正常的Telegram軟件安裝包，并通過搜索引擎打廣告的方式提升網站排名，引誘用戶到惡意網站下載假安裝包。一旦安裝包執行，就會將白加黑木馬釋放到User目錄下，如圖1-1所示。

圖1-1白加黑木馬釋放的位置

在這個目錄中，存在一個被簽名的正常程序see.exe和一個名為libcurl.dll的文件，其中libcurl.dll包含少量惡意代碼。該代碼的作用是將加密文件readme.dat解密后反射加載到內存中執行。這意味著殺毒軟件的靜態檢測很難發揮作用，而行為防御也只能檢測到白名單程序的行為，因此這給檢測帶來了巨大的挑戰。

如圖1-2所示，see.exe被執行后，惡意libcurl.dll會被加載，該惡意DLL內導出函數會執行shellcode解密readme.dat文件。

圖1-2白加黑木馬執行流程

readme.dat實際是一個DLL文件，使用簡單的異或加密。shellcode解密后會直接跳到DLL的反射加載Loader函數。該函數負責修復DLL的導入表和重定位表，然后再跳到入口點執行，如圖1-3所示。

圖1-3shellcode流程

反射加載器會從進程PEB結構中找到LDR_DATA成員，該成員包含三個雙向鏈表，用于記錄進程加載的模塊信息。然后，加載器會從中獲取kernel32.dll的基址，并遍歷其導出函數，找到GetProcAddress和VirtualAlloc的地址。接著，加載器會分配內存，并將DLL文件主體代碼復制到該內存中。最后，加載器會修復DLL的導入和重定位表，如圖1-4所示。

圖1-4反射加載器執行流程

修復完成后，反射加載器的使命已經結束，隨后會將控制權交給已經在內存中加載的DLL。到這一步，用戶的電腦已經被遠程控制，其數據和財產都即將面臨重大損失。

如今大多數終端防護軟件都實現了用戶態API HOOK。Hook英文翻譯過來就是鉤子的意思，在Windows操作系統中，它維護著自己的一套事件流程機制，該機制由大量的系統API函數支撐。應用程序實現某個具體功能，也是調用系統API函數根據事件流程一步步地向下執行。而鉤子的作用就是在事件傳送到終點前截獲API函數并監控事件的傳輸，就像一個鉤子鉤上事件一樣，并且能夠在鉤上事件時處理一些自己特定的邏輯。

HOOK的這個本領使終端安全軟件能夠將自身的代碼融入到被鉤住（Hook）的程序的進程中，成為目標進程的一個部分，并重定向Windows API（例如NtWriteVirtualMemory，這是惡意程序慣用函數，可將指定代碼到其他的進程。）到自身的代碼。這樣，安全軟件就能夠檢查函數參數及其上下文，判斷是否需要阻止或允許該函數繼續執行自身流程。

API HOOK技術上可以細分為不同類型，包括內聯API掛鉤、導入地址表（IAT）掛鉤、導出地址表（EAT）掛鉤、SSDT掛鉤等。在微軟引入內核補丁保護（KPP，又名Patch Guard）之前，防病毒產品一般使用SSDT掛鉤。出于操作系統穩定性的考慮，微軟通過Patch Guard阻止了對SSDT表的修改，導致安全產品紛紛轉戰用戶態HOOK。

圖1-5展示了NtWriteVirtualMemory是如何被安全軟件HOOK后重定向到其自身邏輯的。安全軟件修改了函數的前幾個字節，利用JMP指令跳到自身處理流程，處理完成后再跳回原始函數執行。為了避開安全軟件的HOOK，惡意程序采用了“三十六計之瞞天過?！辈呗?，并利用各種高級技術手段，紛紛涌現出了可以繞過終端安全軟件HOOK的惡意程序。其中，直接使用系統調用來繞過HOOK的惡意軟件尤為突出。

圖1-5NtWriteVirtualMemory
被安全軟件HOOK后的結果

在現代Windows操作系統中，代碼的運行級別被分為兩個特權級：RING 0和RING 3。通常我們把RING 3稱為用戶層，RING 0稱為內核層。應用程序運行于用戶層，并通過操作系統提供的應用程序接口（API）獲得各種運行的支持。用戶層與內核層的數據是隔離的，用戶層無法直接訪問內核層的數據。

如圖1-6所示，在Windows系統上，實際上使用了其中的兩個環。應用程序運行在用戶模式，相當于Ring 3；關鍵系統組件（如內核和設備驅動程序）運行在內核模式，對應Ring 0，操作系統通過系統調用實現用戶層和內核層代碼的切換，具體來講是由ntdll庫文件封裝了系統調用序號，并負責切換到內核模式。

圖1-6特權級別

從圖1-7中，我們可以看到ntdll中的大多數系統API的實現非常簡單，只需要進行參數賦值后，就直接將系統調用號保存到寄存器中，然后調用syscall指令切換到內核模式。然而，這種簡單的實現方式也為惡意程序提供了機會，它們可以輕松地按照這個模板獲取函數的系統調用號，并直接調用syscall指令來完成指定功能，從而繞過了安全軟件對函數頭字節的修改和重定向。

圖1-7系統調用序號

圖1-8展示了華為終端檢測與響應EDR團隊在現網發現的一個CobaltStrike遠控木馬運用直接系統調用繞過安全軟件的檢測。

圖1-8CobaltStrike
遠控木馬運用直接系統調用

木馬啟動后，首先讀取PEB->LDR_DATA結構，找到ntdll.dll的基地址。接著，在ntdll的導出表內循環比較預置的API HASH，該hash使用djb2算法生成。木馬查找的函數主要包含一些內存操作API，如NtAllocateVirtualMemory、 NtProtectVirtualMemory等。當找到目標函數后，在函數體內比較機器碼（0x8B、0xD1、0xB8），這三個碼恰好對應了上述函數體內的mov r10、rcx指令。匹配成功后，下一條指令中正好保存了函數的系統調用號，從而可以被木馬獲取。此技術也被業內稱為Hell's Gate （地獄之門）。

但是現實環境往往比較復雜，木馬仍有可能遇到一些挑戰，例如安全軟件已經HOOK了需要調用的函數，導致函數的前5字節已經被破壞，這使得木馬無法通過搜索機器碼的方式獲取系統調用號。在這種情況下，該樣本還應用了其他技術。

如圖1-9所示，Ntdll導出的函數中，有個規律是對應的函數系統調用號是根據函數地址從上到下逐漸遞增分配的。

圖1-9遞增的系統調用號

木馬在判斷函數被HOOK后，會搜尋周圍沒有被HOOK的函數，并根據上下文關系計算出所需函數的系統調用號，如圖1-10所示。

圖1-10木馬搜尋系統調用號的過程

此技術在業內也被稱為Halo's Gate （光環之門）。

隨著終端安全軟件對內存空間檢查的深入，一些比較流行的內存執行手段已經被防守方注意到并加以攔截，比如在內存中突兀的RWX內存塊。在此背景下，高級攻擊者開始部署越來越復雜的方法來將惡意代碼隱藏在正在運行的系統上。其中一種技術就是華為終端檢測與響應EDR團隊在現網遠控樣本上觀察到的Module Stomping“模塊踩踏”技術，它會用惡意代碼覆蓋已加載的動態庫模塊，從而掩飾自己在內存中的痕跡。

傳統的進程注入或者內存加載技術一般會涉及到多個敏感API調用，比如CreateRemoteThread 、WriteProcessMemory 、VirtualAlloc 、VirtualProtect等。這會帶來兩個問題，首先是這些敏感API容易被安全軟件攔截，另外一個是內存中往往會有新增的帶有可疑權限的模塊。而模塊踩踏技術不會主動進行內存分配，也沒有異常的反射加載事件，因此想依靠一些簡單的IOC來檢測會非常困難。

為了實現模塊踩踏，木馬會先加載一些它不需要的合法模塊。接著，它會在模塊代碼段中尋找空閑區域，并將該區域的權限更改為可寫。最后，木馬會將惡意代碼復制到該區域，并將權限修改為可讀可執行。這樣，惡意代碼就能隱藏在合法模塊內存中，而且不會增加新的內存區域，權限也是合法的。這種策略類似于《三十六計》中的“借刀殺人”，讓安全軟件難以檢測和防御。安全軟件的內存掃描需要對照合法模塊的硬盤文件與內存范圍來檢測，這對于實時掃描器來說是一項巨大的性能挑戰。

如圖1-11所示，惡意模塊會加載user32.dll，并搜尋代碼段上的空閑區域。

圖1-11惡意模塊搜索空閑區域

搜索到空閑區域后，修改內存權限，將惡意代碼寫入并跳轉執行，如圖1-12所示。

圖1-12惡意模塊搜索到空閑區域后的行為

至此，惡意代碼已經被執行，但是從內存中看來不會有什么異常區塊，給安全軟件帶來相當大的檢測難度。

華為終端檢測與響應EDR在與后門的對抗中，逐步形成了獨特的思路和打法。通過輕量級的終端Agent截獲終端的API、進程、網絡、文件等系統行為，并結合獨創的內存威脅溯源圖，對全攻擊鏈路進行行為分析，實現對后門木馬的精準檢測與關聯，最終將整個攻擊鏈路展示在圖上，方便用戶進行溯源、事件響應等。