?什么是模塊篡改保護(hù)？

模塊篡改保護(hù)是一種緩解措施，可防止對進(jìn)程主映像的早期修改，例如 IAT 掛鉤或進(jìn)程空心化。它一共使用了三個 API：NtQueryVirtualMemory、NtQueryInformationProcess 和 NtMapViewOfSection。如果啟用，加載程序?qū)⒃谡{(diào)用入口點(diǎn)之前檢查主圖像標(biāo)頭和 IAT 頁面中的更改。它通過使用信息類 MemoryWorkingSetExInformation 調(diào)用 NtQueryVirtualMemory 來做到這一點(diǎn)。返回的結(jié)構(gòu)包含有關(guān)頁面共享狀態(tài)的信息，以及是否從其原始視圖修改。如果標(biāo)頭或 IAT 已從其原始映射修改。例如，如果主圖像已被取消映射，并且已在其位置映射了另一個圖像，則加載器將使用類 ProcessImageSection 調(diào)用 NtQueryInformationProcess 以獲取主圖像部分，然后將使用 NtMapViewOfSection 重新映射它。這樣，新部分將被使用，篡改的圖像副本將被忽略。

此緩解從 RS3 開始可用，并且可以使用 PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK 在進(jìn)程創(chuàng)建時啟用。

模塊篡改保護(hù)緩解措施是如何發(fā)現(xiàn)的

如果微軟從未宣布或記錄某些緩解措施，那人們?nèi)绾尾拍馨l(fā)現(xiàn)這些緩解措施？因此，一個值得關(guān)注的好地方是 EPROCESS 結(jié)構(gòu)中的各種 MitigationFlags 字段。目前存在三個 MitigationFlags 字段（MitigationFlags、MitigationFlags2、MitigationsFlags3），每個字段包含 32 位。在前兩個中，整個32位已經(jīng)被使用，所以最近添加了MitigationFlags3，目前包含三個緩解措施，我相信很快會添加更多。這些標(biāo)志代表進(jìn)程中啟用的緩解措施。例如，我們可以使用 WinDbg 為當(dāng)前進(jìn)程打印 EPROCESS.MitigationFlags：

最后，在位 28 和 29 中，我們可以看到值 EnableModuleTamperingProtection 和 EnableModuleTamperingProtectionNoInherit。不幸的是，搜索這些名稱并沒有得到任何好的結(jié)果。有幾個網(wǎng)站只顯示結(jié)構(gòu)而沒有解釋，一個模糊的堆棧溢出答案簡要提到了 EnableModuleTamperingProtectionNoInherit 而沒有添加細(xì)節(jié)，還有這條推文：

不出所料，最詳細(xì)的解釋是 Alex Ionescu 2017 年發(fā)布的一條推文。這雖并不是完整的文檔，但它是一個開始。如果你已經(jīng)了解并理解構(gòu)成此緩解措施的概念，那么這一系列的推文可能會非常清楚地解釋有關(guān)該特性的所有內(nèi)容。

開始搜索進(jìn)程緩解實(shí)現(xiàn)的第一個地方通常是內(nèi)核：ntoskrnl.exe。然而，這是一個巨大的二進(jìn)制文件，不容易搜索。似乎沒有與此緩解措施完全相關(guān)的函數(shù)名稱，所以沒有明顯的地方可以開始。

相反，你可以嘗試不同的方法并嘗試找到對 EPROCESS 的 MitigationFlags 字段的引用，并可以訪問這兩個標(biāo)志中的一個。但除非你可以訪問 Windows 源代碼，否則沒有簡單的方法可以做到這一點(diǎn)。但是，你可以做的是利用 EPROCESS 是一個大型結(jié)構(gòu)并且 MitigationFlags 存在于它的末尾，偏移量 0x9D0 的事實(shí)。一種非常粗暴但有效的方法是使用 IDA 搜索功能并搜索所有對 9D0h 的引用：

這會很慢，因?yàn)樗且粋€很大的二進(jìn)制文件，并且一些結(jié)果與 EPROCESS 結(jié)構(gòu)無關(guān)，因此你必須手動搜索結(jié)果。此外，僅查找對該字段的引用是不夠的，MitigationFlags 包含 32 位，其中只有兩個與當(dāng)前上下文相關(guān)。所以，你必須搜索所有的結(jié)果，找出以下情況：

