如何利用COM繞過AppLocker CLM

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

前言

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

不管微軟方面是怎么看待的，這個(gè)功能目前已經(jīng)被大家當(dāng)做一種安全控制功能了，因?yàn)樗梢詭椭烙藛T阻止類似“Invoke-Mimikatz”這樣的工具運(yùn)行。在這篇文章中，我將告訴大家如何以非管理員用戶的身份繞過這種保護(hù)機(jī)制。

直奔主題

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

$ExecutionContext.SessionState.LanguageMode

這里我們可以看到程序返回的值，這表明我們已經(jīng)處于受限環(huán)境了。我們還可以在PowerShell中嘗試執(zhí)行受限命令來二次確認(rèn)：

Add-Type"namespace test { }"

既然我們已經(jīng)啟用了CLM，那我們應(yīng)該怎么繞過它呢？

AppLockerCLM中的New-Object

有趣的是，當(dāng)我在尋找CLM的攻擊面時(shí)，我發(fā)現(xiàn)當(dāng)CLM通過AppLocker啟用時(shí)，會(huì)出現(xiàn)一個(gè)New-Object，大家看看下面這條命令：

New-Object-ComObject WScript.Shell

這樣一來，我們好像就可以直接在PowerShell里面修改PowerShell進(jìn)程了，因?yàn)镃OM對(duì)象通過DLL暴露在外，并且能夠直接被加載到調(diào)用進(jìn)程中。那么我們?nèi)绾尾拍軇?chuàng)建一個(gè)待加載的COM對(duì)象呢？如果我們查看ProcMon調(diào)用New-Object -ComObject xpntest的過程，我們就可以看到大量針對(duì)HKEY_CURRENT_USER注冊(cè)表項(xiàng)的請(qǐng)求：

研究了半天之后，我們發(fā)現(xiàn)，我們可以在下面這段腳本的幫助下直接在HKCU中創(chuàng)建所需要的注冊(cè)表鍵：

現(xiàn)在，如果我們嘗試加載我們自己的COM對(duì)象，我們會(huì)發(fā)現(xiàn)自定義的DLL會(huì)被加載到PowerShell進(jìn)程空間中：

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

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

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

這里我就不詳細(xì)介紹代碼內(nèi)容了，感興趣的同學(xué)可以參考微軟給出的【官方示例】，這段代碼可以讓DLL加載.NET CLR，并加載.NET工具，最后將執(zhí)行權(quán)限轉(zhuǎn)移給特定的方法。

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

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

編譯為.NET工具之后，我們就可以利用反射的方式來禁用CLM了，這里我們只需要?jiǎng)?chuàng)建并運(yùn)行一個(gè)PowerShell腳本【下載地址】即可：

這樣就搞定啦！

演示視頻

攻擊原理

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

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

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

意外發(fā)現(xiàn)

在測(cè)試這項(xiàng)技術(shù)的過程中，我遇到過一次奇怪的情況，當(dāng)我們使用如下方法設(shè)置CLM時(shí)，這項(xiàng)技術(shù)就無法正常使用了：

$ExecutionContext.SessionState.LanguageMode= "ConstrainedLanguage"

這就很尷尬了，因?yàn)橹拔叶际鞘褂蒙鲜雒顏頊y(cè)試Payload的，現(xiàn)在有什么區(qū)別嗎？重新檢查了我們的反匯編代碼之后，我在Microsoft.Powershell.Commands.Utility.dll那里找到了問題的答案。這個(gè)文件的具體路徑位于NewObjectCommand類的BeginProcessing方法中：

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

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

關(guān)于如何利用COM繞過AppLocker CLM就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。