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

創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站制作、網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的阜寧網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

前言

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

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

直奔主題

我們首先要做的就是在我們的實驗環(huán)境中啟用AppLocker。這篇文章中，在啟用腳本限時時，我將使用Windows分配的默認(rèn)角色。開啟了應(yīng)用程序識別服務(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的攻擊面時，我發(fā)現(xiàn)當(dāng)CLM通過AppLocker啟用時，會出現(xiàn)一個New-Object，大家看看下面這條命令：

New-Object-ComObject WScript.Shell

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

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

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

這就很棒了，現(xiàn)在我們已經(jīng)可以向PowerShell中注入任意DLL了，無需調(diào)用動作太大的CreateRemoteThread或者WriteProcessMemory，而且所有操作都是在受限場景下實現(xiàn)的。但我們的目標(biāo)是繞過CLM，如何利用我們的非托管DLL加載方式來實現(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ú)立完成這個任務(wù)：

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

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

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

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

這樣就搞定啦！

演示視頻

攻擊原理

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

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

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

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

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

$ExecutionContext.SessionState.LanguageMode= "ConstrainedLanguage"

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

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

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

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

本文名稱：如何利用COM繞過AppLockerCLM
本文網(wǎng)址：http://chinadenli.net/article42/giogec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站設(shè)計、網(wǎng)站導(dǎo)航、動態(tài)網(wǎng)站、手機(jī)網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)