0x9D0被用作EPROCESS結(jié)構(gòu)的偏移量——因?yàn)闊o法保證知道每種情況使用的結(jié)構(gòu)類型，盡管對于較大的偏移量，只有少數(shù)選項(xiàng)可以是相關(guān)的，它主要可以通過函數(shù)名稱和上下文來猜測。

比較或設(shè)置MitigationFlags字段為0x10000000 (EnableModuleTamperingProtection)或0x20000000 (EnableModuleTamperingProtectionNoInherit)。或者通過諸如bt或bts之類的匯編指令，按位數(shù)測試或設(shè)置位28或位29。

運(yùn)行搜索后，結(jié)果看起來像這樣：

你現(xiàn)在可以瀏覽結(jié)果并了解內(nèi)核使用了哪些緩解標(biāo)志以及在哪些情況下使用。然后我會告訴你，這個努力完全沒有用，因?yàn)?EnableModuleTamperingProtection 在內(nèi)核中的一個地方被引用：PspApplyMitigationOptions，當(dāng)創(chuàng)建一個新進(jìn)程時調(diào)用：

因此，內(nèi)核會跟蹤是否啟用了此緩解措施，但從不對其進(jìn)行測試。這意味著緩解措施本身在其他地方實(shí)現(xiàn)。這種搜索可能對這種特定的緩解措施毫無用處，但它是找出緩解措施實(shí)現(xiàn)位置的幾種方法之一，并且對其他流程緩解措施很有用，所以我想提一下它。

現(xiàn)在讓我們回到模塊篡改保護(hù)，有時會實(shí)現(xiàn)進(jìn)程緩解的第二個位置是 ntdll.dll，它是每個進(jìn)程中要加載的第一個用戶模式映像。此 DLL 包含所有進(jìn)程所需的加載程序、系統(tǒng)調(diào)用存根和許多其他基本組件。在這里實(shí)現(xiàn)這種緩解是有意義的，因?yàn)轭櫭剂x它與模塊加載有關(guān)，這通過 ntdll.dll 中的加載器發(fā)生。此外，這是一個包含 Alex 在他的推文中提到的功能的模塊。

即使我們沒有這條推文，只要打開 ntdll 并搜索“tampering”，我們就能很快找到一個結(jié)果：函數(shù) LdrpCheckPagesForTampering。尋找這個函數(shù)的調(diào)用者，我們看到它是從LdrpGetImportDescriptorForSnap調(diào)用的：

在截圖的第一行，我們可以看到兩個檢查：第一個驗(yàn)證當(dāng)前正在處理的條目是主圖像，因此該模塊被加載到主圖像模塊中。第二個檢查是 LdrSystemSllInitBlock.MitigationOptionsMap.Map中的兩個位。我們可以看到這里檢查的確切字段只是因?yàn)槲覍?LdrSystemDllInitBlock 應(yīng)用了正確的類型，如果你在沒有應(yīng)用正確類型的情況下查看這個函數(shù)，你會看到一些隨機(jī)的、未命名的內(nèi)存地址被引用。 LdrSystemDllInitBlock 是一個數(shù)據(jù)結(jié)構(gòu)，包含加載程序所需的所有全局信息，例如進(jìn)程緩解選項(xiàng)。它沒有記錄，但具有符號中可用的 PS_SYSTEM_DLL_INIT_BLOCK 類型，因此我們可以在此處使用它。請注意，雖然此結(jié)構(gòu)在 NTDLL 符號中不可用，而是你可以在 ole32.dll 和 combase.dll 的符號中找到它。 MitigationOptionsMap 字段只是三個 ULONG64 的數(shù)組，其中包含標(biāo)記為此過程設(shè)置的緩解選項(xiàng)的位。我們可以在 WinBase.h 中找到所有緩解標(biāo)志的值。以下是模塊篡改保護(hù)的值：

這些值與 Map 頂部的 DWORD 相關(guān)，因此模塊篡改保護(hù)位實(shí)際上位于 Map的第 44 位，在 Hex Rays 屏幕截圖中以及在 PspApplyMitigationOptions 中檢查的是相同位。

