一種基于隱藏事件觸發機制的內存取證方法

崔超遠 李勇鋼,2 烏 云 王勵成

1(中國科學院合肥物質科學研究院合肥智能機械研究所 合肥 230031)2(中國科學技術大學研究生院科學島分院 合肥 230027)3(中國科學院合肥物質科學研究院應用技術研究所 合肥 230088)4(北京郵電大學網絡空間安全學院 北京 100876)

內存取證包含2個要素：發起取證的時間點和取證對象.傳統的內存取證方法均是假設取證操作發生在惡意軟件攻擊過程中，然后對整個內存空間進行內存轉儲操作，從而獲取全部內存內容[1].此類方法具有取證范圍廣、實現簡單的特點.但是，攻擊發起者往往僅是一個進程或一個可加載內核模塊(loadable kernel module, LKM)，大范圍的內存取證雖然能夠涵蓋攻擊發起者的代碼信息，卻產生了大量的冗余信息.同時，攻擊者的攻擊發起時間和持續時間具有隨機性，且內存本身具有易失性和不可恢復性的特點.換句話說，攻擊完成后內存一旦被回收，攻擊者的內存痕跡將被徹底清除.因此，若發起內存取證的時間點不在攻擊過程中，那么取證內容將不包含攻擊行為的特征信息，使得內存取證失去意義.總之，取證時間點和取證對象的確立是成功進行內存取證的關鍵.但是，惡意內核對象所具有的隱藏性會對取證工具選取取證對象和取證時間點產生干擾，導致取證失敗.

Rootkit是一種應用范圍最廣的隱藏性惡意軟件[2].它不僅能夠實現自我隱藏，還能與其他惡意軟件相結合，實現指定惡意內核對象的隱藏[3].惡意內核對象(如進程或LKM)被隱藏后，能夠有效規避安全工具的檢測，對操作系統(operating system, OS)安全產生極大的威脅.Rootkit的隱藏技術大致可分為內部指令替換、內核函數重定向、直接內核對象操作(direct kernel object manipulation, DKOM)[4]和容器原語欺騙四大類.其中，指令替換技術很容易通過完整性校驗檢測到，目前已經很少被使用了.內核函數重定向技術并不對內核代碼段做出任何更改，僅對特定內核函數(用于構建語義視圖的函數)的引用指針進行重構，使其指向惡意軟件自定義的代碼段.此類方法并未破壞內核代碼段的完整性，因此對內核完整性校驗方法具有免疫性，對基于主機的安全工具隱藏效果極強.DKOM型Rootkit的操作對象是內核對象的描述符，它直接更改內核對象的屬性.該方法打破了目標內核對象與其他內核對象之間的邏輯連接關系，導致任何依賴于內核對象之間邏輯關系構建語義視圖的安全工具失效[5].基于容器原語欺騙技術的Rootkit是Leibowitz在2016年黑帽大會(Black Hat)上提出的一種新型Rootkit，名為Horse Pill[6].它通過感染ramdisk接管整個操作系統，并通過容器原語欺騙系統所有者.在感染過程中，Horse Pill利用操作系統中initrd動態生成的特點向其中注入惡意二進制可執行文件run-init，取代原有的init，以此獲取系統的控制權.當操作系統重啟之后，run-init會向系統所有者提供提前設計好的虛假語義視圖，這類似于將系統所有者圈定在攻擊者為其設定的容器內.在容器之外，攻擊者可以自由設定后門之類的惡意進程，而這些惡意進程對系統所有者是不可見的.

Rootkit的隱藏性使取證工具在取證對象確定和取證時間點選取上面臨巨大挑戰.傳統的內存取證工具多是基于主機的，與目標OS缺乏足夠的隔離性，很容易被具有隱藏特征的Rootkit繞過.目前基于虛擬化技術的取證方法雖然增強了取證工具和目標OS之間的隔離性，但是無法實時地檢測到可疑內核對象的隱藏操作，使取證對象和取證時間的選取變得極其困難.尤其是針對DKOM型的Rootkit，當前方法僅能檢測到被Rootkit隱藏的內核對象(如進程、文件和網絡端口)，無法檢測到Rootkit本身(即被隱藏的模塊).取證對象的不確定性將導致取證范圍擴大，影響取證效率；取證時間點的選取錯誤將直接導致取證數據無效.

