漏洞鏈攻擊是從以下誘餌開始 :
分析時，研究人員觀察到一個有趣的 Microsoft Word 文檔 ( .docx 文件 ) 于 2023 年 7 月 3 日首次提交給 VirusTotal，名爲 Overview_of_UWCs_UkraineInNATO_campaign.docx。
該活動被社區歸因于 Storm-0978 ( 也被稱爲 RomCom 組織，因爲他們使用了 RomCom 後門 ) 。
惡意 Word 文檔誘餌
此文檔托管在以下 URL：
hxxps://www.ukrainianworldcongress [ . ] info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx
上面的鏈接表明該文檔很可能是通過電子郵件傳播的，電子郵件文本包含指向 .docx 文件的鏈接。文件的創建日期和域名 ukrainianworldcongress 的注冊日期都是 2023 年 6 月 26 日。這個時間點表明，這是一個基于電子郵件的活動，其中包含 .docx 文件的鏈接。
當該文件最初提交給 VirusTotal 時，62 個殺毒軟件中有 27 個将其識别爲惡意文件。
CVE-2023-36584 利用的技術分析
微軟 Office 文檔一直是攻擊者傳播惡意軟件的常用攻擊手段。爲了應對這一威脅，微軟實施了 mow 安全，限制 Office 文檔中的各種功能來自不受信任的位置。
Windows 将這些文件識别爲高風險文件。帶有 mow 标記的文件會生成一個 SmartScreen 提示，表明它有潛在的危險。當 Word 文檔未标記爲 mow 時，就會被攻擊者利用，導緻禁用 Protected View。
爲了理解 CVE-2023-36884 是如何被特定的誘餌利用的，我們應該首先了解 Microsoft Word 對 Open XML 文件格式的實現過程，在本例中是針對 MS-DOCX ( .docx ) 文件。
MS-DOCX 文件是一個壓縮的 ZIP 歸檔文件，其中包含用于顯示 Word 文檔的多個規範文件。其中之一是位于 word/document.xml 的 XML 文件。這是 MS-DOCX 文件的核心 XML 組件，它包含文檔的文本和格式。
在 Microsoft Word 中查看 MS-DOCX 文件時，文檔的大部分内容都是通過 Word /document.xml 導入的。
在 .docx 誘餌中，word/document.xml 使用名爲 altChunk 的導入外部内容元素導入内容，如下圖所示。
這個 altChunk 元素可以導入使用另一種格式的内容，比如富文本格式 ( RTF ) ，來自 .docx 文件的 word/document.xml 有一個 altChunk 元素，它使用标識符 AltChunkId5 指示與外部内容的關系。這個标識符在 word/_rels/document.xml.rels 的關系文件中被定義。
上圖中顯示的 document.xml.rels 代碼片段将導入的目标标識爲位于 word/afchunk.rtf 的文件。
RTF 文件 afchunk.rtf 包含兩個惡意的 OLE ( Object Linking and Embedding ) 對象。第一個 OLE 對象使用帶有 objautlink RTF 控制字的 OLE 自動鏈接類型，在 objautlink 控制字之後，一個 objupdate 控制字強制對象在顯示之前進行更新，如下圖所示。
對象類被定義爲 Word.Document.8，其數據在其标頭中包含 LinkedObject 結構，後跟表示十六進制字符的 ASCII 文本。
我們使用 Didier Steven 的 rtfdump.py 工具進一步檢查 afchunk.rtf。下圖顯示了前面所示的 objautlink 片段的十六進制 ( hex ) 輸出，這個輸出更清楚地顯示了 LinkedObject 結構。
第一個惡意 OLE 對象的 rtfdump.py 輸出
此十六進制轉儲顯示 \104.234.239 [ . ] 26share1MSHTML_C7file001.url，一個使用服務器消息塊（SMB）協議的惡意 url。
使用 rtfdump.py 查看 afchunk.rtf，我們發現另一個使用 xmlfile 類的惡意 OLE 對象，其标頭包含 EmbeddedObject 結構。嵌入的對象是一個複合文檔，其中包含一個 URLMoniker，它從 URL 加載 XML 文件 hxxp://74.50.94 [ . ] 156/MSHTML_C7/start.xml，如下圖中的藍色标注。
第二個惡意 OLE 對象的 rtfdump.py 輸出
漏洞利用鏈的第一階段
對該漏洞利用鏈的初步研究得出了一個流程圖，該流程圖由@zcracga創建，并于 2023 年 7 月 12 日由@r00tbsd共享。該流程圖有助于可視化通過漏洞利用鏈工作的不同階段。
漏洞利用鏈流程圖
我們最初關注的域是 afchunk.rtf 中惡意 OLE 對象的兩個 URL。如前所述，這些 OLE 對象從以下 URL 請求内容：
\104.234.239 [ . ] 26share1MSHTML_C7file001.url hxxp://74.50.94 [ . ] 156/MSHTML_C7/start.xml
當 Windows 客戶端連接到 SMB 服務器時，該客戶端會發送 Windows NT LAN Manager（NTLM）憑據進行身份驗證。因此，當受害者主機訪問位于 \104.234.239 [ . ] 26share1MSHTML_C7file001.URL 的 URL 時，它會将受害者的 NTLM 憑據及其主機名和用戶名洩漏給攻擊者控制的 SMB 服務器。收集到的信息稍後将用于攻擊鏈。
下圖顯示了嵌入 file001.url 中的 HTML 代碼。
file001.url 片段
通過檢查 file001.url，UName 變量包含受害者的用戶名。這是攻擊者控制的 SMB 服務器從受害者洩露的 NTLM 憑據中收集的用戶名。如果上圖顯示的變量 d 不爲空，則漏洞利用鏈将用戶名與攻擊者傳遞的值連接起來，該值用于創建名爲 2222.CHM 的 CHM 文件的路徑，該文件包含在名爲 file001.zip 的文件中。
在攻擊鏈的這一階段，2222.chm 不存在，或者它可能是攻擊者使用的其他攻擊的一部分。file001.url 的進一步行爲将在後面解釋，因爲它與 2222.chm 密切相關。
afchunk.rtf 中的第二個惡意 OLE 對象來自 hxxp://74.50.94 [ . ] 156/MSHTML_C7/start.xml。此 start.xml 文件包含一個 iframe，用于從同一服務器和目錄路徑加載另一個名爲 RFile.asp 的文件。
start.xml 中引用 RFile.asp 的 iframe 片段
RFile.asp 負責在服務器上加載另一個文件，該文件的攻擊特定路徑定義爲：
file [ : ] //104.234.239 [ . ] 26/share1/MSHTML_C7/1/__file001.htm?d=__
該路徑由受害者的
RFile.asp 中的代碼段
濫用 Windows 搜索處理程序
file001.htm 的核心行爲是執行 JavaScript，如下圖中的代碼片段所示。
file001.htm 片段
file001.htm 中的 JavaScript 使用 iframes 來加載幾個文件。它首先加載一個保存的搜索文件，該文件的文件名由受害者的 IP 地址和以字符串 file001.search-ms 結尾的五位标識符組成。我們将把這個文件稱爲其文件名 file001.search-ms 的最後一部分。
接下來是三個 HTTP 請求，在它們的 url 中使用字符串 .zip_k*。除了執行計時或無操作（no-op ）操作外，此行爲沒有明顯的價值。
最後，MSHTML 重新加載 file001。Search-ms 然後加載 redir_obj.htm。
這些請求的順序很明顯，因爲預期的目的并不明顯。根據相關網絡流量示例中的時間戳，我們推測通過服務器端操作實現了這種事件順序的繞過，其中對 .zip_k* 文件的請求被用作延遲機制。下圖顯示了在 Wireshark 中過濾流量的數據包捕獲 ( pcap ) ，突出顯示了一個 HTTP GET 請求與其 HTTP 響應之間的兩秒延遲。
使用 zip_k.asp 延遲響應請求
在檢查文件 redir_obj.htm 時，我們發現了如下圖所示的代碼片段。這段代碼從本地路徑加載一個文件，該文件使用在初始 SMB 連接期間捕獲的洩漏的主機名和用戶名分别作爲 CompName 和 UName 變量，其用于打開文件 file001.zip 中名爲 1111.htm 的 HTML 文件。
來自 redir_obj.htm 的片段
重新創建 Windows 搜索處理程序文件
我們使用 Windows 文件資源管理器創建一個空白保存的搜索文件，文件擴展名爲 .search-ms，以控制包含 2222 的 ZIP 文件的位置。提取 CHM 并說明這個漏洞利用鏈是如何工作的。我們在 File Explorer 中啓動搜索并保存結果，這創建了一個 .search-ms 文件。這個保存的搜索文件是一個空白模闆，可以重現這個漏洞利用鏈中使用的搜索處理程序文件行爲。
Windows 系統文件 Windows. storage .search .dll 處理 .search-ms 文件。爲了成功地将 ZIP 文件解壓縮到 redir_obj.htm 文件中指定的目錄中 ( 由圖 11 中所示的 JavaScript iframe 加載 ) ，需要進行一些更改。
首先，include 元素必須包含一個本地路徑作爲它的網絡路徑，并使用 FILE_ATTRIBUTE_NORMAL，實現爲變量 attributes="128"。
基本 .search ms 文件，已更改爲觸發 ZIP 提取
接下來，autoListFlags 屬性必須打開第二個最低有效位，如下圖所示。這将産生一個完整的搜索，其中還包括任何 ZIP 存檔的内容。
在 Windows.Storage.Search.dll 中進行 .search-ms 處理的示例
此時處理 .search ms 文件将在目标計算機上按以下路徑創建一個目錄：
C:Users [ USERNAME ] AppDataLocalTemp [ Temp1_zip_filename ]
ZIP 文件的内容随後被提取到該目錄中。
search-ms 根據早期 SMB 洩露的主機信息處理 ZIP 文件的放置和内容提取。
結果證實了從 ZIP 文件中提取的兩個文件：1111.htm 和 2222.chm。
在利用 Office 中以前的 RCE 漏洞 CVE-2021-40444 時，也觀察到了類似的行爲。在該攻擊中，攻擊者會利用 Microsoft Compressed Archive（CAB）路徑遍曆提取漏洞來實現類似的目标：将 HTML 文件提取到計算機上的可預測路徑。
在讨論 1111.htm 和 2222.chm 文件之前，我們首先應該了解 Windows 安全區域。
Windows 安全區域和其他障礙
Windows 安全區域也被稱爲 Internet Explorer 安全區域或 URL 安全區域，Windows 安全區域是微軟用來确定來自不同來源文件的權限機制。通常，從 internet 檢索的文件被标識爲來自 "internet Zone"，并标記爲受限權限的 mow。
此數據存儲在名爲 Zone.Identifier 的文件的備用數據流（ADS）中，用于指示文件的安全區域。來自 "Internet Zone" 的文件的 ZoneId 值爲 3 ( 安全區域 3 ) 。
爲了使攻擊鏈的其餘部分成功，1111.htm 和 2222.chm 文件的 ZoneId 值都必須在其 Zone.Identifier ADS（安全區域 1）中标識爲 1。然而，這是一個障礙，因爲從遠程路徑下載并由 .search-ms 提取的 ZIP 内容的 ZoneId 值爲 3，并且該内容會自動标記爲 MotW。
爲了成功利用，還必須克服另外兩個障礙 :
障礙 1：當 Windows Search 使用 .Search ms 完成時，它會删除 [ Temp1_zip_filename ] 目錄。這将生成一個競争條件，以加載臨時目錄中的文件。
障礙 2：默認情況下，Windows 不會搜索 CHM 文件的内容。2222.chm 文件是此漏洞利用鏈的一部分，但它不會使用 Windows 搜索的默認設置從 ZIP 存檔中提取。
使用 CVE-2023-36584 繞過 MotW
在使用 CVE-2023-36884 對這個漏洞鏈進行分析期間，研究人員發現了一個漏洞利用途徑，微軟将其命名爲 CVE-2023-36584。
Windows Search 在搜索期間遍曆 ZIP 存檔中的所有文件。Windows Search 檢查每個文件的文件擴展名，以确定其内容是否也需要搜索。如果是，Windows Search 将該文件寫入臨時目錄，并将 mow 添加到其中。
這個實現生成了一個固有的競争條件。在将解壓縮文件寫入磁盤和用 mow 标記它之間有很短的時間窗口。如果我們在這個窗口中延遲 Windows 搜索，我們可以解決競争條件并最終繞過 mow。
先前利用 CVE-2022-41049 的技術通過向 ZIP 存檔中的文件添加隻讀屬性來繞過 motw，這避免了對區域的修改。這避免了對 Zone.Identifier ADS 的修改，并阻止了提取的文件接收 MotW。這項技術啓發了我們，并使我們發現繞過 MotW。
技術 1：服務器端 ZIP 交換
服務器端操作使我們能夠解決這些問題，我們發現了一個從檢查時間到使用時間 ( TOCTOU ) 的漏洞，當從遠程服務器下載 ZIP 歸檔文件時，可以利用該漏洞。
Windows 使用系統文件 zipfldr.dll 來提取 ZIP 存檔的内容。這個 Windows DLL 文件讀取 ZIP 文件的标頭并将數據緩存在内存中，同時 ZIP 存檔的内容被提取并保存到磁盤。Zipfldr.dll 公開了一個 API，該 API 可用于通過在 ZIP 存檔中指定文件索引來提取文件。
讀取文件标頭後，在使用 zipfldr.dll 對其進行解壓縮之前，我們可以将遠程服務器上的 ZIP 文件替換爲包含不同名稱文件的 ZIP 文件，從而導緻 MotW 無法寫入。
這種技術之所以有效，是因爲 urlmon.dll 使用文件路徑來寫入最初從緩存在内存中的 ZIP 标頭讀取的 MotW，以便繞過将 MotW 寫入文件。
該技術解決了前面提到的關于利用 CVE-2023-36884 的兩個障礙。成功解壓縮了 .chm 文件，否則将無法解壓縮，并且這些文件不會立即删除。
下圖顯示了一個 Process Monitor（procmon）視圖，說明創建名爲 2222.txt 的替代文件的嘗試失敗。此條件允許以前保存的 2222.chm 避免 MotW。
使用 TOCTOU 漏洞繞過 mow
我們無法确認這就是攻擊者在原始漏洞利用鏈中使用的确切技術。但是，VirusTotal 對初始 .docx 誘惑的沙箱分析的行爲日志顯示，創建了一個名爲 1111.txt 的文件，表明可能有一個鏡像 1111.htm 的替代文件名。
技術 2：服務器端延遲
除了第一種技術外，我們還發現了另外兩種可以顯著延遲 mow 編寫的技術。此場景防止寫入 MotW 屬性，并允許從安全區域 1 中的另一個線程執行文件。
從 ZIP 存檔中提取文件後，在将 MotW 添加到 Zone.Identifier ADS 之前，我們可以從攻擊者控制的 SMB 服務器引入時間延遲。這是可能的，因爲 SMB2 協議的關閉操作包括關閉請求和結束基于 SMB 的文件傳輸的關閉響應。
當客戶端接收到來自傳輸文件的所有數據時，它将 SMB 關閉請求發送回服務器，并等待 SMB 關閉響應。文件已被傳輸，但傳輸操作尚未完成，直到客戶端收到關閉響應。這是一個同步操作，可以延遲相當長的一段時間。
下圖中的 procmon 列表顯示了在 111.222.11 [ . ] 20 的 SMB 服務器在下一次操作之前傳輸了一個名爲 served.zip 的文件後的 30 秒延遲。這表示關閉請求和關閉響應之間有 30 秒的延遲。
在這個 30 秒的窗口中，1111.htm 文件是一個沒有 MotW 的安全區域 1 文件。在 30 秒後最終發送了關閉響應後，該過程繼續，并将 MotW 寫入 1111.htm。
mow 繞過
技術 3：服務器端延遲
在從 ZIP 歸檔文件傳輸大文件時，Windows 從遠程共享中讀取文件的一部分，将數據附加到磁盤上的本地文件中，然後從遠程共享中讀取其他部分，直到文件完全寫入磁盤。如果我們在文件末尾附加随機數據，就可以在 Windows 将 mow 添加到文件之前延遲 SMB 服務器對文件的寫入。該文件在寫入過程中是可用的，因爲它是用讀寫 dwShareMode 打開的。
我們通過在流程中引入 10 秒延遲來測試這個預設，如下圖所示。
使用延遲閱讀響應的 mow
微軟安全更新地址 CVE-2023-36884
開發此漏洞利用鏈的攻擊者知道 SMB 文件傳輸期間臨時保存的本地文件的路徑是可預測的。但在微軟 2023 年 8 月的安全更新之後，臨時保存的本地文件名中添加了一個通用唯一标識符（UUID），可以使路徑随機。
微軟 2023 年 8 月安全更新後臨時保存的本地文件路徑
如上圖所示，在我們的測試運行期間，臨時保存的文件在臨時保存的本地文件的目錄路徑中包含 UUID 字符串 90be3ab -6ec5-4f3f-bdd8-1e22ee6c326c。
在 ZIP 存檔的 SMB 文件傳輸過程中，zipfldr.dll 通過調用 CTempFileNameArray::GetTempLocation 函數創建一個臨時文件夾，該函數調用 CTempFileNameArray::_TryCreatingInPath。
使用 BinDiff 查找 zipfldr.dll 補丁版本中的更改，我們在 CTempFileNameArray::_TryCreatingInPath 函數中發現了一個值得注意的新代碼塊，如下圖所示。
調用 UuidCreate
Microsoft 添加了對 UuidCreate 的調用，如果路徑沒有使用新的 UUID 構造，則從 ZIP 存檔中提取内容将失敗。
zipfldr.dll 補丁版本中另一個有趣的更新是 ExtractZipToFile 函數。在提取文件後添加新代碼，它将在文件寫入後立即追加 mow。如果 SetFileAttributes 失敗，文件将被删除，如下圖所示。
調用 DeleteFileW
盡管微軟 2023 年 8 月的安全更新緩解了這一漏洞鏈，但該鏈的其他步驟仍可以被利用。
ActiveX 攻擊面
在安全區域 1 中運行文件會導緻對 ActiveX 控件更寬松的策略，并提供更大的 ActiveX 攻擊面。這允許執行可能被利用來執行惡意代碼的舊 ActiveX 代碼。
增加的 ActiveX 攻擊面使我們能夠觸發攻擊鏈中的下一步。下圖中的 1111.htm 中的代碼片段将導緻下一步。
在 WebBrowser 控件中重新加載 1111.htm
這段來自 1111.htm 的代碼創建了一個隐藏的彈出窗口，并在隐藏的彈出窗口中運行 ActiveX WebBrowser 控件。WebBrowser 控件是一個包裝器，它允許在基于 windows 的應用程序中使用 web 浏覽功能。開發人員經常使用此 ActiveX 控件在應用程序中嵌入 HTML 查看器。
提升命令執行的安全區域
雖然安全區域 1 允許我們避免 mow 并增加 ActiveX 攻擊面，但可以将文件提升到安全區域 0 以執行命令。标記爲安全區域 0 的文件表示 " 本地計算機 " 區域，這是最受信任的區域，并提供最大允許權限。
在這個階段，WebBrowser 控件将頁面從區域 1 中的網絡路徑重定向到同一頁面的本地路徑。現在已經從本地路徑加載了 1111.htm 文件，它将在安全區域 0 中執行。
接下來，1111.htm 通過調用 ms-its 加載 2222.chm，如下圖所示。
加載 2222.chm
Windows 使用這個 ms-its 處理程序來顯示 microsoftcompiled HTML Help ( CHM ) 文件。該函數在 its .dll 模塊中實現，該模塊加載提取的 2222。chm 文件。
下圖顯示了在 HTML Help Workshop 中查看文件時 2222.chm 的内容。
2222.chm 的内容
CHM 文件包含一個名爲 file1.htm 的文件，該文件重定向到 file1.mht（由 inetcomm.dll 處理，它是 Microsoft 互聯網消息 API 的一部分）。然後 file1.mht 使用 showHelp 方法加載 fileH.htm。然後 fileH.htm 重定向到 fileH.mht，最後 fileH.mht 執行如下圖所示的腳本。
fileH.mht 代碼段調用 open 函數
上圖中來自 fileH.mht 的代碼片段使用 window.open 方法調用 ShellExecuteExW API 以在以下位置打開文件：
file [ : ] //104.234.239 [ . ] 26/share1/MSHTML_C7/ex001.url
繞過 SmartScreen
上圖中名爲 ex001.URL 的 Internet 快捷方式（URL）文件指向文件 [ : ] //104.234.239 [ . ] 26/share1/MSHTML_C7/ex001.zip/file001.vbs。
下載的 file001.vbs 文件包含旨在繞過 SmartScreen 保護的惡意 Visual Basic 腳本（vbs）。
當 URL 文件指向遠程 UNC 路徑時，URL 文件将下載并運行從該路徑返回的内容。執行内容調用 ShellExecuteW API，該 API 觸發 CheckSmartScreen 函數，提示用戶進行确認，如下圖所示。
SmartScreen 警告
但是，我們的文件位于 ZIP 存檔中，因此它觸發的行爲流略有不同。文件 file001.vbs 在利用鏈中被下載，并使用 MotW 提取到用戶的本地臨時目錄中，但它會立即執行，不會出現任何彈出警告。下圖中的 procmon 列表對此進行了說明。
立即啓動 Wscript.exe，成功繞過 SmartScreen
如上圖所示，從遠程目錄中檢索文件 ex001.zip，然後從 zip 歸檔中提取文件 001.vbs。稍後在進程事件列表中，我們爲 wscript.exe 找到一個進程創建條目，以運行 VBS 文件，如藍色突出顯示的那樣。
