譯者：知道創宇404實驗室翻譯組
原文鏈接：https://blog.nviso.eu/2020/09/01/epic-manchego-atypical-maldoc-delivery-brings-flurry-of-infostealers/

前言

2020年7月，NVISO檢測到一組惡意Excel文檔，也稱為“ maldocs”，它們通過VBA激活的電子表格傳遞惡意軟件。盡管我們曾見過惡意的VBA代碼和掉落的有效載荷，但創建Excel文檔本身的特定方式引起了我們的注意。

惡意Excel文檔的創建者使用了一種技術，使他們無需實際使用Microsoft Office即可創建裝載宏的Excel工作簿。但是在這種特定工作方式下，這些文檔的檢測率通常低于標準maldocs。

這篇文章概述了這些惡意文檔的產生方式。此外，它簡要描述了觀察到的有效負載，最后以建議和危害指標結尾，以幫助保護組織免受此類攻擊。

主要發現

惡意的Microsoft Office文檔是使用EPPlus軟件而不是Microsoft Office Excel創建的，這些文檔可能與典型的Excel文檔不同，所以可能會受到關注。

NVISO基于上載到VirusTotal等服務的有限數量的文件，以及整個活動中有效載荷傳遞的相似性，以中等可信度評估該活動，這是由單個攻擊者執行的。

直到這篇文章發布之日為止，觀察到的有效負載在大多數情況下都是所謂的信息竊取者，他們的目的是從瀏覽器，電子郵件客戶端等中獲取密碼。

這些文件中產生的有效載荷僅在混淆和偽裝方面有所發展。

分析

下面的分析部分分為兩個部分，涉及感染鏈中的特定鏈接。

惡意文件分析

在較早的文章中，我們寫了有關“ VBA清除” [1]的技術，該技術可從VBA項目中刪除已編譯的VBA代碼。我們很想知道是否有在野外發現的惡意文件正在采用這種技術（它降低了防病毒產品的初始檢測率）。

最初，我們認為它們是使用Excel創建的，然后被VBA清除。但是仔細研究，我們發現，這些文檔是使用.NET庫創建的，該庫創建了Office Open XML（OOXML）電子表格。如我們的VBA清除博客文章所述，使用完全獨立于Microsoft Office的工具創建Office文檔時，它們也可能缺少已編譯的VBA代碼。EPPlus是這樣的工具。我們對這個.NET庫很熟悉，因為幾年來一直在使用它來為我們的紅色團隊和滲透測試人員創建惡意文檔（“ maldocs”）。

當我們注意到maldocs沒有經過編譯的代碼，并且也缺少Office元數據時，我們很快想到了EPPlus。該庫還將創建OOXML文件，而無需編譯VBA代碼和Office元數據。

OOXML文件格式是一種開放包裝約定（OPC）格式：一種ZIP容器，主要包含XML文件，可能還包含二進制文件（如圖片）。它是由Microsoft在Office 2007發行版中首次引入的。OOXML電子表格使用擴展名.xlsx和.xlsm（用于帶有宏的電子表格）。

使用EPPlus創建VBA項目時，它不包含已編譯的VBA代碼。EPPlus沒有創建編譯代碼的方法：創建編譯VBA代碼的算法是Microsoft專有的。

我們檢測到的第一個惡意文檔是在2020年6月22日創建的，從那時起，我們在2個月的時間里發現了200多個惡意文檔。在過去的幾周里，攻擊者增加了他們的活動，現在我們有時會看到10多個新的惡意文檔。

圖1-每天觀察到的獨特的maldocs。

在兩個月的時間內發現的maldocs具有許多與Microsoft Office創建的文檔的屬性完全不同的屬性。我們認為是這是因為它們是使用獨立于Microsoft Excel的工具創建的。盡管我們沒有攻擊者用來創建這些惡意文檔的確切工具的副本，但此工具創建的惡意文檔具有許多屬性，這些屬性使我們確信它們是使用上述EPPlus軟件創建的。

EPPlus的某些屬性包括但不限于：

  • 功能強大且用途廣泛的庫：它不僅可以創建包含VBA項目的電子表格，而且還可以對該項目進行密碼保護和/或數字簽名。它不依賴Microsoft Office。它也可以在Mono（跨平臺，開源.NET）上運行。

  • 用EPPlus創建的OOXML文件具有一些屬性，可將它們與用Excel創建的OOXML文件區分開。這里是一個概述：

ZIP日期：ZIP文件中包含的每個文件都有一個時間戳（ZIPFILE記錄中的DOSDATE和DOSTIME字段）。對于使用Microsoft Office創建（或編輯）的文檔，此時間戳始終為1980-01-01 00:00:00（DOSDATE為0x0021，DOSTIME為0x0000）。使用EPPlus創建的OOXML文件具有與文檔創建時間相對應的時間戳。通常，OOXML文件中的所有文件的時間戳都是相同的，但是由于執行延遲，時間戳之間可能相差2秒。2秒是DOSTIME格式的分辨率。

