通過交叉驗證堆棧和VAD信息檢測Windows代碼注入

摘" 要：Windows 32/64位代碼注入攻擊是惡意軟件常用的攻擊技術，在內存取證領域，現存的代碼注入攻擊檢測技術在驗證完整性方面不能處理動態內容，并且在解析內存中數據結構方面無法兼容不同版本的Windows系統。因此提出了通過交叉驗證進程堆棧和VAD信息定位注入代碼方法，將基于遍歷棧幀得到的函數返回地址、模塊名等信息結合進程VAD結構來檢測函數返回地址、匹配文件名以定位注入代碼，并且研發了基于Volatility取證框架的Windows代碼注入攻擊檢測插件codefind。測試結果表明，即使在VAD節點被惡意軟件修改，方法仍能夠有效定位Windows 32/64位注入代碼攻擊。

關鍵詞：VAD;堆棧;Windows代碼注入;內存取證技術

DOI：10.15938/j.jhust.2024.02.006

中圖分類號： TP319

文獻標志碼： A

文章編號： 1007-2683（2024）02-0043-09

Detect Windows Code Injection by Cross-validating

Stack and VAD Information

ZHAI Jiqiang，" HAN Xu，" WANG Jiaqian，" SUN Haixu，" YANG Hailu

（School of Computer Science and Technology， Harbin University of Science and Technology， Harbin 150000， China）

Abstract：Windows 32/64-bit code injection attacks are a common attack technique by malware. In the field of memory forensics， the existing code injection attack detection technologies cannot handle dynamic content in terms of verification integrity， and cannot be compatible with different versions of Windows systems in terms of parsing data structures in memory. Therefore， the method of locating injected code through cross validation of process stack and VAD information is proposed. The method first obtains data based on traversing stack frames， such as function return address， module name and other information. Then the data is combined with the process VAD structure to detect the function return address and match the file name to locate the injected code. And developed a Windows code injection attack detection plug-in codefind based on the Volatility forensics framework. The test results show that the method can effectively locate Windows 32/64 bit injected code attacks even if the VAD node is modified by malware.

Keywords：VAD; stack; Windows code inject; memory forensics

收稿日期： 2022-05-06

基金項目： 國家自然科學基金（61403109）；黑龍江省自然科學基金（F2016024）；黑龍江省高等教育教學改革研究重點委托項目（SJGZ20220086）；黑龍江省高等教育學會高等教育研究課題（23GJYBB080）.

作者簡介：

韓" 旭（1997—），男，碩士研究生；

王家乾（1997—），男，碩士研究生.

通信作者：

翟繼強（1972—），男，博士，教授，碩士研究生導師，E-mail：zaijiqiang@163.com.

0" 引" 言

內存取證是對計算機系統物理內存內容進行分析以獲取諸如故障或惡意活動來源等信息的技術［1］。Windows 內存空間分為內核空間和用戶空間，系統相關的進程運行在內核內存空間，而用戶相關的進程在用戶和內核空間之間切換，以便獲得對資源的訪問［2］。因此，惡意軟件為了獲得對資源的訪問權，會破壞用戶空間中正在運行的進程。內存取證調查有助于了解系統上運行的惡意進程［3］。

惡意軟件常用代碼注入技術來運行惡意代碼同時隱藏其在受害者系統上的存在，還可以將執行敏感操作的代碼注入到有特權的進程中以繞過安全應用軟件的檢測［4-5］。以往的Windows代碼注入檢測主要專注于x86平臺，然而Windows 10×64的普及，對代碼注入技術產生了一定影響。隨著物理內存大小的增加，取證人員需要對每個案例分析的數據量越來越大，增加了安全事件響應所需的周轉時間。在確保不遺漏重要的取證信息前提下，通過交叉驗證減少提交給分析人員的數據量有利于分析人員進行有效分析以確定攻擊的來源、意圖和損害［6］。

