一種劫持COM伺服器並繞過微軟反惡意軟體掃描介面的方法

Microsoft的反惡意軟體掃描介面（AMSI）在Windows 10中被引入，作為標準介面，它可以讓AV引擎將簽名應用於內存和磁碟上的緩衝區。這使得AV產品能夠在腳本解釋之前「hook」，這意味著任何經過混淆或加密的PS程序都經過了解密程序的解密。你可以在這裡和這裡閱讀有關AMSI的更多信息。這篇文章將介紹一種通過劫持COM伺服器來繞過AMSI的方式，並分析Microsoft是如何在build＃16232 中修復它的，然後我又是如何繞過該修復的。

這個問題在5月3日提交給了微軟，並且已經得到修復，並發布了Build＃16232中的「深度防禦」補丁。

下面是一個通過PowerShell進行的AMSI測試示例，當AMSI接受暴露的腳本塊並將其傳遞給Defender進行分析時，內容如下：

正如你所看到的，AMSI接受了代碼並將其傳遞給被調用的Invoke-Expression。由於該代碼被認為是惡意的，因此被阻止執行。

那麼問題來了：這個過程是如何工作的？ 查看amsi.dll的導出，可以看到AMSI導出的各種函數調用：

amsi！DllGetClassObject和amsi！DllRegisterServer很快引發我的思考，因為這些都是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（或者如果你也可以執行惡意的代碼）。為了做到這一點，有兩個註冊表項需要處理：

當AMSI嘗試實例化其COM組件時，它將查詢其註冊的CLSID並返回不存在的COM伺服器。這導致載入失敗，並阻止任何掃描方法被訪問，最終使AMSI不可用。

你可以看到，導入上述註冊表更改將導致「C： IDontExist」作為COM伺服器返回：

現在，當我們嘗試運行我們的「惡意」AMSI測試樣本時，你將注意到它被允許執行，因為AMSI無法通過其COM介面訪問任何掃描方法：

你可以在這裡找到註冊表更改：

現在我們可以理解這個bug了，那麼我們來看看微軟是如何在build＃16232中修復它的。由於amsi.dll也是AMSI的COM伺服器，因此將這兩個DLL分開似乎是一個很好的辦法。看到diff，AmsiInitialize函數突出顯示，因為它可能包含了實際實例化AMSI的邏輯。

在左側，是原來的AMSI DLL，在右邊的是新更新的AMSI DLL。如你所見，Microsoft似乎刪除了對CoCreateInstance（）的調用，並將其替換為直接調用DllGetClassObject（）。CoCreateInstance（）可以定義為用於實例化使用CoGetClassObject（）實現的COM對象的高級函數。在分辨完成（部分通過註冊表CLSID查找）和定位COM伺服器之後，伺服器的導出函數「DllGetClassObject（）」將被調用。通過直接調用amsi.dll的DllGetClassObject（）函數替換CoCreateInstance，避免了註冊表解析。由於AMSI不再在COM伺服器的註冊表中查詢CLSID，因此我們無法再劫持它。

現在我們知道了修復過程，那麼我們該如何去繞過它呢？在進行繞過之前，重要的是我們要明白，自2006年以來，這個特定的bug已被公布和討論。基本上，腳本解釋器（如PowerShell）從工作目錄載入amsi.dll，而不是從安全路徑（如System32）載入它。由於這個原因，我們可以將PowerShell.exe複製到我們可以寫入的目錄，並載入易受攻擊的amsi.dll版本。基於這一點，我們可以利用bat劫持DLL，或者我們可以創建相同的註冊表項來劫持AMSI的COM組件。由於這個易受攻擊的AMSI版本仍然會調用CoCreateInstance（），我們可以再次劫持註冊表搜索順序。

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

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

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

檢測方案：儘管在構建＃16232補丁中進行了修復，但仍然可以通過使用舊的，易受攻擊的AMSI DLL執行DLL劫持來執行此操作。為了檢測這種攻擊手法，監視對於在其正常目錄之外執行的任何二進位文件（wscript，cscript，PowerShell）（通過命令行日誌記錄等）是比較理想的方法。由於繞過修復程序需要將二進位文件移動到用戶可寫位置，所以在非標準位置執行這些命令就可以抓住這一攻擊行為。

點擊展開全文

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