背景

2018年8月15日，網絡安全公司趨勢科技公開了其在今年7月捕獲到的一例在野0day漏洞攻擊，該攻擊利用了Windows VBScript Engine的代碼執行漏洞，經過分析對比發現該0day漏洞和2018年4月360公司首次發現影響IE瀏覽器并通過Office文檔進行攻擊的“雙殺”漏洞（詳見參考[1]）使用了多個相同的攻擊技術，極有可能是同一團伙所為。
360威脅情報中心第一時間對該0day漏洞進行了分析確認，并通過大數據關聯分析確認本次的0day在野攻擊與DarkHotel APT組織存在關聯。

來源
2018年8月15日，趨勢科技公開了其在今年7月11日捕獲到的一例在野0day漏洞攻擊技術分析，該漏洞已于公開的前一天被微軟修復，漏洞編號為：CVE-2018-8373。

三個“雙殺”0day漏洞時間線
CVE-2018-8373其實是今年以來被發現的影響Windows VBScript Engine的第三個漏洞，其中前兩個均為360公司的安全研究人員首次發現，這三個漏洞均影響IE瀏覽器，且可以通過微軟Office文檔進行攻擊。三個“雙殺”0day漏洞發現的時間線如下：
CVE
發現時間
修復時間
描述
CVE-2018-8174
2018.4.18
2018.5.8
影響Office和IE的雙殺漏洞，在野
CVE-2018-8242
2018.7.10
360安全研究人員發現并上報微軟（參考[2]）
CVE-2018-8373
2018.7.11
2018.8.14
影響Office和IE的雙殺漏洞，在野

溯源與關聯
獲得打碼后的IOC
360威脅情報中心通過大數據分析關聯首先得到了趨勢科技打碼后的IOC地址：
http://windows-updater.net/realmuto/wood.phpwho=1
關聯同源0day攻擊樣本
并發現一個攻擊時間和趨勢科技發現在野“雙殺”0day攻擊在同一天的疑似使用該0day攻擊的office文檔樣本，該Offce文檔樣本中內嵌的域名和趨勢科技給出的域名格式一致（http://windows-updater.net/stack/ov.phpw= 1\x00who =1）

確認與DarkHotel關聯
得到0day漏洞攻擊所使用的域名后我們立即發現，該域名正是360威脅情報中心在今年5月發布的關于DarkHotel APT團伙最新的攻擊活動中使用過的域名（詳見參考[4]）:


在360威脅情報中心威脅平臺中輸入該域名也會立即關聯到DarkHotel：

CVE-2018-8373漏洞分析
如下所示為趨勢給出的對應POC觸發代碼：

如下為該漏洞和今年5月360捕獲的CVE-2018-8174的POC對比，CVE-2018-8174主要的漏洞原因在于Class_Terminater中可以對釋放的內存對象繼續賦值，從而導致釋放后重用，而這次的CVE-2018-8373則是類的Propert Get操作中可以修改對應的類成員array的長度，從而導致之后的對象重用：

如下為對應的的POC代碼，POC代碼很簡單，VulClass類中定義了array成員變量，
方法Class_Initialize及Public Default Property Get P。
其中Class_Initialize是VB中一個已經棄用的方法，用于在類創建的時候實現對應的操作，重載后可以在類創建時完成相應的初始化工作，之后被new代替。
Default Property為一個類屬性，被Public Default Property Get P重載后，對該類的訪問將觸發相應的操作，在POC中即執行ReDim Preserve array(1)。
ReDim用于對指定的內存重新分配，其最終在VB引擎中通過SafeArrayRedim函數實現，熟悉VB漏洞的話，可以知道該函數就是之前CVE-2015-6332漏洞的根源：

POC中首先執行該行代碼，new的時候對應執行以下函數VBScriptClass::InitializeClass，由于VulClass類中重載了Class_Initialize方法，因此通過vbscript!CScriptEntryPoint::Call派發進入到對應的編碼者實現的Class_Initialize方法中：
Set cls = New VulClass

Class_Initialize方法中修改對應的array長度：
Private Sub Class_Initialize
ReDim array(2)
End Sub
可以看到此時生成的Array對象如下所示，其成員變量數為3，對應的pvData為0x0514dfd0：

之后運行以下代碼，VB引擎解析以下代碼的順序是從左自右掃描的，因此首先會進行cls.array(2)的操作：
cls.array(2) = cls
此時會調用函數vbscript!AccessArray判斷對應array（2）是否可訪問，如下所示此時獲取對應array的內存對象：

經過一番判斷之后，如下所示esi指向對應的array對象，依次獲取array中每個成員的大小cbElements，此處為0x10，需要訪問賦值的array index，此處為2，pvData，以此計算出array（2）對象的地址0514dfd0（pvData）+2（element）*10（cbElements）=0514ff0，0514ff0會被直接拷貝到求值棧上：

如下所示拷貝到求值棧上的array(2)地址：

通過內存訪問斷點可以跟蹤對該地址的引用：

之后執行等號右側部分的操作，由于該VulClass類定義了Public Default Property Get P，因此會在賦值前執行其中對應的代碼：
cls.array(2) = cls
該段代碼很簡單，通過ReDim修改了array數組的長度，屬性Preserve表示對數組中已賦值的那些數據不清空 ，但是該處并不影響對應的漏洞觸發，該屬性刪掉也是可以的：
Public Default Property Get P
ReDim Preserve array(1)
End Property
該重置array內存的操作實際通過函數RedimPreserveArray實現，如下所示傳入的array對象：