現有研究方法在完整性驗證方面，已經解決了可執行代碼和IAT/EAT的完整性問題。通過比較目標代碼中的內容和原始版本中的可用內容來檢查完整性。White等［7］提出了一種基于VAD自動比較內存中加載的PE文件與磁盤上的實際文件的方法來檢測惡意軟件所做的修改，該方法在惡意軟件影響代碼或ITA/EAT的情況下非常有效，但只能處理靜態部分，大量的內存所包含的動態內容會在執行過程中會發生更改［8］。在解析內存中數據結構方面，Dolan-Gavitt［9］提出使用VAD解析映射文件并通過PTFinder程序實現該方法。在Dolan-Gavitt的基礎上，Baar等［10］明確了三種從內存中恢復映射文件的方法，但方法只適用于Windows XP 32位系統，隨著Windows版本更新VAD樹結構也有所改變。Arasteh等［11］首次在內存取證角度分析堆棧內存，并提出恢復進程執行歷史的方法，在IDAPro中通過插件實現該方法。在Arasteh研究的基礎上，Hejazi等［12］等提出利用應用程序使用的API調用和相關的堆棧調用分析來識別內存轉儲中的敏感信息的方法，但是當程序不直接調用API時方法失效。Monnappa［13］提出了通過比較PEB和VAD信息的方法來檢測惡意代碼，然而發現當VAD節點被惡意修改時該方法失效。

針對以上檢測代碼注入方法的局限性，提出通過交叉驗證進程堆棧數據和VAD信息檢測Windows代碼注入。經測試，即使當頁面保護或相關VAD信息被修改時，方法仍能有效檢測Windows 32/64位代碼注入攻擊。

1" Windows代碼注入分析

惡意軟件利用代碼注入技術操縱其他進程并隱藏其存在，如遠程DLL注入和進程hollowing等。通過對代碼注入惡意樣本逆向分析發現，在不同的代碼注入手段中有兩處相同點：

1）在目標進程中分配內存空間，并提供執行注入代碼所需的正確保護。

2）獲取程序執行流程以執行所注入的惡意代碼。

注入進程可以調用VirtualAllocEx（或NtAllocateVirtualMemory）在目標進程中分配新的內存（可讀、可寫或可執行）或在目標進程中指定一個已分配的內存用于覆蓋，被指定覆蓋的內存可以是堆棧或堆。

進程內存空間的信息存儲在VAD中，通過檢查VAD類型（VadS、Vad或VadL）和相應的頁面保護（PAGE_EXECUTE_READWRITE等）來確定進程是否被注入是代碼注入檢測的一種方法。然而VAD的保護字段是在第一次保留或提交時為該范圍內所有頁面指定的初始保護，惡意軟件可以通過分配初始保護為PAGE_READONLY的內存空間，在執行惡意代碼時修改為PAGE_EXECUTE_WRITECOPY來避免被檢測。此外，惡意軟件還可以在執行后刪除相關的VAD信息，以保持隱蔽性。線程調用堆棧包含程序執行的關鍵信息，因此，即使進程VAD包含檢測代碼注入所必要的信息，也不能完全依賴它。從而引入堆棧分析，即使初始的內存區域的保護與當前狀態不同，也可以使用堆棧信息和VAD交叉驗證檢測惡意軟件對合法進程的內存空間所做的修改。

2" 檢測Windows代碼注入

根據對代碼注入分析的結果，在目標進程中分配內存空間并竊取目標進程執行流程是代碼注入技術的特點。因此代碼注入攻擊會同時在進程VAD和進程堆棧中留下痕跡。

2.1" 堆棧分析

堆棧的作用是將參數從調用方的子例程傳遞給被調用方的子例程，存儲子例程的局部變量、子例程結束后程序的控制權應轉移到的地址（返回地址）。棧通常分配給進程執行的每個線程，因此每個線程都有自己的棧。由于返回地址表示了程序的執行流程，所以對于堆棧的分析，主要是針對函數棧幀中的返回地址所進行展開。

2.1.1" WoW64進程堆棧分析

