無招勝有招： 看我如何通過劫持COM伺服器繞過AMSI

在Windows 10中，Microsoft的反惡意軟體掃描介面（AMSI）被作為新功能被引入，作為標準介面，該功能可以讓反病毒引擎將特徵規則應用於機器的內存和磁碟上的緩衝區中去。這使的反病毒產品能夠在惡意程序的腳本被解釋執行之前執行劫持操作，這在一定程度上意味著任何的代碼混淆或加密都有相對應的常式去還原和解密程序。如果需要更多詳細的有關AMSI的信息，您可以在

這裡閱讀有關AMSI的更多信息。

在這篇文章中，我們將闡述一種通過劫持COM伺服器來繞過AMSI的方法， 並分析Microsoft如何在build＃16232中修復該繞過，然後再討論如何再次繞過微軟對該漏洞的修復。

通過劫持COM伺服器來繞過AMSI的這個問題在5月3日我們向微軟遞交了報告，並且微軟官方已經修復了該漏洞，具體修複信息可見Build＃16232中的「深度防禦」補丁。

在本文中，我們的實驗是一個通過PowerShell進行的AMSI測試示例，測試過程是當AMSI模塊接受外部傳進來的腳本塊並將其傳遞給Defender進行分析的時候進行劫持操作，具體可見下圖所示：

正如你所看到的，AMSI接受了我們構造的惡意代碼並將該代碼塊傳遞給被調用的Invoke-Expression。由於該代碼被認為是惡意的，因此 該代碼塊被阻止執行。這裡需要我們去研究的是：這種阻止惡意代碼執行操作是如何工作的呢 ？之後我們通過查看amsi.dll的導出，可以看到AMSI導出的各種函數調用：

通過查看AMSI導出的函數，我們可以發現一些很重要的函數信息，那就是amsi！DllGetClassObject和amsi！DllRegisterServer這兩個函數 ，因為這些都是COM入口點，這些函數都是用於方便實例化一個COM對象的。幸運的是，COM伺服器易於劫持，因為COM服務在處理 流程上默認在查找HKCR/HKLM之前會去先搜索當前用戶的註冊表配置單元（HKCU） ，以用於COM伺服器來正常處理。這個過程我們在IDA中可以看出，從圖中 我們可以看到COM服務介面ID（IID）和ClassID（CLSID）傳遞給CoCreateInstance（）：

甚至，我們可以通過查看ProcMon來驗證這一點：

通過以上的分析最終我們可以發現，AMSI掃描惡意程序的功能似乎是通過自己的COM伺服器來實現的，該功能在COM伺服器被實例化時被導出。當AMSI載入時，它首先實例化其COM組件，它導出了諸如amsi！AmsiOpenSession，amsi！AmsiScanBuffer，amsi！AmsiScanString和amsi！AmsiCloseSession之類的函數。在這個過程中如果我們強制COM實例化失敗，那麼AMSI將無法調用用來掃描惡意程序內容所需的函數方法。由於COM伺服器首先通過HKCU配置單元進行解析，因此普通用戶可以劫持InProcServer32鍵值並註冊不存在的DLL（或者是一段惡意執行的代碼）。為了做到這一點，有兩個註冊表項需要修改：

劫持COM服務的整個過程是：當AMSI嘗試實例化其COM組件時，它將查詢其在註冊表中註冊的CLSID並返回 一個不存在的數值。這將導致其載入失敗，並阻止任何掃描惡意軟體的方法被訪問，最終使得AMSI不可使用。您可以看到，導入上述更改的註冊表將導致COM伺服器返回」C:IDontExist」：

現在，當我們嘗試運行我們的「惡意」的AMSI測試樣本時，我們可以發現我們的惡意代碼段被允許執行，因為AMSI無法通過其COM介面訪問任何掃描惡意程序的方法 ，結果如下圖所示：

您可以在這裡找到更改註冊表的方法：

https://gist.github.com/enigma0x3/00990303951942775ebb834d5502f1a6

現在我們可以看看微軟如何在build＃16232中修復該漏洞。由於amsi.dll也是AMSI的COM伺服器，因此將這兩個DLL分開似乎是一個很好的修復方法。我們來看一下漏洞被修復前後的不同，從圖中可以看到AmsiInitialize函數，它可能包含了實際實例化AMSI的邏輯代碼。

在左側，我們有舊的AMSI DLL，在右邊，我們有新更新的AMSI DLL。如您所見，Microsoft似乎刪除了對CoCreateInstance（）的調用，並將其替換為直接調用DllGetClassObject（）。 CoCreateInstance（）可以定義為高級函數，該函數用於實例化使用CoGetClassObject（）生成的COM常式 。該函數解析完成後（部分通過註冊表CLSID查找）以及定位到COM伺服器後，伺服器的導出函數「DllGetClassObject（）」將被調用。通過直接調用amsi.dll的DllGetClassObject（）函數替換CoCreateInstance，這一修復方法避免了註冊表解析操作，由於AMSI不再在COM伺服器的註冊表中查詢CLSID，因此我們無法再劫持它。

現在我們知道修復，那麼我們如何去繞過它呢？在進行研究之前，我們需要明白的是：基本上，腳本解釋器（如PowerShell）從工作目錄載入amsi.dll，而不是從安全路徑（如System32）載入它。由於這個原因，我們可以將PowerShell.exe複製到我們可以寫入的目錄，並 將易受攻擊的amsi.dll版本放到這個目錄中。通過這些操作後，我們獲許就可以劫持DLL，或者我們可以創建相同的註冊表項來劫持AMSI的COM組件。由於這個易受攻擊的AMSI版本仍然調用CoCreateInstance（）函數，因此我們仍然可以通過劫持註冊表的搜索順序來劫持AMSI，整個操作方法如下：

首先，我們可以通過為powershell.exe和AMSI的CLSID創建一個ProcMon過濾器來驗證修補後的amsi.dll版本不再通過註冊表查詢COM伺服器。 當PowerShell啟動時，您將注意到沒有任何條目出現：

接下來，我們刪除易受攻擊的AMSI DLL並將PowerShell移動到同一目錄。 如您所見，現在正在查詢註冊表以查找AMSI的COM伺服器：

使用易受攻擊的AMSI DLL，從圖中可以看出我們現在可以執行COM伺服器劫持：

總結：

儘管微軟在補丁＃16232中對該漏洞進行了修復，但仍然可以通過使用舊的，易受攻擊的AMSI DLL執行DLL劫持來執行劫持操作。 關於防禦方法，我們覺得對那些在正常目錄之外執行任何的二進位文件（wscript，cscript，PowerShell）操作進行監視操作將是一個好的想法。 由於繞過修復補丁需要將二進位文件移動到用戶可寫位置，所以在非標準位置執行這些命令可以被當成一種異常的操作行為。

*本文作者：liulang，轉載請註明來自 FreeBuf.COM

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