為解決上述問題，本文提出一種基于隱藏事件觸發機制的內存取證方法ForenHD.該方法利用虛擬機管理器(virtual machine manager, VMM)實時監視目標虛擬機(target virtual machine, TVM)中內核對象.針對采用DKOM技術隱藏的內核對象，ForenHD實時地監視目標對象與其他對象之間的邏輯連接關系以及運行狀態，通過邏輯連接變化和狀態異常判定其是否具有隱藏性.針對非DKOM型的內核對象，ForenHD首先通過內核對象占用的物理資源變化實時地捕獲正在執行的內核對象，之后與TVM內部視圖進行交叉驗證以檢測該對象是否被隱藏.檢測到隱藏對象后，ForenHD對被隱藏的內核對象采用內存映射進行內存取證.ForenHD將隱藏對象的發現作為內存取證的觸發事件，以檢測到內核對象被隱藏的時刻作為取證時間點，以被隱藏的內核對象作為取證對象.

1 相關工作

關于內存取證技術的研究，研究者們展開了廣泛而深入的探索.目前的內存取證技術大致可以分為2類：基于硬件的內存取證和基于軟件的內存取證.例如Alessandro 等人[7]和Wang 等人[8]提出的方法都是利用PCI 網卡中的系統管理模式(system management mode, SMM)固件獲取物理內存和CPU寄存器內容而tefan[9]則是利用網卡的網絡驅動程序接口規范(networkdriver interface specifica-tion, NDIS)來獲取物理內存.這些方法都屬于基于物理固件的內存拷貝技術，能夠隨時準確地獲取到內存數據.但是這些方法都需要對目標OS中的硬件引入更改，同時對硬件進行重新編程，且容易被基于硬件的Rootkit繞過.此外，它們的取證范圍都是對整個內存的完整取證，包含了大量的冗余信息.

基于軟件的內存獲取方法主要利用軟件去獲取內核內存區對象,并借助于操作系統的內核數據結構和相關機制去解析重構內存數據.例如Garner開發的Data-Dumper[10]、Klein提出的Process Dumper Utility[11]都是通過用戶模式的應用程序讀取目標系統中內核內存區對象.這類方法是基于主機取證方法的代表，實現簡單快速.但是，這些方法依賴于目標OS的內部語義視圖構建函數，存在被繞過的風險.與Data-Dumper不同的是，Mantech 公司的MemoryDD[12]和MoonSols 公司的Windows Memory Toolkit[13]均通過內核模式驅動程序讀取目標系統中內核內存區對象.如果攻擊者采用 DKOM技術直接修改內存操作函數及其所使用的內核對象,則此類方法獲取的內存數據將失真.趙宇韜等人提出的RTMF[14]通過硬件虛擬化技術構建了基于時間觸發機制的入侵檢測方法，能夠及時發現惡意軟件對敏感內核對象的篡改操作.但是，該方法僅對靜態內核對象有效，無法實時監視進程狀態描述符、內核模塊狀態描述符等動態內核對象的異常變化.因此，對通過DKOM方法實現自我隱藏的進程或模塊不具有檢測效果，無法實現基于隱藏事件觸發的內存取證.KIMBMF[15]針對TOC-TOU攻擊，通過采用隨機化時間觸發的方法弱化其攻擊效果.但是，此方法無法確保在惡意軟件進行惡意操作時立即進行檢測，且存在漏檢的可能，這限制了它的推廣使用.

為解決上述問題，本文提出了一種基于隱藏事件觸發機制的內存取證方法.

2 ForenHD總體設計

ForenHD的總體設計如圖1所示.它由實時隱藏監視器Monitor、實時內存取證模塊Foren和存儲文檔file三部分組成.在ForenHD的運行過程中，Monitor實時監視TVM中內核對象的狀態變化，若發現隱藏操作則立即通知取證模塊Foren.Foren被喚醒后通過內存映射捕獲目標對象的內存，并將其存儲在文檔file中.

Fig. 1 Architecture of ForenHD圖1 ForenHD架構設計

ForenHD監視和取證的內核對象包含進程和模塊2類.Rootkit對進程的隱藏方法種類繁多，既包括破壞進程間邏輯連接關系的DKOM，也包括函數重定向、系統調用表重構等非DKOM技術；隱藏模塊的方法相對單一，均是采用DKOM技術.利用DKOM技術隱藏的進程和模塊，其狀態描述符中的邏輯連接條目在隱藏過程中發生了改變，因此ForenHD通過實時檢測該條目的變化即可實現隱藏檢測.與之相比，采用非DKOM技術隱藏進程的Rootkit并不對進程本身做任何更改，而是通過重構語義視圖函數實現隱藏目的[16].針對此類隱藏對象，ForenHD需要實時地跟蹤進程的真實語義視圖，并與Rootkit在TVM內部構建的虛假語義視圖進行交叉驗證才能檢測到被隱藏的進程.