WoW64（Windows-on-Windows 64-bits）進程調用一個函數時，傳遞給該函數的參數、返回地址、前棧幀指針寄存器值以及局部變量都存儲在堆棧上，對局部變量的訪問基于Ebp執行，如圖1所示。函數棧幀通過棧幀指針（Ebp）以鏈式形式所串連，并且各函數的棧幀是連續的。在得到棧幀指針的內容后，可以通過遍歷Ebp鏈的形式獲取函數的返回地址。

WoW64堆棧分析算法如算法1所示，從進程對象EPROCESS開始訪問線程及其調用堆棧。EPROCESS的Pcb字段記錄了關于進程調度的信息，由內核結構KPROCESS維護。KPROCESS中的ThreadListHead字段維護著一個數組的起始地址，該數組條目記錄了KTHREAD結構的起始地址，ETHREAD.TrapFrame對象保存著Windows架構下的線程的執行上下文，由結構體_KTRAP_FRAME維護。在獲取到棧幀指針寄存器后通過增加0x4偏移計算函數返回地址。

算法1：WoW64進程堆棧分析

輸入：EPROCESS進程對象E

輸出：WoW64進程堆棧信息S1

1 LoadAddressSpace（）

2 kthread lt;— getKthread（E）//獲取線程對象

3 context lt;— kthread.TrapFrame/*獲取線程執行上下文*/

4 if context not NULL：

5" current_ebp lt;—context.Ebp//獲取棧幀指針

6" while current_ebp：

7 if is_valid_address（current_ebp） and is_valid_address（ current_ebp + 4）：/*判斷棧幀指針及相鄰內存是否有效*/

8" "reture_addr lt;— ［current_ebp + 4］/*計算函數返回地址*/

9" "S lt;— getInformation（reture_addr）

10" end if

11" "end while

12" end if

2.1.2" 64位進程堆棧分析

在Windows×86中，除了fastcall之外的所有調用約定都將所有參數存放在堆棧上。在經過x86和x64堆棧的差異對比分析后，總結出x64堆棧內存布局如圖2所示：

1）不同于x86堆棧，在x64堆棧中Rsp代替Ebp用作為棧幀指針，Rbp作為通用寄存器使用，對局部變量的訪問也改為基于Rsp執行。各函數棧幀雖按序排列但不再以鏈式形式串連。

2）fastcall是x64上默認的調用約定，調用約定將前4個參數存放在寄存器中（RCX、RDX、R8和R9），其余參數放在堆棧中。

3）使用alloca函數分配的棧空間位于局部變量與參數之間。

這使得為x64設計payload變得更加困難，因為這樣的payload必須額外控制寄存器才能調用一個函數。在x86中，payload只需要按照函數調用成功的順序正確地安排堆棧，這可以由單字節指令POP A （opcode 0x61）簡單地處理，但該指令在x64模式下是不可用的。

Windows 64位PE文件中的.pdata節對應于RUNTIME_FUNCTION結構，該結構描述了當前函數的范圍和指向當前調用堆棧展開結構UNWIND_INFO的指針。UNWIND_INFO結構包含可變數量的UNWIND_CODE 結構，UNWIND_CODE中的CodeOffset和UnwindOp字段描述了棧幀大小。因此，本質上，UNWIND_CODE是函數序言的元數據。64位進程堆棧分析算法如算法2所示，利用線程執行上下文結構獲取棧幀指針寄存器、函數序言元數據計算函數棧幀大小后，獲取函數返回地址并根據返回地址確定函數名及其所在模塊。

算法2： 64位進程堆棧分析

輸入：EPROCESS進程對象E

輸出：64位進程堆棧信息S2

1 LoadAddressSpace（）

2 kthreadlt;— getKthread（E）

3 contextlt;— kthread.TrapFrame

4 if context：

5" current_rsp lt;—context.Rsp//獲取棧幀指針

6" while current_rsp：

7" if is_valid_address（current_rsp） and is_valid_address（current_rsp + 8）：/* 判斷棧幀指針及相鄰內存是否有效*/

8" "runt_funclt;— getPdata（）/*獲取RUNTIME_FUNCTION結構體*/

9""" "size_of_frame lt;— getSize（runt_func）/*計算棧楨大小*/

10" reture_addr lt;— ［current_rsp + size_of_frame + 8］//計算函數返回地址

11""" "S lt;— getInformation（reture_addr）

