如何利用COM繞過AppLocker CLM

這篇文章給大家介紹如何利用COM繞過AppLocker CLM，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

前言

受限語言模式是PowerShell限制用戶訪問高級功能的一種方式，暫且不管微軟怎么說的，這個功能本質上是一種安全控制措施，很多防御者可以利用這種功能來阻止類似“Invoke-Mimikatz”這樣的工具。

不管微軟方面是怎么看待的，這個功能目前已經被大家當做一種安全控制功能了，因為它可以幫助防御人員阻止類似“Invoke-Mimikatz”這樣的工具運行。在這篇文章中，我將告訴大家如何以非管理員用戶的身份繞過這種保護機制。

直奔主題

我們首先要做的就是在我們的實驗環境中啟用AppLocker。這篇文章中，在啟用腳本限時時，我將使用Windows分配的默認角色。開啟了應用程序識別服務之后，我們就可以使用下列命令來確保CLM已成功啟用：

$ExecutionContext.SessionState.LanguageMode

這里我們可以看到程序返回的值，這表明我們已經處于受限環境了。我們還可以在PowerShell中嘗試執行受限命令來二次確認：

Add-Type"namespace test { }"

既然我們已經啟用了CLM，那我們應該怎么繞過它呢？

AppLockerCLM中的New-Object

有趣的是，當我在尋找CLM的攻擊面時，我發現當CLM通過AppLocker啟用時，會出現一個New-Object，大家看看下面這條命令：

New-Object-ComObject WScript.Shell

這樣一來，我們好像就可以直接在PowerShell里面修改PowerShell進程了，因為COM對象通過DLL暴露在外，并且能夠直接被加載到調用進程中。那么我們如何才能創建一個待加載的COM對象呢？如果我們查看ProcMon調用New-Object -ComObject xpntest的過程，我們就可以看到大量針對HKEY_CURRENT_USER注冊表項的請求：

研究了半天之后，我們發現，我們可以在下面這段腳本的幫助下直接在HKCU中創建所需要的注冊表鍵：

現在，如果我們嘗試加載我們自己的COM對象，我們會發現自定義的DLL會被加載到PowerShell進程空間中：

這就很棒了，現在我們已經可以向PowerShell中注入任意DLL了，無需調用動作太大的CreateRemoteThread或者WriteProcessMemory，而且所有操作都是在受限場景下實現的。但我們的目標是繞過CLM，如何利用我們的非托管DLL加載方式來實現？我們可以利用.NET CLR，或者更確切一點，我們可以通過非托管DLL加載.NET CLR來調用.NET 工具。

非托管DLL->托管DLL->反射

現在我們可以使用Cobalt Strike這樣的工具，這款工具提供了Execute-Assembly功能，可以將CLR加載到非托管進程中，我在GIST上給大家提供了一份代碼，它可以獨立完成這個任務：

這里我就不詳細介紹代碼內容了，感興趣的同學可以參考微軟給出的【官方示例】，這段代碼可以讓DLL加載.NET CLR，并加載.NET工具，最后將執行權限轉移給特定的方法。

完成之后，我們就可以訪問.NET了，重要的是，我們可以訪問的是.NET的反射功能，接下來我們要做的就是如何啟用/禁用CLM了。

System.Management.Automation.Runspaces.RunspaceBase.LanguageMode屬性中有一個地方可以識別當前的語言模式。由于我們要使用反射技術，因此需要找到引用Runspace的變量，然后在運行時修改該變量。我覺得最好的實現方法就是利用Runspaces.Runspace.DefaultRunspace.SessionStateProxy.LanguageMode：

編譯為.NET工具之后，我們就可以利用反射的方式來禁用CLM了，這里我們只需要創建并運行一個PowerShell腳本【下載地址】即可：

這樣就搞定啦！

演示視頻

攻擊原理

為什么COM可以繞過這種保護機制？PowerShell又是如何處理COM加載的呢？我們可以在SystemPolicy.IsClassInApprovedList方法中找到答案，這個方法可以用來檢查程序是否允許我們向New-Object提供CLSID。下面這段代碼負責的是核心檢測功能：

if(SystemPolicy.WldpNativeMethods.WldpIsClassInApprovedList(ref clsid, refwldp_HOST_INFORMATION, ref num, 0u) >= 0 && num == 1) { ... }

這個函數調用只是WldpIsClassInApprovedList函數（位于wldp.dll中）的一個封裝函數，而后者主要用來檢查CLSID是否匹配DeviceGuard（現已更名為Windows Defender Application Control）策略。由于該方法沒有考慮到AppLocker，這意味著任何通過檢查的CLSID都可以使用。

意外發現

在測試這項技術的過程中，我遇到過一次奇怪的情況，當我們使用如下方法設置CLM時，這項技術就無法正常使用了：

$ExecutionContext.SessionState.LanguageMode= "ConstrainedLanguage"

這就很尷尬了，因為之前我都是使用上述命令來測試Payload的，現在有什么區別嗎？重新檢查了我們的反匯編代碼之后，我在Microsoft.Powershell.Commands.Utility.dll那里找到了問題的答案。這個文件的具體路徑位于NewObjectCommand類的BeginProcessing方法中：

這里我們可以看到上述的代碼中存在兩條代碼路徑，具體使用哪一條取決于CLM的啟用方式。如果SystemPolicy.GetSystemLockdownPolicy返回的是Enfore，即執行第一條路徑，此時的AppLocker或者DeviceGuard將被啟用。如果直接設置這個參數，則會直接進入if (!flag)…代碼段，此時就會拋出異常。實際上，CLM會根據具體的啟用方法（是通過AppLocker、DeviceGuard，還是通過LanguageMode屬性來啟用）而有不同的行為。

本文介紹的方法并不是繞過CLM的唯一方法，即使粗略分析PowerShell，我們也能找到實現類似效果的其他方法。

關于如何利用COM繞過AppLocker CLM就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。