當下發現的DKOM型的Rootkit在進行對象隱藏(隱藏進程)和自我隱藏(隱藏模塊)時，均需解除目標對象與其他兄弟對象之間的級聯關系.Monitor將目標對象狀態描述符中的級聯關系成員變量作為監視對象，實時監視其變化.能夠引起目標對象中級聯關系成員變量產生狀態變化的方式有3種：1)目標對象的正常退出操作；2)目標對象相鄰節點的加入或刪除操作；3)目標對象本身的隱藏操作.前2種操作屬于OS的正常操作，第3種操作是DKOM型Rootkit產生的惡意隱藏操作.Monitor通過判斷目標對象與相鄰節點之間連接關系的變化，以及目標對象自身運行狀態的變化可以有效地甄別出正常操作和隱藏操作.

采用非DKOM技術隱藏的進程會對TVM內部指令構建的語義視圖保持隱藏，但是仍然會被OS正常地調度執行.為檢測此類隱藏進程，ForenHD首先在SVM中實時地監視被TVM調度執行的進程.任何進程的執行都需要獲得CPU時間片，并在時間片內獨占CPU資源[17].ForenHD實時地捕獲TVM中VCPU的上下文信息，通過esp寄存器的變化監視進程內核棧的更新，然后通過棧底的數據結構thread_info→task即可得到當前正在運行的進程.進程的隱藏操作可發生在執行階段的任意時間點，因此ForenHD需要將每一個捕獲的進程與TVM內部的進程語義視圖進行交叉驗證.由于ForenHD部署在SVM中，無法直接取得TVM的內部語義視圖.所以，ForenHD運行前首先向TVM中植入內部視圖構建模塊.該模塊收到視圖更新指示后，利用TVM內部指令(如“ps”)構建語義視圖，并將所得進程視圖存儲在共享內存中供ForenHD使用.

當檢測到隱藏對象時，ForenHD對目標對象進行內存取證.為防止取證內容被刷新或置換到交換區，本文設計了一種映射頁表緩存機制，以減少重復的映射操作，加快映射速度.完成取證后，ForenHD將取證數據存儲在文檔中保存.

3 內存取證系統實現

3.1 映射頁表緩存機制

由于ForenHD部署在SVM中，與TVM之間存在內存隔離，因此不能直接讀取TVM的內存數據.ForenHD對TVM的所有讀內存操作都需要經過內存映射，在內存映射過程中為取得內存頁框，需要完成從頁目錄到頁表再到頁框的多級頁表映射操作.例如獲取32位TVM的單個內存頁框需要經歷3次內存映射，而64位TVM則需5次.同一進程或模塊的不同內存頁框之間共用同一頁目錄，其頁表也可能相同.因此，對共用頁目錄或頁表的不同頁框的內存映射操作會造成對已映射內存的重復映射.為減少重復映射操作，ForenHD引入了映射頁表緩存機制，如圖2所示(以32 b地址寬度為例).

Fig. 2 Initialization of page mapping圖2 頁面映射初始化

映射操作前，ForenHD按照OS中的多級頁表分別建立不同等級的映射頁表緩存，并對每一緩存頁建立管理結構.該結構中包含客戶物理地址(GPA)、映射后的內存地址(MMA)、時間戳信息(time)、雙向循環鏈表連接項(list)和下一級緩存首地址(next_init)等信息.各級緩存頁表按照時間戳由大到小的順序構成雙向循環鏈表，由初始節點指向時間戳最大的緩存頁.各級緩存的鏈表連接關系如圖3所示.

Fig. 3 Structure of mappedpage table圖3 緩存鏈表結構