12" "end if

13" "end while

14" end if

堆棧分析也能夠解析殘余棧幀，既由已執行完畢的函數所創建的、但其內存空間沒有被覆蓋的棧楨。解析殘余棧幀可以幫助分析在獲取內存鏡像之前所執行的惡意代碼。

2.2" 進程VAD分析

虛擬地址描述符（VAD）是一個樹狀數據結構，如圖3所示。操作系統使用VAD來存儲關于進程內存區域的信息。VAD描述了關于內存映射文件的名稱、內存區域中的頁面和最初分配的權限的信息。分配/保留的內存區域在進程請求訪問它之前不會被提交，這使得操作系統能夠有效地管理內存。

EPROCESS結構用于標識有關進程映射信息的物理位置，結構下的VadRoot字段指向VAD樹的根節點。在不同版本的Windows系統上VAD的節點描述可能不一致，但是本質可以分為VadS （_MMVAD_SHORT）、VAD （_MMVAD）和VadL （_MMVAD_LONG）三種類型的節點，用于存儲進程相關信息。Tag字段是上述三種節點結構的共有字段，用來描述該節點類型。在Windows 10 以下的版主中，_MMVAD和_MMVAD_LONG結構中的Subsection字段被操作系統用來描述映射到該區域的文件或DLL信息；Windows 10各版本中均不再對VadL節點進行維護。如圖3所示，VAD節點中的StaringVpn 和EndingVpn 字段描述了分配的起止地址，對于_MMVAD和_MMVAD_LONG，可以找到記錄內存區域的_CONTROL_AREA地址，如果該內存區域用于映射文件，則可以引用相應的_FILE_OBJECT結構提取文件對象信息。由于VadS不需要存在于磁盤上，不能存儲關于映射文件的信息，所以其通常被shellcode使用。

2.3" 定位Windows代碼注入

檢測代碼注入攻擊的一種方法是首先使用VAD解析進程內存，然后使用簽名搜索內存空間中的惡意代碼［12， 19］。這種方法的缺點是，需要事先收集惡意代碼信息。此外，這種方法是資源密集型的，因為必須對整個進程內存進行檢查。不同于White所使用的交叉引用［6］，本文所提出的方法摒棄了VAD保護字段可被惡意軟件修改的局限性，結合進程的堆棧信息和VAD信息以檢測Windows代碼注入，檢測算法如算法3所示。

算法3：代碼注入檢測

輸入：進程堆棧信息S1、S2

輸出：代碼注入信息I

1 LoadAddressSpace（）

2M lt;— getVADTree（E.VadRoot）

3 for m in M：//遍歷VAD節點

4 start lt;— m.StaringVpn

5" endlt;— m.EndingVpn

6" if S.return_addr in Range（start，end）：/*判斷函數返回地址是否在VAD節點中*/

7if getInfo（m.Subsection.ControlArea） is TURE：//判斷ControlArea類型

8" blt;—getFile（m. FileObject ）

9" "if b is 1：//判斷文件信息

10" "Ilt;— getInject（m， S.return_addr）

11else

12" "t lt;—getMatch（m.FileObject， S.Moudle）/* 匹配堆棧和VAD分析結果*/

13" "if t is False

14" I lt;— getInject（m， S.return_addr）

15" "else

16" "if StackAnal（S.return_addr） is False/*在VAD節點被修改時轉為堆棧分析*/

17" "I lt;— getInject（m， S.return_addr）

18" end if

19" "end if

20" end if

21 end for

如算法3所示，堆棧分析方法所獲取到的信息作為交叉驗證的一部分輸入到代碼注入檢測方法中。首先通過VAD節點中StaringVpn和EndingVpn字段確定函數返回地址在VAD樹中的位置，若VAD節點被惡意軟件破壞則利用堆棧分析，檢測敏感函數以判別代碼注入。