圖2 – DOSTIME差異（左：EPPlus創建的文件）

  • 額外的ZIP記錄：一個典型的ZIP文件由ZIP文件記錄（magic 50 4B 03 04）和（壓縮）文件內容組成。然后是ZIP目錄條目（magic 50 4B 01 02），后面是一個ZIP結束的目錄記錄（magic 50 4B 05 06）。Microsoft Office創建包含這3種ZIP記錄類型的OOXML文件。EPPlus創建包含4個ZIP記錄的OOXML文件：在每個ZIP文件記錄之后還包括一個ZIP數據描述記錄（magic504b0708）。

圖3 –額外的ZIP記錄（左：EPPlus創建的文件）

  • 缺少Office文檔元數據：使用Microsoft Office創建的OOXML文檔包含元數據（作者，標題等）。此元數據存儲在docProps文件夾中的XML文件中。默認情況下，使用EPPlus創建的文檔沒有元數據：ZIP容器內沒有docProps文件夾。

圖4 –缺少元數據（左：EPPlus創建的文件）。

  • 已清除VBA：具有通過Microsoft Office創建的VBA項目的OOXML文件包含OLE文件（vbaProject.bin），該文件的流包含已編譯的VBA代碼和已壓縮的VBA源代碼。使用EPPlus創建的文檔不包含已編譯的VBA代碼，而僅包含壓縮的VBA源代碼。這意味著： 模塊流僅包含壓縮的VBA代碼。

沒有SRP流（SRP流包含特定于實現和版本的編譯代碼，其名稱以__SRP_開頭）。

_VBA_PROJECT流不包含已編譯的VBA代碼。實際上，_VBA_PROJECT流的內容被硬編碼在EPPlus源代碼中：始終為CC 61 FF FF 00 00 00。

圖5 –硬編碼的流內容（左：EPPlus創建的文件）。

除上述內容外，我們還觀察到了VBA源代碼的某些屬性，這些屬性提示使用基于EPPlus之類的庫的創建工具。

actor使用的VBA源代碼有兩個變體（一些變體使用PowerShell來下載有效負載，其他變體使用純VBA代碼）。但是所有這些變體都包含一個調用程序，該調用程序具有一個參數，即帶有URL的字符串（BASE64或十六進制編碼）。像這樣（十六進制示例）：Loader"68 74 74 70…"

請注意，函數名稱和參數之間沒有空格字符：Loader與“ 68 74 74 70…”之間沒有空格。

這表明VBA代碼不是通過Office中的VBA EDI輸入的：當輸入這樣的語句時，如果沒有空格字符，VBA EDI會自動為您添加一個空格字符（即使您復制/粘貼該代碼也是如此）。

缺少此空格字符說明該代碼不是通過VBA EDI輸入的，而是可能通過EPPlus之類的庫輸入的。

為了說明這些屬性上的差異，我們使用EPPlus庫使用內部工具之一（ExcelVBA）顯示示例。我們使用工具ExcelVBA在文本文件vba.txt中用vba代碼創建vba.xlsm文件，并顯示其某些屬性：

圖6 – NVISO使用EPPlus庫創建的XLSM文件。

圖7 –運行oledump.py顯示該文檔是使用EPPlus庫創建的。

一些惡意文檔包含使用EPPlus Wiki上的示例代碼清楚地由EPPlus創建的對象。我們通過以下示例（此廣告系列中的第一個文檔）進行說明：

文件名：掃描順序列表.xlsm
MD5：8857fae198acd87f7581c7ef7227c34d
SHA256:8a863b5f154e1ddba695453fdd0f5b83d9d555bae6cf377963c9009c9fa6c9be
文件大小：5.77 KB（5911字節）
最早內容修改： 2020-0646

本文檔包含一個具有以下名稱的drawing1.xml對象（圓角矩形）：name =" VBASampleRect"。

圖8 – maldoc的zipdump。

圖9 –選擇drawing1.xml對象顯示名稱。

這是使用EPPlus Wiki [2]上的示例代碼創建的：

圖10 – EPPlus示例代碼，清楚地顯示了相似之處。

值得注意的是，我們觀察到的所有惡意文檔的VBA項目均受密碼保護。有趣的是，VBA代碼本身未經編碼/加密，而是以明文形式存儲（盡管經過壓縮）[3]。當打開具有受密碼保護的VBA項目的文檔時，VBA宏將在沒有密碼的情況下執行：用戶不需要提供密碼。僅在VBA IDE（集成開發環境）中查看VBA項目時才需要密碼：

圖11 –查看VBA項目的密碼提示。