內存映射初始化時，ForenHD首先得到TVM中VCPU的cr3寄存器，并將該寄存器內容和內存映射指令“IOCTL_PRIVCMD_MMAP”通過ioctl傳遞給驅動privcmd.驅動privcmd收到指令后將cr3寄存器內容對應的頁目錄映射到SVM中.得到映射頁目錄后，ForenHD將該映射頁目錄信息填充到頁目錄緩存鏈表中，并建立指向該緩存項的初始節點init_node.在之后進行的內存映射中，ForenHD陸續將各級頁表填充到對應的緩存結構中，直到得到虛擬地址對應的內存頁框初始化完成.之后，ForenHD在內存映射時從頁目錄到各級頁表，以各自的GPA為鍵值逐級檢索緩存結構.在對每一級緩存進行檢索的過程中，ForenHD從next_init指向的時間戳最大的緩存項開始，搜索當前緩存鏈表中是否存在與GPA相匹配的映射內存.若存在匹配項，則根據虛擬地址中本級頁表對應的偏移量(如圖3中p1和p2)直接讀取下一級頁表首地址的GPA，并以該GPA為鍵值繼續搜索下一級緩存鏈表；若不存在匹配項，則停止本級及之后的緩存檢索操作，并從本級開始進行逐級內存映射，直到得到目標緩存頁結束.ForenHD通過內存映射得到頁表的映射內存后，以該頁表的信息更新當前緩存鏈表中最小時間戳對應的緩存項.若更新項屬于頁目錄緩存鏈表，則將init_node更新為該項的地址；若更新項屬于頁表緩存表，則使上一級緩存項中的next_init指向該緩存項.

通過映射緩存機制可以減少對各級頁表的重復映射.若緩存鏈表中不存在對應的緩存項，完成一次內存映射需要進行3次頁面映射操作(32位OS)；若僅存在頁目錄映射緩存，則需要進行2次頁面映射；如果緩存池中頁目錄和頁表緩存同時存在，則僅需1次頁面映射即可.

3.2 隱藏進程的實時檢測

在Linux系統中，每個進程在被創建時都會由函數alloc_thread_info分配若干個完整的內存頁(8 KB或16 KB)作為內核棧.內核棧采用自頂向下的方式增長，esp寄存器指向棧基址.數據結構thread_info存儲在以棧基址為起始地址的一段內存中，它的第一個成員變量即指向進程描述符task_struct[18].進程的切換執行也伴隨著CPU寄存器esp所指向的內核棧的切換.ForenHD實時捕獲TVM中VCPU上下文信息，并提取出esp寄存器；然后通過esp寄存器的變化判定棧基址的更新；最后通過讀取指針thread_info→task得到當前正在執行的進程.由于任何進程的執行都離不開CPU資源，因此利用該方法取得的進程視圖能夠監視到以任何形式隱藏的進程.

Fig. 4 Monitoring process圖4 監視流程

3.2.1 DKOM型隱藏進程的實時檢測

目前，采用DKOM技術對進程進行隱藏的技術已經出現，如linuxfu.linuxfu利用DKOM技術將進程狀態描述符從它所屬的雙向循環鏈表中摘除，以實現隱藏目的.被隱藏的進程對依賴進程間邏輯關系實現檢測目的的方法如libvmi[19],vmwatcher[20]等具有極強的隱藏效果.針對此類隱藏進程，ForenHD在監視到VCPU中存在新切換的進程后，檢測該進程與該進程的狀態描述符中list項所指向的進程之間的連接關系，并通過進程運行狀態變化判定是否發生隱藏行為，監視流程如圖4所示.

在圖4中需要注意的是，在判定隱藏進程的時候不僅需要當前進程的運行信息，還需要核對與該進程的鏈表相鄰進程的指向關系.若相鄰節點的list項均不再指向當前進程，或當前進程的list項不再指向任何相鄰節點，都判定該進程發生了鏈表移除操作.此時，若當前進程的狀態仍為TASK_RUNNING態，則認定該進程為隱藏進程.

3.2.2 非DKOM型隱藏進程的檢測

在當前的各類Rootkit中，采用非DKOM技術隱藏進程的Rootkit仍占多數.此類Rootkit并不會對進程本身做出任何更改，而是將構建進程語義視圖的系統接口作為攻擊目標，實現對內部進程語義視圖的重構.由于進程的自身保持正常，我們很難通過監視進程狀態實現隱藏檢測.ForenHD在TVM內部部署了一個語義獲取模塊InerSem，該模塊利用TVM指令建立內部進程視圖.ForenHD通過Xenstore[21]實現與InerSem之間的消息傳遞，通過內存映射實現語義視圖的傳遞.初始化時，InerSem將生成的進程視圖存儲在內存池SemPool中，并將構建視圖的時間戳信息存儲在SemPool頂部，之后通過Xenstore通知ForenHD將SemPool映射到SVM中.ForenHD將實時捕獲的進程與SemPool中的進程視圖進行交叉驗證即可檢測到隱藏的進程.

