Windows 10 RS3中的EMET ASR功能優劣分析

介紹

使用EMET 5中的攻擊面減少（ASR）功能的人可能會很喜歡這個功能，因為它能夠輕易的阻止在指定的進程中載入特定的DLL。例如，作為針對Casey Smith的regsvr32.exe腳本攻擊的緩解措施，NSA IAD發布了一個很好的EMET ASR規則集，來阻止在regsvr32.exe上下文中載入scrobj.dll。

從Windows 10 1709開始，EMET 不再受支持，因為它已被Windows Defender Exploit Guard（WDEG）所取代。WDEG也有自己的功能，稱為攻擊面減少，這個功能是阻止Office套件產品創建可疑的子進程的好方法，但它不允許你指定自定義的阻止規則，而且還依賴於Windows Defender反病毒軟體。WDEG ASR雖然很好，但它卻不能提供EMET ASR規則所提供的配置粒度。

據推測，為了彌補這一差距，Windows Defender應用程序控制（以前稱為Device Guard）引入了在特定進程中阻止模塊的功能。

好的一面：是一種相當可靠的阻止濫用DLL的方案

以下文件是建立一個非常簡單的阻止regsvr32.exe載入scrobj.dll的規則集，可以在三行代碼中完成：

$ScrObjBlockRule = New-CIPolicyRule -DriverFilePath $Env:windirSystem32scrobj.dll -Level FileName -Deny -AppID $Env:windirSystem32
egsvr32.exe

# Merge the block rule into the allow all template rule included in the OS

Merge-CIPolicy -OutputFilePath CustomASRPolicy.xml -PolicyPaths $Env:windirschemasCodeIntegrityExamplePoliciesAllowAll.xml -Rules $ScrObjBlockRule

# This must be run elevated. Convert the policy to binary form and copy it to where WDAC will consume it.

ConvertFrom-CIPolicy -XmlFilePath .CustomASRPolicy.xml -BinaryFilePath $Env:windirSystem32CodeIntegritySIPolicy.p7b

# Now reboot and the policy will take effect.

作為參考，這些命令將生成以下XML WDAC策略。

10.0.0.0

Enabled:Unsigned System Integrity Policy

Enabled:Advanced Boot Options Menu

Enabled:UMCI

Enabled:Update Policy No Reboot

0

AllowAll

041417

重新啟動後，策略將生效，scrobj.dll將被阻止載入到regsvr32.exe中，並且將生成Microsoft-Windows-CodeIntegrity / Operational 3077事件。例如，運行以下命令將相應地生成代碼完整性事件：

regsvr32 /s /n /u /i:Backdoor.sct scrobj.dll

代碼完整性事件ID 3077指示scrobj.dll被阻止載入。

隱形攻擊者可能會嘗試通過執行以下操作來逃避檢測：

1.將regsvr32.exe複製到攻擊者控制的位置，並將其重命名為看起來正常的文件名 —— 例如notepad.exe

2.將Backdoor.sct重命名為看起來正常的文件名稱並刪除sct擴展名。

3.將scrobj.dll複製到攻擊者控制的位置，並將其重命名為blah.txt

這種規避策略很可能會規避那種針對檢測惡意regsvr32使用的命令行日誌記錄。一個規避調用的示例可能如下所示:

notepad /s /n /u /i:foo blah.txt

令攻擊者驚訝的是，這個規避姿勢的企圖也被阻止了。

所以我們現在有一種方法可以有效地阻止載入到我們所選擇的進程中的指定的DLL。

壞的一面：繞過阻止規則

考慮到生成的策略允許所有的代碼運行，無論在regsvr32.exe的上下文中的scrobj.dll的簽署者是誰，目前沒有什麼方法可以防止攻擊者更改OriginalFileName屬性中的「scrobj.dll」。 在重命名的blah.txt文件中，「scrobj.dll」的OriginalFileName屬性被簡單地改為「tcrobj.dll」，果然，scrobj.dll規則被規避了，如下面的procmon事件詳細信息所證明的那樣：

scrobj.dll阻止規則繞過

一種可能的緩解措施是在Windows Defender Exploit Guard中嚴格載入regsvr32.exe中僅限微軟簽名的二進位文件：

阻礙

在所有操作系統SKU上均可使用EMET ASR的情況下，必須在Windows 10 Enterprise SKU上配置Windows Defender應用程序控制規則。對於任何想要僅使用WDAC來阻止來自特定進程的模塊的人來說，這可能是一個主要的阻礙。

另一個問題是，因為你正在處理WDAC用戶模式規則，所以用戶模式代碼完整性將被強制執行，這意味著PowerShell將被置於受限語言模式。我認為我可以使用Set-RuleOption cmdlet 設置「Disabled：Script Enforcement」策略規則選項，但是由於受限語言模式仍然有待強制執行，因此它看起來沒有太大意義。

結論

使用Windows Defender應用程序控制模塊阻止規則，是阻止那些攻擊技能比較幼稚的攻擊者將目標DLL載入到特定進程中的一種有效方式，但對於利用規避策略的攻擊者無效。讓阻止規則變得健壯的唯一的可能方式就是將它們與實際的WDAC白名單策略結合起來，原因如下：

1、儘管攻擊者重命名了regsvr32.exe，但在scrobj.dll中修改OriginalFileName將始終被阻止。

2、通過適當的應用程序白名單強制執行，期望應該是適用於PowerShell的規則，在這種情況下，會在受限語言模式中執行。

3、還有很多其他的攻擊變種，其中腳本可以執行並且scrobj.dll可以被用於除regsvr32.exe以外的其他進程，例如mshta，rundll32等。這將需要進行測試，但只是阻止scrobj.dll可能是有意義的，在這種情況下，你只需要編寫一個適用於全局的標準的WDAC拒絕規則。全局拒絕規則的例子可以在這裡找到。

因此，可以得出的最終結論是，模塊阻止規則僅對那些已經部署了強大的WDAC白名單策略的用戶有利。另外，現在應該清楚的是，與EMET ASR規則所使用的規則沒有直接的平行關係。而這不一定是壞事，希望EMET ASR規則能相應地設置均勢的期望。也許最終有一天，微軟將在Windows的所有SKU上開放WDAC策略配置。

我的總體建議是不要單獨使用WDAC模塊阻止規則——即允許所有用戶/內核模式規則同時使用。通過所有的方法來規避這些規則，這些規則只有在適當的WDAC白名單策略中才有意義。如果你想了解更多關於WDAC / Device Guard的信息，請閱讀微軟的官方文檔並閱讀我之前寫的許多關於Device Guard 的文章中的這一篇。。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！