經過一番array類型判斷后最終會調用SafeArrayRedim，該函數也就是前面提到的漏洞CVE-2015-6332的成因根源，其原型如下所示，*psa為對應array對象，* psaboundNew為新數組的大小+1：
HRESULT SafeArrayRedim(
_Inout_ SAFEARRAY *psa,
_In_ SAFEARRAYBOUND *psaboundNew
);
此時的參數如下所示：

調用之后可以看到array對象的pvData已經被修改為0x084a0fe0，之前的pvData 0514dfd0的內存地址已經被釋放，包括我們之前存在賦值棧上的0x0514dff0：

最終調用函數AssignVar完成賦值，如下所示，具體賦值操作在紅框中，之前會有一個VAR：：Clear的操作，用于釋放之前的引用：

VAR：：Clear會獲取對應的array（2）的地址，從而造成崩潰：

總結一下，cls.array(2) = cls這行代碼中，cls.array（2）賦值前會保存array（2）的地址到求值棧上，之后cls中的Public Default Property Get P操作導致賦值前對array（）內存進行重新分配，即之前保存到求值棧上的指針指向的內存被釋放，該指針在最終的賦值操作中作為賦值的目標地址，從而導致重用崩潰。

樣本分析
360威脅情報中心通過大數據關聯到本次0day攻擊相關的一些payload文件，并對其中的一個后門程序進行了詳細分析。
Zlib
關聯到的一個后門程序名為Zlib，其主要功能為：
判斷加載進程，如果為mmc.exe，則zlib模塊是通過bypassuac的方式加載起來的，然后會通過rundll32加載zlib模塊的導出函數uncormpress2（也就是惡意代碼主函數），隨后調用進程退出。
判斷加載進程，如果不是rundll32加載的（Dropper加載），在DllMain函數中創建線程；再判斷操作系統是否為64位，如果為64位，直接執行惡意代碼主函數，如果不是64位，把zlib模塊文件拷貝到programdata目錄下，然后通過劫持mmc，運行mmc.exe，加載zlib模塊，實現bypassUAC，然后轉到第一步。
惡意代碼的功能主要是從自身解密出URL，下載惡意payload，解密成dll，修改上線配置信息后，在內存中加載運行。

具體流程如下所示：

詳細分析如下：
樣本MD5：80705564b4f89915a04bd4c416cd63bc
樣本編譯時間是2018年7月12日：

樣本入口首先會判斷加載DLL的主程序是什么：

如果加載DLL的進程為mmc.exe，通過給rundll32.exe傳參數調用DLL的uncompress2導出函數：

而該導出函數也被后面的調用進程不為rundll32.exe的流程的線程調用：

如果加載的進程不為rundll32.exe，會直接進入MainThread線程，該處會先判斷系統版本，如果是64位系統，直接下載并加載shellcode，如果不是的話，會進入LoadByMMC函數：

該函數的作用主要是把當前DLL復制到ProgramData下，然后運行批處理，通過劫持mmc，繞過UAC加載DLL：
/c REG ADD "HKCU\\Software\\Classes\\CLSID\\{D5AB5662-131D-453D-88C8-9BBA87502ADE}\\InprocServer32" /ve /t REG_EXP AND_SZ /d "%s\\zlib1.dll" /f &
REG ADD "HKCU\\Environment" /v "COR_PROFILER" /t REG_SZ /d "{D5AB5662-131D-453D-88C8-9BBA87502ADE}" /f &
REG ADD "HKCU\\Environment" /v "COR_ENABLE_PROFILING" /t REG_SZ /d "1" /f &
REG ADD "HKCU\\Environment" /v "COR_PROFILER_PATH" /t REG_SZ /d "%s\\zlib1.dll" /f &
mmc gpedit.msc

把操作系統版本和進程列表通過HTTP POST的方式發送到解密后的URL：



URL的解密算法，如下：

待解密的數據，和之前發過的報告的前面的標志是一樣的：OCCUR和OCCID

解密后的域名：

檢驗網絡返回數據的合法性，還和以前發的報告的樣本的算法是相同的：

解密成DLL后，把DLL里面的URL配置信息修改成當前的url，如圖：

尋找REFUR和REFID 這2個字段，按照同樣的加密算法，加密并寫回去：

然后在內存中加載執行惡意代碼：

該惡意代碼和之前代碼的相同處：
解密URL的代碼一樣
判斷網絡回來數據的合法性的地方一樣

不同處：
動態修改加載的DLL的上線URL和ID
ByPASS uac的方法在DLL里
另外，360威脅情報中心還關聯到一個新的DarkHotel使用的劫持Windows操作系統模塊的后門mstfe.dll（MD5: 5ce7342400cce1eff6dc70c9bfba965b），并發現新的C2：
hxxp://documentsafeinfo.com/mohamed/salah.php
hxxp://779999977.com/mohamed/salah.php


ID為dr.john-1:


總結
360威脅情報中心對DarkHotel APT團伙的攻擊活動一直保持著持續跟蹤，從本次事件可以看出，該攻擊團伙在近年中保持著相當高的活躍度，為了達成攻擊目的甚至會不惜使用0day漏洞進行攻擊。另一方面，以Office文檔作為0day攻擊載體依然是當前最為流行的攻擊方式，而通過微軟Office來利用第三方模塊0day漏洞的攻擊面已經成為黑客研究的熱點。
目前，基于360威脅情報中心的威脅情報數據的全線產品，包括360威脅情報平臺（TIP）、天眼高級威脅檢測系統、360 NGSOC等，都已經支持對此APT攻擊團伙最新攻擊活動的檢測。

IOC
URL
http://documentsafeinfo.com/mohamed/salah.php
http://779999977.com/mohamed/salah.php
http://windows-updater.net/stack/ov.php