正確的函數返回地址應該被一個文件（該文件可以是EXE或DLL類型）所映射。當確定函數返回地址在進程VAD樹中的位置后，利用節點中的ControlArea字段獲取函數返回地址所對應的文件對象信息。若函數返回地址位于一個沒有映射到任何文件對象的頁面內，那么表明存在直接注入到內存中的代碼。

最后對比堆棧分析所得到的文件信息與VAD分析所得到的文件信息，若對比失敗則表明進程的內存空間已被惡意代碼修改。

3" 插件實現

Volatility取證框架是一個開源的工具集，在GNU協議下通過Python語言實現，用于從易失性存儲器（RAM）樣本中提取數字信息［14］。本文基于Volatility取證框架提供的基礎功能，實現了檢測Windows代碼注入的插件codefind，具體執行步驟如下：

步驟1：讀取內存樣本的配置文件信息；

步驟2：讀取進程信息，加載地址空間；

步驟3：利用堆棧分析方法解析進程線程調用堆棧，獲得棧幀信息；

步驟4：通過VAD節點信息與堆棧信息交叉驗證檢測代碼注入；

步驟5：輸出進程線程調用堆棧信息以及檢測結果。

其中堆棧分析方法最為關鍵，決定了之后的數據交叉驗證是否有效，以及在VAD節點被修改情況下的取證分析。檢測代碼注入分析方法的流程圖如圖4所示。

將惡意軟件Kronos 在Windows 10×64 15063中運行后利用內存轉儲工具獲取內存轉儲文件分析［15］，codefind插件在Volatility框架下運行結果如圖5所示。

在此案例中，explorer.exe進程被注入了惡意代碼。根據輸出中包含函數返回地址及其所在模塊信息，其中返回地址為0x0309ee11、0x0309f08b、0x0309c1eb和0x0309c33d的函數未匹配到任何文件對象，意味著與函數返回地址對應的代碼并沒有從磁盤加載，而是被注入到進程內存空間中。因此實現的插件能夠通過比較堆棧和VAD數據信息中的不一致來識別內存中的注入代碼區域。

4" 插件測試及分析

4.1" 有效性測試

本文將內存取證領域現存的代碼注入檢測插件做了分析和整理，提煉出如表1所示的插件與本文所研發的插件codefind進行對比分析。

表1" 對比插件及其檢測類型

Tab.1" Contrast Plugins and Their Detection Types

對比插件檢測類型

hollowfind［16］檢測不同類型的進程hollowing攻擊

threadmap［17］檢測進程hollowing攻擊和線程指向的匿名VAD

malfofind［18］檢測進程hollowing攻擊

Psinfo［19］通過檢查父進程、命令行參數、可執行路徑和VAD保護來檢測可疑進程

malthfind檢測指向匿名內存區域的調用堆棧地址

malfind［19］檢測既有執行權限的VAD節點

表2列出的可執行文件實現了現存的Windows代碼注入技術，并將可執行文件分為32位與64位進行有效性測試。

將可執行文件分別在Windows內核版本16399×64、17134×64和18363×64上運行，利用內存轉儲工具獲取內存樣本后使用各插件分析［15］。插件對于特定可執行文件的結果如表3所示：第1個大寫字母表示所有注入可執行代碼的進程，第2個小寫字母表示所有注入的可執行內存區域。字母所對應的插件檢測結果如下：

A/a： 所有進程/頁面被識別。

N/n： 沒有進程/頁面被識別。

P/p： 部分進程/頁面被識別。

F： 結果為假陽性。

其中_m表示初始化內存時所分配的保護為READONLY，在執行惡意代碼時更改為EXECUTE_READWRITE。_32和_64表示可執行文件類型位32位或64位。

分析結果表明，沒有插件能夠檢測到包含注入代碼的所有內存區域。除Gargoyle_m_32外，無論可執行文件類型（32位或64位）或內存區域執行狀態是否被修改，codefind插件都可以有效檢測到代碼注入所在的內存頁面。由于Gargoyle首先將shellcode寫在數據頁面中，隨后利用Ret2libc技術繞過數據執行保護機制以執行惡意代碼，導致codefind插件沒有檢測到被Gargoyle隱藏的堆棧信息。在檢測進程hollow方面，hollowfind和malfofind無論執行權限是否修改都能夠準確檢測到包含注入代碼的所有內存區域，但是對于其他注入手段檢測失敗；malthfind對于64位可執行文件檢測全部失效，對于32位可執行文件檢測也并不準確；malfind在執行權限被修改后檢測效果大幅下降；threadmap和Psinfo對于32位可執行文件的檢測效果優于64位可執行文件。