ForenHD捕獲的進程是當前CPU時間片內正在運行的進程，此時SemPool中的進程視圖應在理論上包含此進程才能確保交叉驗證操作有效.CPU中所執行的進程既可能是首次執行的“新進程”，也可能是之前尚未執行完畢而被再次調度執行的“老進程”，二者都可能是被Rootkit隱藏的可疑進程.進程的創建、退出和隱藏都會導致TVM內部的進程視圖發生改變.由于ForenHD采用存在性驗證方式檢測進程的隱藏性，因此進程退出并不影響視圖交叉驗證.但是，我們必須在進程創建或隱藏之后，在交叉驗證之前的時間段內重構SemPool中的進程視圖，才能確保SemPool中的進程視圖的時效性.

觸發SemPool更新的方式包括條件觸發和無條件觸發2種，前者針對“新進程”的隱藏檢測，而后者則針對“老進程”的隱藏檢測.ForenHD捕獲到當前進程后，首先通過該進程的task_struct→real_start_time取得進程的啟動時間戳[22]，并與SemPool頂部的時間戳信息進行比較.若進程的啟動時間戳大于SemPool的時間戳，則說明當前進程是“新進程”，并以該事件作為觸發SemPool更新的事件.此外，SemPool也會定時更新，以確保SemPool正確反映“老進程”被隱藏后的進程視圖.在整個檢測過程中，若進程啟動時間戳小于SemPool的時間戳，則將該進程與SemPool中的進程視圖進行交叉驗證.當前進程的啟動時間先于SemPool中進程視圖的更新時間，說明理論上SemPool中的進程視圖應當包含該進程.因此，若該進程不存在于SemPool中，則可判定該進程為隱藏進程.

3.3 隱藏模塊的實時檢測

LKM的運行信息，如導出符號、初始函數、代碼段等都存儲在狀態描述符structmodule中.所有的狀態描述符被連接成一個雙向循環鏈表(module→list).在該鏈表中，始終存在一個初始化模塊，它本身并不實現具體功能，只作為雙向循環鏈表的一個初始節點，連接著鏈表中的第1個模塊(本文記作“首模塊”).任何新增模塊在進行內核模塊加載時，都需要加載到初始模塊后面成為它的下一個節點(即新的“首模塊”).

當前的內核級Rootkit均以LKM的形式加載到內核中，因此Rootkit隱藏模塊即是自我隱藏.與進程多種多樣的隱藏方式不同，Rootkit通常采用DKOM技術解除與其他模塊之間的鏈表連接關系以實現自我隱藏.此外，不同于進程可在執行期間的任意時刻被隱藏，模塊的隱藏僅發生在初始化階段.內核級Rootkit在加載過程中，首先由OS將其連接到雙向循環鏈表中；之后通過自定義的初始化函數執行鏈表移除操作實現隱藏目的；最后OS再將模塊的狀態更新為MODULE_STATE_LIVE完成初始化.

引發初始模塊list項變化的可能有3種：1)首模塊正在被正常卸載;2)有新模塊正在被加載;3)首模塊正在被隱藏.這3種操作引發的模塊狀態變化如圖5(a)～(c)所示.

Fig. 5 State transition of modules圖5 模塊狀態變化

模塊正常加載引發初始模塊list項發生變化時，更新前list所指向的模塊的狀態為MODULE_STATE _LIVE；更新后的list所指向的模塊狀態為NULL.模塊正常卸載引發初始模塊list項發生變化時，更新前list所指向的模塊狀態為MODULE_STATE _GOING；更新后的list所指向的模塊狀態為MODULE_STATE_LIVE.模塊隱藏引發初始模塊list項發生變化時，list變化前所指向的模塊狀態為MODULE_STATE_COMING；更新后的list所指向的模塊狀態為MODULE_STATE_LIVE.ForenHD在監視到初始模塊的list項發生變化時，檢測首模塊的狀態并判斷其是否正在發生隱藏操作.需要注意的是，由于list變化后模塊的狀態可能會在極短的時間內發生改變，所以ForenHD需要在監視到list變化時暫停TVM，防止模塊狀態尚未被讀取就發生改變.

3.4 隱藏對象實時取證

3.4.1 隱藏進程取證

檢測到隱藏進程后，ForenHD立即對隱藏進程進行內存取證，取證內容包括進程的執行路徑、映射庫文件、代碼段和數據段.通過對(task_struct→mm→start_code, task_struct→mm→end_code)區間段的內存進行映射讀取即可得到進程的代碼段.同樣地，對(task_struct→mm→start_data, task_struct→mm→end_data)區間段的內存進行映射讀取即可得到進程的數據段.

