反取證技術：內核模式下的進程隱蔽
本文是介紹惡意軟件的持久性及傳播性技術這一系列的第一次迭代，這些技術中大部分是研究人員幾年前發現并披露的，在此介紹的目的是建立這些技術和取證方面的知識框架。
用于證明概念的代碼可以在 CERT的GitHub 上查看。由于CERT分析師Devoteam在這個領域的經驗，知識框架會不斷完善。
第一篇文章將討論DKOM（分布式組件對象模式）進程隱藏的以下幾個方面：
Windows進程
隱藏直接內核對象的修改
概念性證明（PoC）
使用Volatility進行內存檢測
這個概念在2004年的美國黑帽大會上被介紹，不過到現在還被用于幾個內核工具，比如介紹者本人所開發的FU-rootkit。
Windows進程
Windows內核使用 EPROCESS 來處理進程，這些是不透明進程，且沒有被微軟記錄，標準編譯頭也沒有詳細標明。
MSDN鏈接： EPROCESS (Windows Driver)
但是這仍然能通過使用 KD 通過內核調試被分析。
該示例中的結構有207個字段（Windows 10 64位系統）。
只有三個相關的可以解釋該技術。
此列表包含兩個鏈接： Flink 和 Blink 。這些鏈接很有趣，因為它們指向屬于屬于下一個進程（ Forwardlink ）和之前的進程（ Backlink ）的另外兩個 LIST_ENTRY 結構。
Windows系統中的所有進程通過其 ActiveProcessLinks 結構中的指針來引用。它們構成了諸如taskmgr.exe（任務管理器）或某些 SysInternals （例如 procexp.exe ）等工具使用的雙鏈表。
雙鏈表會被定時檢查以更新進程顯示。
隱藏直接內核對象的修改
DKOM技術隱藏了一個取消鏈接它自己的 ActiveProcessLinks 的進程，并將“前一個”和“下一個”進程直接相互鏈接。
從雙鏈表中獲取進程（示例圖中的 smss.exe ）使得它不依賴于此列表的工具來顯示進程。
取消鏈接流程不會影響其執行流程。調度器將計算時間分配給線程，而不是進程。
當修改惡意進程的 ActiveProcessList 時，它的 Blink 和 Flink 被修改以指向它們自己的結構。這樣做是為了避免在進程退出時出現任何問題。如果 Blink 或 Flink 指向的是舊的或無效的內存地址，那么當嘗試更新“相鄰”進程時，內核可能會引發異常。
實現
關于概念性證明（PoC）的評論
CERT在Github上的代碼 是一個測試驅動程序，它是從使用 內核模式驅動程序框架 的Windows示例中實現的。驅動配置的初始化使用 WDF_DRIVER_CONFIG_INIT() 被hook。該hook搜索一個 ImageFileName 字段為 virus.exe 的進程，并使用DKOM技術進行隱藏。
注意：這不是一個功能性的工具（只是在安裝的時候會嘗試隱藏一個進程），而且只被用于教學目的。
該代碼大量使用Windows 10 64位測試的硬編碼的存儲器偏移。它們被用于直接訪問 EPROCESS 字段，并且在其他Windows版本上可能無法正常工作。
以上顯示的偏移可以在 Windows進程 部分的第一個 KD 截圖中找到。
代碼很容易被改進，可以使用更穩定的訪問這些字段的方式然后提供一個用戶控制界面。
EPROCESS字段訪問及版本
Windows API沒有提供 EPROCESS 的結構定義，但是可以使用API調用來檢索這些結構的指針。
PoC中使用的函數是 PsGetCurrentProcess() ，它返回一個當前進程“ EPROCESS ”結構的指針。在執行的過程中，它返回一個指向System進程結構的指針，一旦找到一個 EPROCESS 結構，就調用一個搜索函數，以便通過 EPROCESS 循環列表來查找 virus.exe ImageFileName 。
如果搜索返回一個 EPROCESS 結構，那么它的 ActiveProcessLinks 就會被修以隱藏它。這通過 EPROCESS 結構在內存中的操作來實現。
其他相關與當前操作系統的保護
PoC生成的驅動程序已提交到 https://nodistribute.com/ 平臺，以檢查是否會報毒。
沒有一個報了毒，考慮到代碼十分簡單，系統調用量也很低，這樣一來就一點也不奇怪了。另外，雖然這種技術非常隱蔽，但是并不是在所有Windows版本上都很穩定。
一個叫PatchGuard的對Windows 64位的保護可以檢測前面提到的操作。 PatchGuard 也被稱為內核補丁保護（ KPP ），于2005年在Windows XP 64位和Windows Server 2003 SP1中被引入。
KPP以一個隨機頻率驗證內核結構，幾十分鐘可以分開成兩個檢查。當檢測到異常時，會引發 0×109 - CRITICAL_STRUCTURE_CORRUPTION 內核錯誤，然后強制阻止系統執行。其實 KPP 并沒有真正阻止這種技術的執行，它只是關閉了操作系統。
由于該技術旨在提供隱蔽性，而藍屏的顯示會破壞其有效性。另外，該保護僅在64位版本的Windows中實現，所以32位系統就會容易受到攻擊。如今，大多數人安裝的都是64位，因此他們會被保護免受這種威脅。
不過即使使用了 KPP ，這種技術也不能忽視，因為：
在32位系統的事件響應中可以遇到。
內核模式驅動（仍然是一個活躍的研究領域）存在對 PatchGuard 的攻擊。
使用Volatility進行內存檢測
使用工具在受感染的主機上檢測這種技術可能有點棘手，不過它可以很容易地在內存捕獲中被檢測到。事實上，許多監控/系統工具（例如 SysInternals Microsoft套件 ）都是基于雙鏈表的進程枚舉。
為了演示這個概念，PoC已在運行Windows 10 Professional版本的主機上執行。
在PoC系統上執行的Process Explorer，VMMap，ListDlls和Handle64的示例
這個進程對于這幾個工具是不可見的。但是該進程其實正在運行，并且其系統事件可以被進程監視器捕獲。
在現實生活中，很多rootkit可以修改和劫持大量的系統功能，使得大多數實時檢測變得更加困難。這里推薦使用諸如 Volatility 等適應框架對RAM轉儲然后脫機研究。
以前提到的Windows版本由擁有Win10x64_14393的配置文件的Volatility 2.6支持。
內存轉儲由Winpmem實現，該工具是Google Rekall項目分發的工具。
在Winpmem的輸出中列出了驅動程序名稱，我們可以看到PoC二進制文件（這里稱為2017_remote_helloworld）。
一旦內存捕獲過程完成，研究就可以開始了。
Volatility有幾個插件來分析轉儲中的運行進程，可以通過以下方式進行快速比較：
只有psscan和psxview發現了我們的隱藏過程。
這些插件的文檔可以幫助我們了解為什么有些人會發現這個進程，為什么有些人沒有發現。
pslist – 通過檢查雙鏈表來檢測進程
pstree – 使用了相同技術，只是顯示有小小的差別
psscan – 在內存中掃描_POOL_HEADER結構（內存頁池）以識別相關進程
psxview – 幾種技術的組合：
pslist ：如上所述
psscan ：如上所述
thrdproc ：線程掃描，檢索調度程序使用的_KTHREAD列表（不能在不中斷進程執行的情況下修改它），然后搜索相關的_EPROCESS對象。
pspcid
csrss ：csrss.exe進程保留著可以在其內存中檢索到的進程的獨立列表。
session
deskthrd
在這些插件中，psxview是分析正在運行的進程的最快方法，它為用戶提供了不同檢測技術。
我們知道隱藏的進程稱為virus.exe，且PID為4952，現在可以利用Volatility進一步研究。
在這種“隱藏”情況下，PID不能直接被Volatility插件使用，因此必須指定進程內存偏移量。
對于大多數波動插件，可以使用存儲器偏移（P代表Physical）代替PID。
有了這個信息，可以獲得很多東西，例如：
打開系統資源的處理（文件，注冊表項…）
進程命令行
驅動程序/rootkit也可以從內存轉儲中恢復