4.2" 應用實例測試

本文選取了近年來包含代碼注入行為并實現自我隱藏的惡意軟件樣本：

1）Form Grabber：惡意軟件的主線程枚舉目標操作系統上正在運行的進程以查找注入的目標進程，匹配到目標進程后在其進程地址空間分配可執行的內存空間以存儲解密后PE文件，最后調用CreateRemoteThread（）使得注入的線程開始運行。

2）Kronos：Kronos在進行注入時取決于系統架構。在Windows 32位系統中創建一個具有EXECUTE_WRITECOPY共享內存區域和EXECUTE_READWRITE內存區域的新進程explorer.exe并將自身映像注入其中，而在Windows 64位系統中在%ProgramFiles（×86）%＼＼Internet Explorer下創建WoW64進程explorer.exe后將自身映射注入其中。注入函數自身獲取一個PID和目標進程的主線程句柄，以及在注入發生后要執行的函數地址。

3）Ghostminer：惡意軟件將惡意代碼注入已授權的應用程序來隱藏自身，利用Oracle WebLogic Server漏洞在目標系統的內存中運行代碼，并通過啟動PowerShell腳本解釋器繼續滲透。

4）Formbook：遍歷系統中運行的進程以查找explorer進程進行explorer主線程劫持和APC注入，然后以掛起狀態創建一個線程，其中有幾個EXECUTE_READWRITE共享內存區域和一個READWRITE區域，但其中包含可執行頁面。

5）Rig Exploit Kit：創建兩個具有EXECUTE_READWRITE內存區域的新進程。

6）Olympic Destroyer：創建一個新進程，其READWRITE內存區域包含一個可執行頁面。

使用對比插件分析惡意樣本如表4所示。將惡意軟件分別在分別在Windows內核版本15063×64、19041x64上運行，待病毒運行完成后轉儲操作系統內存并使用各插件進行分析。

由于不掌握惡意樣本的源代碼，所以無法人為影響內存分配的方式。hollowfind、malfofind和threadmap可以檢測部分病毒軟件的進程hollow行為，但是由于APC注入的干擾對Formbook的進程hollow行為檢測失敗；在64位環境下malthfind對于64位進程檢測失效；Psinfo和malfind在執行權限被修改時無法有效檢測；特別是Olympic Destroyer，其他插件全部檢測失敗，通過逆向分析該樣本發現執行權限被API函數修改。但codefind并不是只依賴VAD信息來進行檢測，所以基于本文所研發的codefind插件可以有效檢測Windows 32/64位代碼注入攻擊。

5" 結" 論

本文針對目前Windows代碼注入檢測方法的局限性，提出了通過交叉驗證堆棧和VAD信息檢測代碼注入的方法，滿足了當前對于Windows系統代碼注入攻擊的取證需求。通過測試和分析，本文所提出的方法能夠有效檢測Windows 32/64位代碼注入攻擊；并且本文針對不同類型的進程測試了插件的適用性，結果表示插件能夠適用于64位進程和WoW64進程，檢測結果優于現存檢測方法。通過分析近年來的惡意樣本，插件在實際應用中能夠有效檢測到包含注入代碼所在的內存區域，幫助取證人員進一步取證分析。

惡意軟件與反惡意軟件一直處于此消彼長的趨勢，未來的研究可專注于調查惡意軟件常用的API，并創建這些API函數簽名的數據庫。提取傳遞給這些函數的數據，并提供更多關于執行流程的信息以豐富堆棧分析的結果。

此外，惡意軟件可能會使用自定義函數以躲避檢測，未來的工作還可以收集惡意軟件通用行為，提供更多的可靠數據來驗證進程的執行并檢測進程被攻擊者操控或感染的情況，提高取證效率與準確率。