追溯文件路徑和映射庫文件的一個關鍵結構體是struct dentry，其獲取方法是逐級讀取指針task_struct→mm→mmap→vm_file→file→fpath→dentry.在結構體dentry中含有2個關鍵的條目，一個是struct dentry*d_parent，指向當前文件或目錄的父目錄(可為空)；另一個是unsigned chard_iname[DNAME_INLINE_LEN]，該數組中存放著當前文件或目錄的名字.通過由“子”向“父”的不斷遞推，直到追溯到根目錄“/”，并逐級讀取文件或目錄名，這樣就能獲取到完整的文件路徑.映射文件的偏移量存儲在vm_area_struct的vm_pgoffset項中，該項的大小以PAGE_SIZE(本文中大小為4 KB)為單位.

3.4.2 隱藏模塊取證

發現隱藏模塊之后，ForenHD會對目標LKM的代碼段進行內存取證.LKM狀態描述符中的module_core項指向LKM的代碼段，core_text_size項記錄了代碼段大小.ForenHD根據這2項通過內存映射即可得到LKM的代碼數據，其實現過程如圖6所示：

Fig. 6 The memory forensic of modules圖6 模塊內存取證

4 實驗結果與分析

實驗環境由物理主機、Xen虛擬化平臺、SVM和TVM組成.物理主機為Dell R710機架式服務器，配置為Intel Xeon?E5520@2.27 GHz 16核處理器、16 GB內存、137 GB硬盤.Xen虛擬化平臺為Xen 4.1.2.操作系統系統環境配置如表1所示：

Table 1 Experimental Environment表1 實驗環境

4.1 隱藏對象實時檢測與內存取證

linuxfu是一種利用DKOM技術隱藏進程的典型Rootkit.Diamorphine是一種以LKM形式加載進內核中的內核級Rootkit，它通過解除與其他模塊之間的邏輯關系隱藏自身.本節以linuxfu隱藏的進程為例，詳細說明ForenHD對隱藏進程的實時檢測和內存取證效果，以diamorphine為例驗證ForenHD對隱藏模塊的隱藏檢測和內存取證的檢測和取證效果.

4.1.1 隱藏進程檢測

Linuxfu感染TVM后，會以LKM的形式加載到內核空間，從而獲得root權限.通過將目標進程從雙向循環鏈表中移除，linuxfu可以實現對進程的隱藏.ForenHD對linuxfu所隱藏進程的檢測結果，以及與libVMI進行的對比如圖7所示.圖7(a)是ForenHD在SVM中對進程加載執行的實時監視.圖7(b)和(c)分別是TVM中未運行linuxfu和運行linuxfu時，利用libVMI在SVM中得到的TVM進程視圖,通過對比發現，libVMI無法檢測到linuxfu的隱藏進程test.圖7(a)顯示，當linuxfu隱藏進程test時，ForenHD能夠實時地檢測到linuxfu對test的隱藏操作，如圖7(a)橫線部分.

Fig. 7 Hidden process detectionof Linuxfu Rootkit圖7 Linuxfu隱藏進程檢測

Fig. 8 Execution path and map library file of hidden process圖8 隱藏進程執行路徑及映射庫文件

4.1.2 隱藏進程取證

ForenHD對隱藏進程的執行路徑和映射庫文件的取證結果圖8所示.圖8(a)是ForenHD的取證結果，圖8(b)是在TVM中使用指令“pmap”得到的test的映射庫文件視圖.從圖8中可以看出，ForenHD能夠檢測到隱藏進程test的完整映射庫文件及其偏移量.其中，左側窗口橫線部分就是隱藏進程的執行路徑.

圖9是ForenHD對隱藏進程test取證所得的代碼段信息(圖9(a))與利用指令“objdump-S test”在TVM中得到的test代碼段(圖9(b))的對比結果.對比顯示：ForenHD的取整數據與test代碼段完全一致.

4.1.3 隱藏模塊檢測

ForenHD對LKM的隱藏事件檢測如圖10所示，分別是ForenHD的檢測視圖和TVM的內部指令視圖.從圖10可以看出，diamorphine隱藏后，無論是模塊的外部語意視圖(圖10(a)中MODULE LIST)還是其內部指令視圖(圖10(b)中lsmod)均無法檢測到它的存在.但是，ForenHD能夠檢測到diamorphine的隱藏事件操作，如圖10(a)橫線部分所示.

4.1.4 隱藏模塊取證