我們無法恢復這些密碼。我們將開膛手約翰（John the Ripper）與rockyou.txt密碼列表[4]結合使用，對Hashcat使用了小型ASCII蠻力攻擊。

盡管每個惡意文檔都有其自己的VBA代碼，但每個惡意文檔都是唯一的，迄今為止已分析了200多個樣本，但我們可以將所有這些VBA代碼概括和抽象為少數幾個模板。VBA代碼將使用PowerShell或ActiveX對象下載有效負載。不同的字符串使用十六進制，BASE64或XOR編碼進行編碼，或這些編碼的組合。本博客文章的末尾提供了一個Yara規則來檢測這些惡意文檔，以進行識別和檢測。

有效負載分析

如上一部分所述，通過惡意VBA代碼，從各個網站下載了第二階段的有效負載。由其各自的惡意文檔創建的每個第二階段可執行文件都充當最終有效負載的放置程序。為了阻止諸如防病毒解決方案之類的檢測機制，利用了多種混淆技術，但是這些技術不夠先進，無法掩蓋惡意意圖。攻擊者所使用的基礎設施似乎主要包括受感染的網站。

流行的防病毒解決方案，例如VirusTotal上列出的解決方案，如圖12所示，通常將第二階段的可執行文件標識為“ AgentTesla”。盡管利用VirusTotal進行惡意軟件識別不是一種理想的方法，但它確實顯示了簡單的混淆會導致錯誤的分類。在整個分析過程中，我們將解釋這些流行的檢測中只有很少的結果是準確的。

圖12：VirusTotal的“ AgentTesla”錯誤識別。

我們觀察到的不同混淆技術概述了操作Epic Manchego的所有第二階段可執行文件所共有的模式。從圖13中可以看到，第二階段將動態加載解密DLL。然后，此DLL組件繼續提取其他設置和第三階段有效負載，然后再將執行轉移到最終的有效負載（通常是信息竊取者）。

圖13：Epic Manchego操作的最后階段交付機制。

盡管以上混淆模式對于所有樣本都是通用的，但我們已經觀察到其復雜性的演變以及可能采用更多機會主義技術的廣泛變化。

該行動第二階段樣本的一個共同因素是使用隱寫術掩蓋其惡意意圖。圖14標識了在最近的變體中使用的部分配置，其中包括最終有效負載在內的設置字典被編碼為數百個圖像，這是作為第二階段嵌入式資源的一部分。

圖14：BMP圖像中編碼的部分字典。

圖像本身是以下第二階段樣本的一部分，該樣本具有以下屬性：

文件名：crefgyu.exe
MD5：7D71F885128A27C00C4D72BF488CD7CC
SHA256:C40FA887BE0159016F3AFD43A3BDEC6D11078E19974B60028B93DEF1C2F95726
文件大小：761 KB（779.776字節）
編譯時間： 2020-03-09 16:39

值得注意的是，混淆過程不是由攻擊者自己建立的。對第二階段隱寫術解碼程序的仔細審查揭示了大多數樣本是如何錯誤地將最終有效載荷包含兩次。在加載程序配置的以下表示形式（圖15）中，我們可以看到其有效負載確實是重復的。第二級和第三級有效載荷的復雜性還傾向于表明操作涉及不同的參與者，因為初始文檔反映了經驗不足的參與者。

在分析的多個基于字典的變體中，我們還注意到，無論最終的有效負載如何，相似的鍵都用作設置的一部分。所有字典都包含最終的有效載荷，即“EpkVBztLXeSpKwe”，而某些字典（如圖15所示）也包含與“PXcli.0.XdHg”相同的值。這暗示了可能的有效載荷傳遞構建器，可以由多個參與者使用。

圖15：第二階段解碼字典。

在30個不同的基于字典的第二階段的手動分析數據集中，觀察到19個唯一的最終有效載荷。從這些中，“Azorult”竊賊占該變種交付量的50％（圖16）。其他有效負載包括“ AgentTesla”，“Formbook”，“Matiex”和“njRat”，這些都已經有據可查。“Azurult”和“njRAT”都有明顯的重用率。

圖16：基于字典的有效載荷分類和帶有修剪散列的樣本的（重新）使用。

我們對滴管和相應有效負載的分析揭示了混淆例程中的常見模式。盡管機會主義混淆方法可能會發展，但交付的有效負載仍然是相當有限的一組惡意軟件系列的一部分。

指定目標

我們從VirusTotal檢索到的少量惡意文檔與網絡釣魚電子郵件本身一起上傳。對這些電子郵件的分析可以為該參與者的潛在目標提供一些啟示。由于檢索到的源電子郵件數量有限，因此無法根據受害者確定明確的模式。在我們能夠檢索到的6封電子郵件中，收件人分別是醫療設備部門，鋁業，設施管理部門和定制壓機供應商。