參 考 文 獻：

［1］" JOSEPH P， NORMAN J. Systematic Memory Forensic Analysis of Ransomware Using Digital Forensic Tools［J］. International Journal of Natural Computing Research （IJNCR）， 2020， 9（2）： 61.

［2］" CASE A， RICHARD III G G. Memory Forensics： The Path Forward［J］. Digital Investigation， 2017， 20： 23.

［3］" 張瑜， 劉慶中， 李濤，等. 內存取證研究與進展［J］. 軟件學報， 2015， 26（5）： 1151.

ZHANG Yu， LIU Qingzhong， LI Tao， et al. Research and Progress in Memory Forensics［J］. Software Journal， 2015， 26（5）： 1151.

［4］" OR-MEIR O， NISSIM N， ELOVICI Y， et al. Dynamic Malware Analysis in the Modern Era—A State of the Art Survey［J］. ACM Computing Surveys （CSUR）， 2019， 52（5）： 1.

［5］" ZIMBA A， WANG Z， CHEN H， et al. Recent Advances in Cryptovirology： State-of-the-art Crypto Mining and Crypto Ransomware Attacks［J］. KSII Transactions on Internet and Information Systems （TIIS）， 2019， 13（6）： 3258.

［6］" PANDEY A K， TRIPATHI A K， KAPIL G， et al. Current Challenges of Digital Forensics in Cyber Security［J］. Critical Concepts， Standards， and Techniques in Cyber Forensics， 2020： 31.

［7］" WHITE A， SCHATZ B， FOO E. Integrity Verification of User Space Code［J］. Digital Investigation， 2013， 10： 59.

［8］" 翟繼強，陳攀，徐曉，等.面向Windows 10系統段堆的內存取證研究［J］.西北工業大學學報，2021，39（5）：1139.

ZHAI Jiqiang， CHEN Pan， XU Xiao， et al. Research on Memory Forensics for Windows 10 System Segment Heap［J］. Journal of Northwestern Polytechnical University， 2021，39（5）：1139.

［9］" DOLAN-GAVITT B. The VAD Tree： A Process-eye View of Physical Memory［J］. Digital Investigation， 2007， 4： 62.

［10］VAN Baar R B， ALINK W， VAN Ballegooij A R. Forensic Memory Analysis： Files Mapped in Memory［J］. Digital Investigation， 2008， 5： 52.

［11］ARASTEH A R， DEBBABI M. Forensic Memory Analysis： From Stack and Code to Execution History［J］. Digital Investigation， 2007， 4： 114.

［12］HEJAZI S M， TALHI C， DEBBABI M. Extraction of Forensically Sensitive Information from Windows Physical Memory［J］. Digital Investigation， 2009， 6： 121.

［13］MONNAPPA K A. Detecting Deceptive Process Hollowing Techniques Using Hollowfind Volatility Plugin［J］. Accessed August， 2016， 25： 2022.

［14］FREILING F， GRO T， LATZO T， et al. Advances in Forensic Data Acquisition［J］. IEEE Design amp; Test， 2018， 35（5）： 63.

［15］VMEL， Stefan， JOHANNES Stüttgen. An Evaluation Platform for Forensic Memory Acquisition Software［J］. Digital Investigation， 2013， 10： 30.

［16］TANK D M. Enhancement of Security Mechanism In Virtualization Environment［D］. Gujarat Technological University Ahmedabad， 2022.

［17］BALAOURA S. Process Injection Techniques and Detection Using the Volatility Framework［D］. Πανεπιστη＇" μιο Πειραιω＇" ， 2018.

［18］BLOCK F， DEWALD A. Windows Memory Forensics： Detecting （un） Intentionally Hidden Injected Code by Examining Page Table Entries［J］. Digital Investigation， 2019， 29： S3.

［19］LIGH M H， CASE A， LEVY J， et al. The Art of Memory Forensics： Detecting Malware and Threats in Windows， Linux， and Mac Memory［M］. John Wiley amp; Sons， 2014.

（編輯：溫澤宇）