現(xiàn)在我們知道該緩解措施在哪里應(yīng)用了檢查，因此我們可以開始查看實(shí)現(xiàn)并了解該緩解措施的作用。

實(shí)現(xiàn)細(xì)節(jié)

再次查看 LdrpGetImportDescriptorForSnap：在我們已經(jīng)看到的兩次檢查之后，該函數(shù)獲取主圖像的 NT 標(biāo)頭并調(diào)用 LdrpCheckPagesForTampering 兩次。第一次發(fā)送的地址是 imageNtHeaders->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]，圖像的導(dǎo)入表，大小為 8 個字節(jié)。第二次使用 NT 標(biāo)頭本身的地址和大小調(diào)用該函數(shù)。如果這些頁面中的一個被認(rèn)為被篡改了，LdrpMapCleanModuleView將被調(diào)用(根據(jù)名稱判斷)映射主圖像模塊的一個干凈的視圖。

讓我們看看 LdrpCheckPagesForTampering 內(nèi)部，看看 NTDLL 如何判斷一個頁面是否被篡改：

首先，此函數(shù)計(jì)算請求的字節(jié)范圍內(nèi)的頁數(shù)（在本文的兩個示例中，該數(shù)字都是 1）。然后它分配內(nèi)存并使用 MemoryInformationClass == 4 (MemoryWorkingSetExInformation) 調(diào)用 ZwQueryVirtualMemory。這個系統(tǒng)調(diào)用和信息類是安全人員可能不太經(jīng)常看到的，工作集是一種基于物理內(nèi)存頁面當(dāng)前狀態(tài)來管理和優(yōu)先級排序的方法，因此大多數(shù)安全人員通常不感興趣。然而，工作集確實(shí)包含一些我們感興趣的屬性。具體來說，是“共享”標(biāo)志。

我不會在這里詳細(xì)介紹映射和共享內(nèi)存，因?yàn)樗鼈冊诤芏嗥渌胤蕉加薪忉尅５喍灾到y(tǒng)盡量不復(fù)制內(nèi)存，因?yàn)檫@意味著物理內(nèi)存將很快被復(fù)制的頁面填滿，主要是那些屬于圖像和 DLL 的頁面， 像 ntdll.dll 或 kernel32.dll 的系統(tǒng) DLL被映射到大多數(shù)系統(tǒng)中的進(jìn)程，因此在物理內(nèi)存中為每個進(jìn)程單獨(dú)創(chuàng)建一個副本只是浪費(fèi)。因此，這些圖像頁面在所有進(jìn)程之間共享。也就是說，除非以任何方式修改圖像。圖像頁面使用一種稱為“寫時復(fù)制(copy-on-write)”的特殊保護(hù)，它允許頁面可寫，但如果頁面被寫入，則會在物理內(nèi)存中創(chuàng)建一個新副本。這意味著對 DLL 的本地映射所做的任何更改（例如，用戶模式掛鉤的寫入或任何數(shù)據(jù)更改）都只會影響當(dāng)前進(jìn)程中的 DLL。

這些設(shè)置保存為可以通過 NtQueryVirtualMemory 查詢的標(biāo)志，這里使用的信息類：MemoryWorkingSetExInformation。它將在 MEMORY_WORKING_SET_EX_INFORMATION 結(jié)構(gòu)中返回有關(guān)查詢頁面的數(shù)據(jù)：

這個結(jié)構(gòu)為你提供了被查詢的虛擬地址，以及包含頁面狀態(tài)信息的位，例如：它的有效性、保護(hù)以及它的共享狀態(tài)。有幾個不同的位與頁面的共享狀態(tài)相關(guān)：

共享——頁面是可共享的嗎？這并不一定意味著該頁當(dāng)前與任何其他進(jìn)程共享，但是，例如，除非進(jìn)程特別請求，否則私有內(nèi)存不會被共享。

ShareCount——此字段告訴你此頁面存在多少映射。對于當(dāng)前未與任何其他進(jìn)程共享的頁面，這將是 1。對于與其他進(jìn)程共享的頁面，這通常會更高。