在調查發件人域時，似乎大多數電子郵件都是從合法公司發送的。使用“已被我擁有” [5]服務確認是否已知有任何電子郵件地址遭到破壞，但沒有結果。這使我們想知道攻擊者在早期感染期間是否能夠利用這些帳戶，或者是否由另一方提供。無論誰破壞了帳戶，攻擊者似乎主要使用合法的公司電子郵件帳戶來發起網絡釣魚活動。

從發送者和接收者這兩個角度來看，似乎沒有一種可以推斷出潛在新目標的模式。似乎沒有針對的特定部門，發送域也沒有關聯。

電子郵件的正文（內容）和主題均與更經典的網絡釣魚方案有關，例如，發起業務的請求，附件提供了“詳細信息”。觀察到的主題概述可以在下面看到，請注意，某些主題已被各自的郵件網關更改：

  • 回復：需要報價/
  • 報價量和重量為首選
  • * SPAM *** FW：Offer_10044885_ [companyname] _2_09_2020.xlsx *
  • [懷疑的垃圾郵件]替代要求*
  • 采購訂單明細
  • 報價請求

圖17 –網絡釣魚電子郵件示例。

這種誘使用戶打開附件的方法并不是什么新鮮事物，并且沒有提供很多其他信息來精確定位針對任何特定組織或行業的廣告系列。

但是，通過VirusTotal利用maldocs的公開提交，我們聚集了200多個文檔，這使我們能夠按提交計數對27個國家/地區進行排名，而無需區分可能通過VPN執行的上傳。如圖18所示，美國，捷克共和國，法國，德國以及中國等地區占了大多數目標區域。

圖18 – VT提交的地理分布。

在分析目標區域的初始文檔時，我們主要識別基于英語，西班牙語，中文和土耳其語的圖像。

圖19 – Maldoc內容分別為中文，土耳其語，西班牙語和英語。

但是，某些圖像包含一個有趣的細節：某些文檔屬性使用西里爾字母，而與圖像的主要語言無關。

盡管在多幅圖像中觀察到了西里爾字母設置，但是在撰寫此文章時發現了一個新的惡意文檔，這引起了我們的興趣，因為它似乎是第一個明確冒充醫療保健部門成員的人（“俄亥俄·哈丁紀念醫院”），如圖20所示。還要注意上述設置：СТРАНИЦА1ИЗ1 ; 表示第1頁，共1頁。

圖20 –帶有西里爾字母設置的Maldoc內容模擬了“ Ohiohealth Hardin Memorial Hospital”。

此Microsoft Excel文檔具有以下詳細信息：

文件名： ? ? ? ? ? _2608.xlsm（韓文：新訂單_2608.xlsm）
MD5：551b5dd7aff4ee07f98d11aac910e174
SHA256:45cab564386a568a4569d66f6781c6d0b06a9561ae4ac362f0e76a8abfede7bb
文件大小：5.77 KB（5911個字節）
最早修改內容時間： 2020年6月22日14時01分46秒

盡管可以從網上簡單地找到來自該醫院的模板，然后由攻擊者使用，但是這種令人驚訝的操作方式變化似乎與自跟蹤開始以來觀察到的行為者的不斷發展相吻合。

評價

根據分析，NVISO評估以下內容：

  • 所觀察到的威脅行動者已經找到了一種創建惡意Office文檔的新方法，該方法可以至少略微減少檢測機制。

  • 攻擊者可能正在嘗試和發展其方法，以創建惡意Office文檔，從而可能使工作流程自動化。

  • 盡管目前的定位似乎很有限，但這些首次投放可能是為了測試而不是全面的廣告系列。 提交給VirusTotal的最新檢測結果表明，該攻擊者可能正在加強其行動。

  • 盡管創建惡意文檔的方法是唯一的，但有效負載傳送和實際有效負載的方法并不是唯一的方法，應該由現代技術加以阻止或檢測。

  • 有趣的是Xavier Mertens最近在SANS日記中通過VT追蹤惡意軟件活動[6]發表的文章。似乎另一位安全研究人員也一直在跟蹤這些文檔，但是，他們已經從maldocs中提取了VBA代碼并上傳了該部分。這些模板與PowerShell的下一階段下載方式有關。

總之，NVISO評估了這種特定的惡意Excel文檔創建技術，盡管有效載荷分析通常被認為更有趣，但它可能會被更多地在野外觀察到，盡管它被電子郵件網關或分析人員遺漏了。但是，阻止和檢測這些類型的新穎性（例如本博客中描述的惡意軟件創建）使組織能夠在出現激增或類似活動時更快地進行檢測和響應。建議部分提供了裁定和指標作為檢測手段。

推薦建議

  • 過濾電子郵件附件和從組織外部發送的電子郵件。
  • 實施強大的端點檢測和響應防御。
  • 創建網絡釣魚意識培訓并執行網絡釣魚練習。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1328/