如何在惡意文件中發現VBA清除的證據？
最近安全研究人員發現他們最近找到的惡意Office文檔僅包含VBA源代碼，而沒有經過編譯的代碼。經過認真分析，研究人員發現這是一種被稱之為「VBA清除」的技術，攻擊者如果使用此技術來發起攻擊，則更有可能逃避殺毒軟體的檢測。
VBA清除技術
利用VBA的惡意MS Office文檔將其VBA代碼存儲在「複合文件二進位格式」文件流中，每個VBA模塊，類……都存儲在其自己的模塊流中。模塊流包含與版本和實現有關的PerformanceCache數據（已編譯的VBA代碼，也稱為P-code），然後是CompressedSourceCode數據（已壓縮的VBA源代碼）。
在2016年，保加利亞科學院助理教授、網路安全研究員維塞林邦切夫（VesselinBontchev）就認為存在一種可以刪除或更改壓縮的VBA源代碼並執行P-CODE的技術。在2018年底，該技術被稱為「VBA stomping」。
VBA Stomping 是一種可以繞過反病毒檢測惡意文檔生成技術，該技術可以銷毀 Microsoft Office 文檔中的 VBA 源代碼，只留下文檔文件中稱為 p-code 的宏代碼的編譯版本。在這種情況下，僅基於VBA源代碼的惡意文檔檢測會失敗。
當時的研究表明，該技術還可以刪除PerformanceCache數據（已編譯的VBA代碼，也稱為P-CODE），同時保持完整的VBA源代碼準備執行。所以，研究人員將此技術稱為「VBA清除」（或者是緩存清除）。
PerformanceCache數據和CompressedSourceCode數據之間的邊界由每個模塊流的MODULEOFFSET定義。該MODULEOFFSET是存儲在每個模塊流的dir流中的一條記錄。
要刪除PerformanceCache數據，必須刪除其位元組，以便CompressedSourceCode數據從位置0x0000（流的開頭）開始。模塊流的大小必須相應減小，並且MODULEOFFSET記錄必須指向位置0x0000。
PerformanceCache數據也存在於_VBA_PROJECT流和SRP流中，VBA清除技術意味著從_VBA_PROJECT流中刪除PerformanceCache數據，並完全刪除SRP流。
VBA在野外地利用
多年來，研究人員遇到過的沒有PerformanceCache數據的Office文檔，要麼是良性文檔，要麼是概念證明文檔。但是，最近研究人員發現最有可能是真實惡意軟體的惡意Office文檔（例如，不是PoC文檔）。
「Voo Cancelado Localizador RR9N4V.ppam」 (MD5 730a8401140edb4c79d563f306ca529e)就是這樣一個文檔，該惡意文檔有幾個有趣的方面，不過在這篇文章中，我們僅關注VBA清除方面的內容。
研究人員找到的文檔是PowerPoint載入項（.ppam文件擴展名），這是一個帶有VBA宏的Office Open XML文件（OOXML）：
在此ZIP容器內，文件vbaProject.bin包含VBA代碼，可以使用oledump.py之類的工具進行分析：
使用選項-i，研究人員可以可視化MODULEOFFSET記錄值：
此選項添加了一個額外的列，其中包含PerformanceCache數據和CompressedSourceCode數據的大小。請注意，對於此示例，PerformanceCache數據的大小為0：沒有P-CODE。
_VBA_PROJECT流的大小僅為7個位元組：這只是沒有PerformanceCache數據的標頭。
將此與正常惡意Office文檔進行比較：
此「VBA清除」文檔中的VBA代碼下載並執行託管在GitHub上的VBS腳本：
VBA清除工具
有一些工具可以創建不依賴MS Office組件的Office文檔，例如.NET庫EPPlus（Epplus是一個使用Open Office XML（Xlsx）文件格式，能讀寫Excel 2007/2010文件的開源組件），使用此庫創建的Excel文檔不包含性能緩存數據。
專業的VBA開發人員也使用一些商業工具在發布之前清理他們的文檔，比如這些工具。
我們不知道到底是用什麼工具來實現VBA清除這個文件，但它不是簡單地用PowerPoint保存。當使用MS Office創建帶有VBA代碼的文檔時，它將包含PerformanceCache數據和CompressedSourceCode數據，缺少PerformanceCache數據意味著該文檔是使用其他工具創建/清除的。
刪除惡意文檔的性能緩存數據降低了反病毒檢測的機會，以下是一個示例。
模塊流包含PerformanceCache和CompressedSourceCode數據，然後，沃爾瑪（Walmart）的安全團隊通過用空位元組覆蓋CompressedSourceCode變數來「overwriting」該文檔，這導致VirusTotal的檢測率大大降低（他們在2018年4月進行測試時為7/58對36/59）。
當研究人員採用沃爾瑪安全團隊提供的示例刪除PerformanceCache數據時，還發現VirusTotal的檢測率較低（2019年12月22日為16/58）：
當然，這只是VirusTotal上的一個示例，與在VirusTotal上進行靜態殺毒掃描相比，在生產環境中使用完全可操作的殺毒軟體時，這樣你的檢測結果可能會大不相同。
殺毒軟體不是唯一會受到VBA清除技術影響的工具，比如，有些IDS和YARA規則依賴於僅在PerformanceCache數據中找到的字元串。例如，通常在惡意Office文檔的VBA源代碼中用於創建ActiveX對象（例如HTTP對象）的字元串CreateObject僅出現在PerformanceCache數據中。有些IDS和YARA規則依賴於此字元串的存在。它也出現在VBA源代碼中，由於壓縮，它沒有作為完整的字元串出現在CompressedSourceCode數據中。
總結
攻擊者使用VBA清除技術使用VBA代碼從Office文檔中刪除PerformanceCache數據，這樣在不影響代碼執行的情況下就可以發起攻擊。在這個過程中，VBA清除技術可能會影響殺毒軟體檢測，並且肯定會影響IDS和YARA規則的有效性，這些規則依賴於僅在PerformanceCache數據中找到的字元串。如果你使用或制定此類規則，則建議你根據本文提供的信息進行檢測。
與VBAStomping不同，VBA清除技術並不會讓惡意攻擊留下多少證據。除此之外，還有一些合法工具可以創建沒有PerformanceCache數據的文檔或將其從現有文檔中刪除。
參考及來源：https://blog.nviso.eu/2020/02/25/evidence-of-vba-purging-found-in-malicious-documents/