SharedOriginal ——該標(biāo)志會告訴你該頁面是否存在映射。因此，如果一個頁面被修改，導(dǎo)致在物理內(nèi)存中創(chuàng)建一個新副本，這將被設(shè)置為零，因?yàn)檫@不是頁面的原始映射。

此 SharedOriginal 位是由 LdrpCheckPagesForTampering 檢查的，以判斷此頁面是原始副本還是由于更改而創(chuàng)建的新副本。如果這不是原始副本，這意味著該頁面以某種方式被篡改，因此該函數(shù)將返回 TRUE。 LdrpCheckPagesForTampering 對正在查詢的每個頁面運(yùn)行此檢查，如果其中任何一個被篡改，則返回 TRUE。

如果函數(shù)對任何檢查范圍返回 TRUE，則調(diào)用 LdrpMapCleanModuleView：

這個函數(shù)簡短而簡單：它使用 InformationClass == 89 (ProcessImageSection) 調(diào)用 NtQueryInformationProcess 來獲取主圖像的部分句柄，然后使用 NtMapViewOfSection 重新映射它并關(guān)閉句柄。它將新部分的地址寫入 DataTableEntry->SwitchBackContect，以代替原來的篡改映射。

為什么該特性特別選擇檢查這兩個范圍——導(dǎo)入表和 NT 標(biāo)頭？

這是因?yàn)檫@兩個地方經(jīng)常會成為試圖虛化進(jìn)程的攻擊者的目標(biāo)。如果主圖像未映射并被惡意圖像替換，則 NT 標(biāo)頭將不同并被視為已篡改。進(jìn)程空心化（Process hollowing）還可以篡改導(dǎo)入表，以指向與進(jìn)程預(yù)期不同的函數(shù)。所以，這主要是一個反空心化的功能，目標(biāo)是發(fā)現(xiàn)主圖像中的篡改企圖，并用一個沒有被篡改的新圖像副本替換它。

功能限制

不幸的是，此功能相對有限。你可以啟用或禁用它，僅此而已。實(shí)現(xiàn)緩解的函數(shù)是內(nèi)部調(diào)用，不能在外部調(diào)用。因此，例如，除非你自己編寫代碼（并手動映射模塊，因?yàn)檫@些部分的句柄不方便地存儲在任何地方），否則不可能將緩解擴(kuò)展到其他模塊。此外，此緩解不包含日志記錄或 ETW 事件。當(dāng)緩解通知在主圖像中被篡改時，它會靜默映射并使用新副本，并且不會留下任何痕跡供安全產(chǎn)品或團(tuán)隊(duì)查找。唯一的提示是 NtMapViewOfSection 將再次為主圖像調(diào)用并生成 ETW 事件和內(nèi)核回調(diào)。但這很可能會被忽視，因?yàn)樗⒉灰欢ㄒ馕吨l(fā)生了不好的事情，并且可能不會導(dǎo)致任何警報(bào)或?qū)赡苁钦嬲墓舻闹卮笳{(diào)查。

從好的方面來說，這種緩解非常簡單和有用，如果你想實(shí)現(xiàn)它，則很容易模仿，例如檢測放置在你的進(jìn)程上的鉤子并映射一個新的、未掛鉤的頁面副本以供使用。你可以這樣做，而不是使用直接系統(tǒng)調(diào)用！

該緩解措施有人使用過嗎？

在 WinDbg 中運(yùn)行查詢，我沒有發(fā)現(xiàn)任何啟用模塊篡改保護(hù)的進(jìn)程的結(jié)果。經(jīng)過一番探索，我設(shè)法找到了一個啟用此功能的進(jìn)程：SystemSettingsAdminFlows.exe。此過程在你打開 Windows 設(shè)置菜單中的應(yīng)用程序->可選功能時執(zhí)行。我不知道為什么這個特定的進(jìn)程會使用這種緩解措施，或者為什么它是唯一一個這樣做的，但這是迄今為止我設(shè)法找到的唯一一個啟用模塊篡改保護(hù)的過程。

本文翻譯自：https://windows-internals.com/understanding-a-new-mitigation-module-tampering-protection/