圖11是ForenHD對diamorphine的取證結果，圖11(a)和(b)分別是ForenHD的取證數據和利用指令“objdump -S diamorphine.ko”所得的靜態代碼數據.需要注意的是，未加載的LKM因為尚未完成符號重定向等操作，所以部分數據為初始值0.ForenHD的取證對象是運行態的LKM，此時LKM已完成初始化操作，因此原來為0的靜態數據可能已發生變化.拋開靜態數據0產生的差異，可以發現ForenHD的取整數據與靜態代碼完全一致.

除linuxfu和diamorphine外，實驗中還對多種其他類型的Rootkit進行了實驗，實驗結果匯總如表2所示.從表2中可以看出，ForenHD能夠檢測到各種類型Rootkit隱藏的內核對象并對內核對象進行內存取證.

Fig. 11 Code forensic of hidden module圖11 隱藏模塊代碼取證

RootkitNameProcessModuleDetectionForensicDetectionForensicadore-ng√√√√horsepill√√brootus√√diamorphine√√√√z-Rootkit√√√√linuxfu√√xingyiquan√√kbeast√√√√mak_it√√

TVM內部工具(如ps，top等指令)在構建進程視圖時，必須要借助TVM提供的進程視圖構建函數.Rootkit(如adore-ng，z-Rootkit等)侵入TVM后會重構或重定向這些函數，導致內部進程視圖失真.諸如libVMI類的外部視圖構建工具，雖然通過虛擬機之間的隔離性避免了使用TVM內部不可信函數，但其構建進程視圖的過程依賴于進程之間的邏輯關系.一旦某種Rootkit(如linuxfu)打破了進程之間的邏輯關系，此類工具得到的進程視圖將變得不可信.

與libVMI等安全工具不同是，ForenHD構建進程的真實視圖時既不依賴于TVM的內部函數，也不依賴于進程之間的邏輯連接關系.ForenHD首先根據VCPU中esp所指向的內核棧的更新判定進程的切換執行，然后通過內核棧中的數據結構取得VCPU中正在運行的進程.由于任何進程的執行都需要獲得CPU、內核棧等物理資源，因此ForenHD通過監視物理資源變化構建的進程視圖能夠涵蓋各類Rootkit隱藏的進程.ForenHD實時地捕獲每一個在CPU中執行的進程，并檢測所捕獲進程與其他進程的邏輯連接關系是否遭到破壞.與此同時，ForenHD還搜索該進程是否存在于InerSem構建的TVM內部進程視圖中.因此，ForenHD能夠檢測到以任何形式被隱藏的進程.

無論是內部工具還是外部工具，在構建模塊視圖時都依賴于模塊之間的邏輯連接關系.所以Rootkit只需將LKM從雙向循環鏈表中移除即可實現隱藏目的.模塊的隱藏操作均發生在加載期間初始化函數的調用過程中，且在加載完成之前就已經實現了隱藏目的.因此ForenHD實時地監視初始模塊的鏈表更新，并通過首模塊的狀態變化甄別LKM的加載、卸載和隱藏行為.所以當Rootkit進行隱藏操作時，會被ForenHD實時地檢測到.

4.2 內存取證性能分析

4.2.1 運行時間

本實驗以目標對象的隱藏檢測作為時間起點，測試完成隱藏檢測和取證總共所需的時間.取證操作所需時間與取證的內存數量相關，實驗中逐漸增加目標對象的體積并測量檢測和取證總共所需的時間，結果如圖12所示：

Fig. 12 Performance overhead of memory forensic圖12 內存取證性能開銷

從圖12中可以看出，ForenHD對進程和模塊的檢測及取證所需時間幾乎相同，均與取證內存的數量成正相關.此外，可以發現映射第一個內存頁時耗時較多.這是由于ForenHD對內存映射引入了映射頁表緩存機制，在進行首次映射時需要完成對多級頁表的映射并建立緩存.之后進行內存映射時，ForenHD會首先對頁表緩存進行搜索，若存在存根則直接讀取，這可以減少對已映射頁表的重復映射，提高映射速度.

Fig. 13 Time proportion of detection and forensic圖13 檢測與取證的時間占比

以4 KB內存數量為例，測量隱藏進程檢測、隱藏模塊檢測、進程取證和模塊取證4部分的耗時百分比，結果如圖13所示:

對比發現，對進程的隱藏檢測耗時最多，對模塊的隱藏檢測耗時最少.因為在監視進程時，需要實時地捕獲vcpu上下文信息，然后通過內存映射得到內核棧，之后再次通過內存映射得到進程描述符，最后解析進程的狀態描述符并進行隱藏性校驗.而對模塊的監視只需要映射得到LKM狀態描述符后檢測模塊狀態即可.因此，ForenHD對進程的隱藏檢測耗時較多.

