背景
2018年8月15日，網(wǎng)絡(luò)安全公司趨勢(shì)科技公開(kāi)了其在今年7月捕獲到的一例在野0day漏洞攻擊，該攻擊利用了Windows VBScript Engine的代碼執(zhí)行漏洞，經(jīng)過(guò)分析對(duì)比發(fā)現(xiàn)該0day漏洞和2018年4月360公司首次發(fā)現(xiàn)影響IE瀏覽器并通過(guò)Office文檔進(jìn)行攻擊的“雙殺”漏洞（詳見(jiàn)參考[1]）使用了多個(gè)相同的攻擊技術(shù)，極有可能是同一團(tuán)伙所為。
360威脅情報(bào)中心第一時(shí)間對(duì)該0day漏洞進(jìn)行了分析確認(rèn)，并通過(guò)大數(shù)據(jù)關(guān)聯(lián)分析確認(rèn)本次的0day在野攻擊與DarkHotel APT組織存在關(guān)聯(lián)。
來(lái)源
2018年8月15日，趨勢(shì)科技公開(kāi)了其在今年7月11日捕獲到的一例在野0day漏洞攻擊技術(shù)分析，該漏洞已于公開(kāi)的前一天被微軟修復(fù)，漏洞編號(hào)為：CVE-2018-8373。
三個(gè)“雙殺”0day漏洞時(shí)間線
CVE-2018-8373其實(shí)是今年以來(lái)被發(fā)現(xiàn)的影響Windows VBScript Engine的第三個(gè)漏洞，其中前兩個(gè)均為360公司的安全研究人員首次發(fā)現(xiàn)，這三個(gè)漏洞均影響IE瀏覽器，且可以通過(guò)微軟Office文檔進(jìn)行攻擊。三個(gè)“雙殺”0day漏洞發(fā)現(xiàn)的時(shí)間線如下：
CVE
發(fā)現(xiàn)時(shí)間
修復(fù)時(shí)間
描述
CVE-2018-8174
2018.4.18
2018.5.8
影響Office和IE的雙殺漏洞，在野
CVE-2018-8242
2018.7.10
360安全研究人員發(fā)現(xiàn)并上報(bào)微軟（參考[2]）
CVE-2018-8373
2018.7.11
2018.8.14
影響Office和IE的雙殺漏洞，在野
溯源與關(guān)聯(lián)
獲得打碼后的IOC
360威脅情報(bào)中心通過(guò)大數(shù)據(jù)分析關(guān)聯(lián)首先得到了趨勢(shì)科技打碼后的IOC地址：
http://windows-updater.net/realmuto/wood.phpwho=1
關(guān)聯(lián)同源0day攻擊樣本
并發(fā)現(xiàn)一個(gè)攻擊時(shí)間和趨勢(shì)科技發(fā)現(xiàn)在野“雙殺”0day攻擊在同一天的疑似使用該0day攻擊的office文檔樣本，該Offce文檔樣本中內(nèi)嵌的域名和趨勢(shì)科技給出的域名格式一致（http://windows-updater.net/stack/ov.phpw= 1\x00who =1）
確認(rèn)與DarkHotel關(guān)聯(lián)
得到0day漏洞攻擊所使用的域名后我們立即發(fā)現(xiàn)，該域名正是360威脅情報(bào)中心在今年5月發(fā)布的關(guān)于DarkHotel APT團(tuán)伙最新的攻擊活動(dòng)中使用過(guò)的域名（詳見(jiàn)參考[4]）:
在360威脅情報(bào)中心威脅平臺(tái)中輸入該域名也會(huì)立即關(guān)聯(lián)到DarkHotel：
CVE-2018-8373漏洞分析
如下所示為趨勢(shì)給出的對(duì)應(yīng)POC觸發(fā)代碼：
如下為該漏洞和今年5月360捕獲的CVE-2018-8174的POC對(duì)比，CVE-2018-8174主要的漏洞原因在于Class_Terminater中可以對(duì)釋放的內(nèi)存對(duì)象繼續(xù)賦值，從而導(dǎo)致釋放后重用，而這次的CVE-2018-8373則是類的Propert Get操作中可以修改對(duì)應(yīng)的類成員array的長(zhǎng)度，從而導(dǎo)致之后的對(duì)象重用：
如下為對(duì)應(yīng)的的POC代碼，POC代碼很簡(jiǎn)單，VulClass類中定義了array成員變量，
方法Class_Initialize及Public Default Property Get P。
其中Class_Initialize是VB中一個(gè)已經(jīng)棄用的方法，用于在類創(chuàng)建的時(shí)候?qū)崿F(xiàn)對(duì)應(yīng)的操作，重載后可以在類創(chuàng)建時(shí)完成相應(yīng)的初始化工作，之后被new代替。
Default Property為一個(gè)類屬性，被Public Default Property Get P重載后，對(duì)該類的訪問(wèn)將觸發(fā)相應(yīng)的操作，在POC中即執(zhí)行ReDim Preserve array(1)。
ReDim用于對(duì)指定的內(nèi)存重新分配，其最終在VB引擎中通過(guò)SafeArrayRedim函數(shù)實(shí)現(xiàn)，熟悉VB漏洞的話，可以知道該函數(shù)就是之前CVE-2015-6332漏洞的根源：
POC中首先執(zhí)行該行代碼，new的時(shí)候?qū)?yīng)執(zhí)行以下函數(shù)VBScriptClass::InitializeClass，由于VulClass類中重載了Class_Initialize方法，因此通過(guò)vbscript!CScriptEntryPoint::Call派發(fā)進(jìn)入到對(duì)應(yīng)的編碼者實(shí)現(xiàn)的Class_Initialize方法中：
Set cls = New VulClass
Class_Initialize方法中修改對(duì)應(yīng)的array長(zhǎng)度：
Private Sub Class_Initialize
ReDim array(2)
End Sub
可以看到此時(shí)生成的Array對(duì)象如下所示，其成員變量數(shù)為3，對(duì)應(yīng)的pvData為0x0514dfd0：
之后運(yùn)行以下代碼，VB引擎解析以下代碼的順序是從左自右掃描的，因此首先會(huì)進(jìn)行cls.array(2)的操作：
cls.array(2) = cls
此時(shí)會(huì)調(diào)用函數(shù)vbscript!AccessArray判斷對(duì)應(yīng)array（2）是否可訪問(wèn)，如下所示此時(shí)獲取對(duì)應(yīng)array的內(nèi)存對(duì)象：
經(jīng)過(guò)一番判斷之后，如下所示esi指向?qū)?yīng)的array對(duì)象，依次獲取array中每個(gè)成員的大小cbElements，此處為0x10，需要訪問(wèn)賦值的array index，此處為2，pvData，以此計(jì)算出array（2）對(duì)象的地址0514dfd0（pvData）+2（element）*10（cbElements）=0514ff0，0514ff0會(huì)被直接拷貝到求值棧上：
如下所示拷貝到求值棧上的array(2)地址：
通過(guò)內(nèi)存訪問(wèn)斷點(diǎn)可以跟蹤對(duì)該地址的引用：
之后執(zhí)行等號(hào)右側(cè)部分的操作，由于該VulClass類定義了Public Default Property Get P，因此會(huì)在賦值前執(zhí)行其中對(duì)應(yīng)的代碼：
cls.array(2) = cls
該段代碼很簡(jiǎn)單，通過(guò)ReDim修改了array數(shù)組的長(zhǎng)度，屬性Preserve表示對(duì)數(shù)組中已賦值的那些數(shù)據(jù)不清空 ，但是該處并不影響對(duì)應(yīng)的漏洞觸發(fā)，該屬性刪掉也是可以的：
Public Default Property Get P
ReDim Preserve array(1)
End Property
該重置array內(nèi)存的操作實(shí)際通過(guò)函數(shù)RedimPreserveArray實(shí)現(xiàn)，如下所示傳入的array對(duì)象：
經(jīng)過(guò)一番array類型判斷后最終會(huì)調(diào)用SafeArrayRedim，該函數(shù)也就是前面提到的漏洞CVE-2015-6332的成因根源，其原型如下所示，*psa為對(duì)應(yīng)array對(duì)象，* psaboundNew為新數(shù)組的大小+1：
HRESULT SafeArrayRedim(
_Inout_ SAFEARRAY *psa,
_In_ SAFEARRAYBOUND *psaboundNew
);
此時(shí)的參數(shù)如下所示：
調(diào)用之后可以看到array對(duì)象的pvData已經(jīng)被修改為0x084a0fe0，之前的pvData 0514dfd0的內(nèi)存地址已經(jīng)被釋放，包括我們之前存在賦值棧上的0x0514dff0：
最終調(diào)用函數(shù)AssignVar完成賦值，如下所示，具體賦值操作在紅框中，之前會(huì)有一個(gè)VAR：：Clear的操作，用于釋放之前的引用：
VAR：：Clear會(huì)獲取對(duì)應(yīng)的array（2）的地址，從而造成崩潰：
總結(jié)一下，cls.array(2) = cls這行代碼中，cls.array（2）賦值前會(huì)保存array（2）的地址到求值棧上，之后cls中的Public Default Property Get P操作導(dǎo)致賦值前對(duì)array（）內(nèi)存進(jìn)行重新分配，即之前保存到求值棧上的指針指向的內(nèi)存被釋放，該指針在最終的賦值操作中作為賦值的目標(biāo)地址，從而導(dǎo)致重用崩潰。
樣本分析
360威脅情報(bào)中心通過(guò)大數(shù)據(jù)關(guān)聯(lián)到本次0day攻擊相關(guān)的一些payload文件，并對(duì)其中的一個(gè)后門程序進(jìn)行了詳細(xì)分析。
Zlib
關(guān)聯(lián)到的一個(gè)后門程序名為Zlib，其主要功能為：
判斷加載進(jìn)程，如果為mmc.exe，則zlib模塊是通過(guò)bypassuac的方式加載起來(lái)的，然后會(huì)通過(guò)rundll32加載zlib模塊的導(dǎo)出函數(shù)uncormpress2（也就是惡意代碼主函數(shù)），隨后調(diào)用進(jìn)程退出。
判斷加載進(jìn)程，如果不是rundll32加載的（Dropper加載），在DllMain函數(shù)中創(chuàng)建線程；再判斷操作系統(tǒng)是否為64位，如果為64位，直接執(zhí)行惡意代碼主函數(shù)，如果不是64位，把zlib模塊文件拷貝到programdata目錄下，然后通過(guò)劫持mmc，運(yùn)行mmc.exe，加載zlib模塊，實(shí)現(xiàn)bypassUAC，然后轉(zhuǎn)到第一步。
惡意代碼的功能主要是從自身解密出URL，下載惡意payload，解密成dll，修改上線配置信息后，在內(nèi)存中加載運(yùn)行。
具體流程如下所示：
詳細(xì)分析如下：
樣本MD5：80705564b4f89915a04bd4c416cd63bc
樣本編譯時(shí)間是2018年7月12日：
樣本入口首先會(huì)判斷加載DLL的主程序是什么：
如果加載DLL的進(jìn)程為mmc.exe，通過(guò)給rundll32.exe傳參數(shù)調(diào)用DLL的uncompress2導(dǎo)出函數(shù)：
而該導(dǎo)出函數(shù)也被后面的調(diào)用進(jìn)程不為rundll32.exe的流程的線程調(diào)用：
如果加載的進(jìn)程不為rundll32.exe，會(huì)直接進(jìn)入MainThread線程，該處會(huì)先判斷系統(tǒng)版本，如果是64位系統(tǒng)，直接下載并加載shellcode，如果不是的話，會(huì)進(jìn)入LoadByMMC函數(shù)：
該函數(shù)的作用主要是把當(dāng)前DLL復(fù)制到ProgramData下，然后運(yùn)行批處理，通過(guò)劫持mmc，繞過(guò)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
把操作系統(tǒng)版本和進(jìn)程列表通過(guò)HTTP POST的方式發(fā)送到解密后的URL：
URL的解密算法，如下：
待解密的數(shù)據(jù)，和之前發(fā)過(guò)的報(bào)告的前面的標(biāo)志是一樣的：OCCUR和OCCID
解密后的域名：
檢驗(yàn)網(wǎng)絡(luò)返回?cái)?shù)據(jù)的合法性，還和以前發(fā)的報(bào)告的樣本的算法是相同的：
解密成DLL后，把DLL里面的URL配置信息修改成當(dāng)前的url，如圖：
尋找REFUR和REFID 這2個(gè)字段，按照同樣的加密算法，加密并寫(xiě)回去：
然后在內(nèi)存中加載執(zhí)行惡意代碼：
該惡意代碼和之前代碼的相同處：
解密URL的代碼一樣
判斷網(wǎng)絡(luò)回來(lái)數(shù)據(jù)的合法性的地方一樣
不同處：
動(dòng)態(tài)修改加載的DLL的上線URL和ID
ByPASS uac的方法在DLL里
另外，360威脅情報(bào)中心還關(guān)聯(lián)到一個(gè)新的DarkHotel使用的劫持Windows操作系統(tǒng)模塊的后門mstfe.dll（MD5: 5ce7342400cce1eff6dc70c9bfba965b），并發(fā)現(xiàn)新的C2：
hxxp://documentsafeinfo.com/mohamed/salah.php
hxxp://779999977.com/mohamed/salah.php
ID為dr.john-1:
總結(jié)
360威脅情報(bào)中心對(duì)DarkHotel APT團(tuán)伙的攻擊活動(dòng)一直保持著持續(xù)跟蹤，從本次事件可以看出，該攻擊團(tuán)伙在近年中保持著相當(dāng)高的活躍度，為了達(dá)成攻擊目的甚至?xí)幌褂?day漏洞進(jìn)行攻擊。另一方面，以O(shè)ffice文檔作為0day攻擊載體依然是當(dāng)前最為流行的攻擊方式，而通過(guò)微軟Office來(lái)利用第三方模塊0day漏洞的攻擊面已經(jīng)成為黑客研究的熱點(diǎn)。
目前，基于360威脅情報(bào)中心的威脅情報(bào)數(shù)據(jù)的全線產(chǎn)品，包括360威脅情報(bào)平臺(tái)（TIP）、天眼高級(jí)威脅檢測(cè)系統(tǒng)、360 NGSOC等，都已經(jīng)支持對(duì)此APT攻擊團(tuán)伙最新攻擊活動(dòng)的檢測(cè)。
IOC
URL
http://documentsafeinfo.com/mohamed/salah.php
http://779999977.com/mohamed/salah.php
http://windows-updater.net/stack/ov.php
| 