4.2.2 性能開銷

本節利用Linux系統性能測試工具nbench[23]測試ForenHD對SVM和TVM產生的性能影響.Nbench的測試結果共有10項，每項測試表示每秒能夠完成的測試個數，進行多次測試取平均值，數值越大表明處理速度越快.實驗中分別測試了ForenHD對SVM和TVM的影響，包括進程隱藏性檢測(P-Monitor)、模塊隱藏性檢測(M-Monitor)和內存取證(Foren)各自造成的性能開銷，以及總的性能開銷.

Fig. 14 Influence of ForenHD modules on SVM performance圖14 ForenHD各功能模塊對SVM的性能影響

測試結果如圖14～16所示.圖中各項結果均以系統中不運行ForenHD的性能表現作為標準做了歸一化處理，橫坐標表示測試類型，縱坐標表示性能損耗.可以看出，P-Monitor,M-Monitor和Foren對SVM引入的平均性能開銷分別為2.9%,1.0%和1.9%，總計為5.8%；對TVM引入平均性能開銷分別為1.4%,0.4%和1.0%，總計為2.8%.對比發現，ForenHD對SVM影響較大，同時各功能模塊中又以進程檢測引入的性能開銷最大.

Fig. 15 Influence of ForenHD modules on TVM performance圖15 ForenHD各功能模塊對TVM的性能影響

由于ForenHD部署在SVM中，其主要計算資源和存儲資源均來自SVM，因此它的運行將對SVM產生的影響較大；對TVM的影響則主要來源于其對整體資源占用造成的影響以、運行過程中對TVM的短暫暫停以及內部進程視圖的生成3部分.

ForenHD為實時地捕獲CPU中執行的進程，首先獲取TVM中VCPU上文信息，然后通過esp寄存器的變化識別內核棧的更新.緊接著通過內核棧中的thread_info→task得到當前進程的狀態描述符，最后通過進程描述符解析進程的狀態，如進程名、進程號、啟動時間和邏輯連接關系等.之后，為檢測當前進程的隱藏性ForenHD需要將其與TVM的內部進程視圖進行交叉驗證.若檢測到該進程為新進程，則需等待TVM內部進程視圖更新后再進行驗證.整個進程的檢測過程需要依次取得并解析TVM的VCPU上下文、進程內核棧的內存映射和進程描述符的內存映射，且進程切換頻率較高.因此進程檢測會引入較大的性能開銷.模塊檢測的性能開銷主要來自于初始模塊的實時監視和新增模塊的狀態檢測2部分.與進程切換相比，模塊的加載和卸載頻率較低，所以引入的性能開銷較小.內存取證的產生的性能開銷則來自內存映射、內存讀取和內存轉儲3部分.

5 總 結

本文提出了一種基于隱藏事件觸發機制的內存取證技術ForenHD.它能夠實時地檢測到被隱藏的進程和模塊，并完成對目標對象進行內存取證.ForenHD以發現隱藏對象的時刻作為取證時間點，確保了該時刻的內存中包含了表征目標對象惡意行為的代碼段信息.與RTMF等軟件方法相比，ForenHD以隱藏事件作為內存取證的觸發條件，在惡意軟件進行隱藏動作時即可實現內存取證. 同時，ForenHD的取證對象并非是TVM的全部內存，而是僅對被隱藏的內核對象進行取證. 與基于硬件的內存取證方法相比，該方法在最大程度上減少了取證的冗余信息.通過實驗驗證，ForenHD能夠實時地檢測到被各類Rootkit隱藏的進程和模塊，并快速捕獲其內存證據.ForenHD對SVM和TVM分別引入了5.8%和2.8%的性能開銷.

但是，ForenHD仍存在一些局限性.首先，ForenHD假設虛擬化平臺和SVM是絕對安全的.目前針對hypervisor和特權域的惡意軟件已經出現，如何確保它們的安全顯得尤為重要.其次，ForenHD僅對正在加載的Rootkit進行取證有效，而對于運行前已完成加載的Rootkit無法取證.最后，ForenHD仍采用以已知的內核語義知識為模板解析TVM內部語義的方式克服語義鴻溝問題，一方面會影響系統執行速率[24]，另一方面也未考慮地址隨機化[25]造成的語義模板多樣化的問題.這些問題都將作為我們后續的研究重點展開.