from:https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns.pdf
今年年初，卡巴斯基實驗室在安全掃描過程中，檢測到了幾個影響了自家內部系統的網絡入侵行為。
接著我們大范圍調查了這些入侵事件。我們分析發現了一個全新的木馬平臺，這個平臺出自Duqu APT小組之手。Duqu APT小組是世界上最神秘，水平最高的APT小組。這個小組從2012年開始銷聲匿跡，直到今天又卷土重來。我們分析了這新一輪攻擊，結果表明這是2011年Duqu木馬的升級版，懷疑與Stuxnet木馬有關。我們把這個新木馬和相關的平臺命名為"Duqu 2.0"。
Duqu利用了0-day漏洞CVE-2015-2360（WindowsKernel中的漏洞）和另外兩個0-day漏洞，攻擊了卡巴斯基實驗室。微軟在2015年6月9日修復了第一個漏洞，另兩個漏洞在近期也得到了修復。
Filename:隨機 / 根據具體樣本而定
MD5 (根據具體樣本而定): 14712103ddf9f6e77fa5c9a3288bd5ee
Size: 503,296 bytes
MSI文件具有一下屬性
其他攻擊中使用的MSI文件可能具有另外一些屬性。例如，我們還發現了另外幾個字段：
在Windows資源管理器的文件屬性對話框中，可以查看某些字段。
這個MSI數據包中有兩個二進制文件：
ActionDll是一個dll文件，ActionData0是一個經過Camellia加密，LZJB壓縮的數據payload（不同情況下的加密算法和壓縮算法也不同）。實際上，經過加密或壓縮的二進制數據塊中，會有好幾層可執行代碼。
在后面的文章中，我們詳細地說明了這些組件。
原文件名: msi.dll
MD5: e8eaec1f021a564b82b824af1dbe6c4d
Size: 17’920 bytes
Link時間: 2004.02.12 02:04:50 (GMT)
類型: 64-bit PE32+ executable DLL for MS Windows
這個DLL只有一個StartAction導出函數，msiexec.exe進程的上下文會調用這個函數。當這個函數被調用時，這個函數就會獲取一個MSI屬性-PROP，并用這個值來解密actionData0包。
接下來，這段代碼會遍歷12個需要解密并啟動的payload。這些payload是MSI的一部分，可能會包含以下名稱：ActionData0, ActionData1, ActionData2。
我們的這個數據包中只包含一個paylioad-“ActionData0”。
主代碼會被壓縮和加密到這個二進制數據包中。這個二進制的組成包括可執行程序，位置無關代碼塊，和內嵌的數據對象。這些代碼似乎遵循著某種框架，使用了很多輔助結構。輔助結構中包含了一些系統API的指針和內部數據塊的偏移量。這些結構能反映出開發者的風格。當代碼初始化時，一個字段（一般是前四個字節）中的magic值就會識別結構的狀態和類型。
這名編碼員還喜歡根據模塊和輸出名稱的哈希來導入系統API。在可執行代碼的很多層上都使用了這個哈希算法。通過兩個DWORD常量就能識別：0x8A20C27和0x67F84FC6。
一般情況下，ActionData0中的代碼會在一個內嵌的可執行程序-“klif.dll”上運行，由這個DLL文件的導出函數表上的第二個函數執行。也就是說，函數名稱無所謂，就是要按照函數表上的順序。當調用這個導出函數時，下一階段的輔助結構指針就會傳遞到這個函數上，這樣指針就能使用上一層中設置的一些值。
但是，在klif.dll執行之前，代碼會嘗試另一條路徑。首先，代碼會查找“api-ms-win-shell-XXXX.dll”，其中X可以是任意的十進制數。如果當前進程中沒有這種名稱形式的模塊，名稱就是無效的。這樣的話，代碼就會遍歷查找任何符合名稱形式的模塊，首先從api-ms-win-shell-0000.dll, api-ms-win-shell-0001.dll, api-ms-winshell-0002.dll開始。這應該是Duqu平臺組件的一個依賴選項。
在找到名稱后，代碼會嘗試按照名稱來映射內核(section kernel object)對象，這些名稱是使用PRNG算法生成的。節名稱的格式“\BaseNamedObjects{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}”，其中X是根據當前系統的啟動時間生成的十六進制數字。到目前為止，節名稱都是根據“machine/boot time” 來確定的，這樣每個節名稱都不一樣，但是如果有其他模塊的進程也使用了相同的名稱生成算法，進程就能定位這樣的節。以OSBoot節為例，一旦生成了節名稱，代碼就會打開節，如果能找到節，代碼就會從節中選取幾個值，然后嘗試打開特定的設備，并把ICTL代碼發送到驅動上。驅動設備的名稱和IOC代碼都在KMART.dll 內的一個節中。
這名編碼員非常喜歡用節來訪問數據。在映射klif.dll的代碼/數據時，還是要用節。另外也可以通過硬編碼magic QWORD數: 0xA1B5F8FC0C2E1064來找到這個節。一旦在當前進程的地址空間中找到了節，就由這個節來運行代碼。當前的MSI文件數據包并不能應用這種執行路徑，但是這種執行路徑出現在了代碼中，我們猜測這可能是為了使用通用代碼模版來創建當前的MSI數據包。當然，這也說明，其他的Duqu平臺組件還具有另外的特征。
Original filename: klif.dll
MD5: 3fde1bbf3330e0bd0952077a390cef72
Size: 196’096 bytes
Link time: 2014.07.06 08:36:50 (GMT)
Type: 64-bit PE32+ executable DLL for MS Windows
很顯然，這個文件偽裝成了卡巴斯基產品的名稱-“klif.sys”。雖然代碼和文件信息與卡巴斯基產品完全不同，但是，這個模塊的導出函數名稱使用了卡巴斯基實驗室的縮寫：KLInit 和KLDone。
當這個DLL加載到一個新進程中時，DLL的內部結構就會初始化，比如給系統API提供指針的結構。
這個模塊的payload位于KLDone導出函數上，是導出函數列表上的第二個函數。這個導出函數是從上一層代碼中調用的。 首先，模塊會確保全局應用結構和關鍵函數ntdll.dll, kernel32.dll and user32.dll，已經初始化。在調用系統API函數時，需要使用導出函數名稱的哈希。哈希算法與前文提到的算法相同，并且也使用了相同的magic常量：0x8A20C27 和0x67F84FC6。
接下來，代碼會遍歷正在運行的進程列表，并且獲取每個進程的小寫名稱哈希。這個哈希可以是0x3E3021CB 的硬編碼值，也就是“avp.exe”字符串的哈希。
如果“avp.exe”進程正在運行，模塊就會嘗試打開OSBoot-section，并且嘗試攻擊avp.exe進程。攻擊開始時，首先遍歷下列產品的硬編碼注冊表項和注冊表值，來識別卡巴斯基產品的安裝路徑：
在模塊所查詢的注冊表值中包含了卡巴斯基產品的根目錄路徑，如“C:\Program Files\KasperskyLab\Kaspersky Internet Security 15.0.0\”
一旦找到了注冊表項和注冊值，模塊就會確認avp.exe是不是在那個路徑下面。另外它還會對文件執行一些額外的檢查:環境變量的檢查,文件能否被讀取的檢查,是否是一個PE文件的檢查.
之后這個模塊執行如下動作:1.把avp.exe映射到它內部2.改變內存區域的屬性讓代碼執行3.改變avp.exe內的字符4.使用SSE2 CPU擴展對avp.exe打補丁.
接著，模塊會嘗試啟動一個新的線程，線程的開始位置就是其中一個補丁的位置。到目前為止，新的線程會首先調用avp.exe模塊，這個模塊會執行其他的一些調用，比如，跳回到klif.dll。很顯然，這次攻擊是為了讓avp.exe相信后續的調用是安全的，相信調用堆棧是來自一個合法的avp.exe模塊。繼續研究代碼，發現：新線程會立刻從avp.exe跳轉會klif.dll，并且會嘗試與卡巴斯基產品的微過濾器，也就是klif.sys通信。
事實上，在與klif.sys通信之前，新線程會打開OSBoot-section，并獲取一個IOCTL代碼和驅動設備的名稱，然后把這個IOCTL代碼發送給設備。這個節和相應的驅動（KMART.dll）會給當前模塊提供一定的支持。代碼會獲取當前進程名稱的哈希，并且驗證哈希是不是下列三個哈希之一：0x3E3021CB (avp.exe), 0xDE6D4DA0 (msiexec.exe), 0xB915B2D8 (rundll32.exe)。
如果能識別當前進程名稱的哈希，模塊就會打開\KlifComm微過濾器的通信端口，并且發送一些驅動通信信息，來和klif.sys通信。通過分析這些信息，我們發現這項技術能讓klif發現不了進程或線程操作。所有的殺毒產品都會認為這個注冊過的項目是受信任的，所以不會掃描其活動，也不會檢測或攔截其進程。另外，這個模塊會要求卡巴斯基產品的自我防御支持，這個功能是防止木馬利用系統技術來殺掉安全產品的進程。這樣的話，即使是管理員用戶也無法終止模塊的進程。
我們測試了卡巴斯基的其他一些產品，結果發現，這些產品都會檢查進程的自定義數字簽名來驗證caller進程。截至目前，如果沒有額外的驅動支持，這項技術不會成功。從2010年開始，如果有進程嘗試打開\KlifComm微過濾器的通信端口，卡巴斯基的產品就會驗證這些進程的數字簽名。這種攻擊只能影響舊版的卡巴斯基產品，比如在2009年發布的KIS2010。
一般來說，攻擊者現在不會攻擊卡巴斯基在2009年之前發布的產品。所以，我們有分析了另一種比較合理的解釋。
通常來說，這類攻擊不會攻擊我們的產品，因為我們的產品會檢查進程的自定義數字簽名，來驗證進程的合法性。為了繞過這種檢測，Duqu 2.0的一個“KMART.dll”模塊給內存中的“klif.sys”打了補丁。因為 “KMART.dll”已經利用Windows內核漏洞在內核模式下運行了，所以這種攻擊才能發揮作用。
在發送完代碼后，模塊會繼續下一階段，也就是進程遷移。
第三層-klif.dll會執行多個函數，來保證木馬能駐進內存，并且繞過殺毒檢測。
很重要的一點就是獲取內核權限。在64位系統上，如果驅動沒有簽名，用戶就不能加載和運行它。雖然其他攻擊者，例如Equation 或 Turla，他們會選擇利用第三方簽名的驅動，但是Duqu 2.0平臺使用的手段要高明很多。
其中一個payload-“CTwoPENC.dll”捆綁了“klif.dll”。這是一個Windows內核漏洞(CVE-2015-2360)。利用這個漏洞，payload就能使用最高權限來運行代碼。我們恢復了幾個版本的“CTwoPENC.dll”，存在32位和64位版本，編譯時間戳如下：
不同于Duqu 2.0的其他模塊，這些時間戳看起來都是合法的。至于為什么會這樣，我們還不清楚-可能Duqu平臺的開發者使用的是其他人編寫的模塊，而開發者忘了修改編譯時間戳。
“CTwoPENC.DLL”是 “win32k.sys” 中存在的一個0-day漏洞，利用這個漏洞，非權限用戶也能獲取到內核權限。這個模塊會利用漏洞來創建窗口，線程的類別名稱分別是“CPer”, “Zero”, “CTwo”, “Vero” ，并且模塊還能操控回調指針。
部分漏洞代碼會注冊窗口類并創建新的窗口
這個漏洞的目的是加載一個“KMART.dll”驅動。如果漏洞攻擊成功，“KMART.dll”就會從模塊中解壓縮，然后在內核模式下發動攻擊。“KMART.dll”既有32位也有64位版本。然后，這個驅動會執行一個內核模式攻擊，攻擊目標就是卡巴斯基產品的過濾器“klif.sys”。“KMART.dll”會給系統API函數-PsGetCurrentProcessId, PsLookupProcessByProcessId的導入表地址打補丁，也會給殺毒驅動-klflt.sys的輸出函數KlGetStringRef 打補丁。在函數被攔截之前，惡意代碼已經把惡意模塊偽裝成來自進程/文件“avp.exe”（使用殺毒組件的真實位置），這樣就能繞過殺毒軟件的監視。
在測試期間，所有的Windows版本(32位和64位的XP, Vista, 7, 8, 8.1)上都受這個漏洞的影響。微軟于2015年6月9日修復了這個漏洞。
payload容器中包含一個短代碼節，用于描述目標CPU的架構，payload類型和目標進程的名稱或哈希。當模塊使用某些內嵌代碼或文件時，代碼中一般會有兩個代碼變量：32位和64位。每個payload的運行類型都是根據單一字符來識別。當前模塊支持這5種payload 運行類型：g,i,k,l,q。開發者使用的字符按照字母表順序排列，也就是說，代碼中原來可能還有其他的payload類型，只不過被移除了。
運行類型為“L”的payload
首先，代碼會在其他進程中查找權限。進程句柄是硬編碼的，或者是通過查找當前運行進程，獲取進程的名稱，然后對比已知哈希來獲得的。模塊中包括下列硬編碼進程的哈希： 0x31283314 (services.exe), 0x1026D1BA (lsass.exe), 0x3BD2498C (svchost.exe)。
如果發現了任何識別出的進程，模塊就會打開進程標記，并驗證下列的權限是否可用：
如果這些權限可用，模塊就會復制進程標記并保存到內部結構中，以便日后使用。
模塊在當前系統中，查找一個可用的殺毒軟件和一些通用進程。如果什么都沒有發現，模塊就會嘗試查找下列軟件的可執行文件：
當模塊發現了一個這樣的可執行程序后，模塊會從發現的位置上運行一個新的進程，并使用自己的代碼替換當前可執行文件中的可執行代碼，代碼會經過加密和壓縮。
如果代碼能從具有安全權限的進程中，找到一個安全標記，代碼就會使用CreateProcessAsUser API來創建一個新的進程，在這時，代碼就會使用得到的安全標記。否則，代碼只會簡單地生成一個新的進程。
這個新進程在啟動時，處于掛起和調試狀態。在新進程啟動前，為了簡化代碼注入和數據操控，子進程的DEP是禁用的。這樣，從外表上看，這個進程就像是一個殺毒程序的進程，但是它的內部代碼可完全不是合法的模塊。
運行模式為“G”的payload
這種payload與上面的payload幾乎一樣，但是這個payload的載入程序更簡單-這個Loader不進行hijack和提權步驟。注入進程的選擇是自動的，只要是可用進程就可以。
運行模式為“I”的payload
這種payload類似于G類 payload，但是它的載入程序在解析payload的標頭時有區別：這個載入程序只會選取4個字節來作為進程的哈希，而是不是進程名稱字符串。這種方法可能是為了隱藏目標進程的名稱，但是，并不是整個模塊都應用了這種方法。
運行模式為“K”的payload
這種payload會在當前進程的上下文中運行。代碼僅僅會復制需要在獨立內存中執行的代碼，然后在單獨的線程中運行這些代碼。在線程完成執行后，執行就會被攔截。
運行模式為“Q”的payload
這種payload與 Q類 payload一樣，但是這種payload不會攔截新線程的執行。目前來看，新代碼是異步運行的。
在payload容器打開后，代碼就會遷移到另一個進程，安全軟件會保護這個進程，這樣真正的惡意代碼就啟動了。在多數情況下，我們稱其為后門通道，能監聽協調器的通信。在很少的情況下，某些設備上的協調器模塊才能與C2通信，這是才可以作為一個雙向代理，來提供大量的二級插件。
插件化模塊平臺
除了基本的遠程后門，攻擊者還在域控制器上和受害者的設備上，部署了更復雜的數據包。這些MSI軟件包包括很多模塊，各自的作用也不同。
具備完整功能的軟件包很大-18MB，基本的遠程后門只有500KB。這兩者的結構相同，都有ActionDll和加載程序，但是軟件還有用于載入和運行的插件。
分析中，我們識別了100多種插件的變種。關于插件的描述如下。我們使用MD5的前兩個字節創建了虛擬標識符，來區分插件。
03B7-Duqu2.0的主要模塊，大師手筆
可以使用HTTP HTTPS SMB網絡管道 或者加密的TCP直連的方式通信.跟2011duqu一樣它可以把交互隱藏在Jpeg或者gif圖片中通過http的方式來進行.請求名字,url,和user-agent在不同的攻擊中可能是不同的.
已知其他變種：3026, 4F11。
0682 –收集基本系統信息：
收集到的信息會通過caller提供的命名管道來傳輸。
已知其他變種：C0B7
073C **–在客戶端和服務器上應用完整的Windows Socket傳輸**。提供工廠類來封裝網絡函數。
0872-當Windows安裝程序啟動了惡意軟件安裝包時，MSI CustomAction library就會被激活。然后，加載包含payload的加密二進制，接著解密，并在內存中執行。
版本信息中的名稱有好幾個：svcmsi_32.dll, msi3_32.dll, MSI.dll, msi4_32.dll。
加密算法也不同：Camellia 256, AES, XXTEA。
從MSI參數中提取出的解密密鑰可能是：PROP,HASHVA, CKEY。
通過前綴（根據具體情況）來搜索加密的二進制對象：ActionData, CryptHashs, CAData。
已知存在32位和64位版本。其他已知變體：8D7C, 16EF, E6E5,434C, 44BD, F708。
09A0-64位變體，能竊取文件內容。搜索符合下列規則的文件：
09A0 插件感興趣的文件名稱和目錄名稱
已知其他變體：8858
0AB8 –提供25個函數，這些函數能操控文件和目錄：
在某些情況中，模塊會搜索目錄-“\int”, “\lg”, “\of\md”, “\tl”, “\ak”，以及擴展名-“.part”, “.manual”, “.inuse”。
0AB8 插件感興趣的文件目錄名稱
其他已知變體：A69E
0B97-網絡傳輸。利用API來連接socket和caller提供的管道。其他變體：56A2。
152B-網絡和域發現。
其他已知樣本：A987
1C71-把文件數據放到內存中。
2125-網絡感染模塊。嘗試從正在運行的進程中，獲取管理憑證。然后使用Windows共享來連接到一個目標設備。接著，惡意DLL后門成功感染設備；目標目錄是變化的，可能在UPDROOT$, ADMIN$ 或 C$。使用自定義SMB數據包來識別目標OS的版本。然后使用新創建的服務“svcmsi_[email protected]，[email protected]??后門通信。其他變體：DB65。除了惡意DLL，模塊還會上傳一個新的MSI數據包，并且依賴MSIEXEC.EXE 通過新創建的服務“msisvc_[email protected]，目標MSI的名稱是隨機生成的，名稱模版是“tmp%x.tmp”。
在被感染時，Windows創建的事件日志（系統）項目
模塊通過竊取當前運行進程的token來獲取管理憑證。這些進程需要是管理員權限用戶啟動的。所以，模塊首先會直接在域控制器中，查詢當前域中的100個管理員用戶名。
網絡感染模塊使用的遠程位置
24B7-遠程桌面管理。獲取屏幕截圖，同時可以發送輸入到桌面，移動鼠標光標。存在32位和64位版本的變體。其他的已知變體：65BE, 7795, BDC8, DEE2
26D6-檢測正在運行的網絡嗅探器（wireshark, tcpview, netstat, dumpcap, perfmon)，設置一個TCP服務器，并通過網絡管道通信。內部名稱：“P.dll。
2829-收集系統信息
2913-WMI數據收集
其他已知變體：C776
29D4-模塊2125利用服務msisvc_32@; DLL backdoor來感染網絡，通過管道“Global{B54E3268-DE1E-4c1e-A667- 2596751403AD}”來接收命令。存在32位和64位變體。
其他已知變體：6F92, A505, D242
2B46-收集系統和用戶信息
模塊收集到的一些注冊位置
已知變體：A7F8
2BF7-實用工具DLL。提供基本的API來創建新的MSI數據包，加載并注入任意PE模塊。同時負責加載惡意MSI文件中，VFS的第一層。存在32位和64位變體。
已知名稱：“ntdll.dll”, “klif.dll”, “apiset.dll”.
其他已知變體：6DA1, 32DB, 8304, 9931, 9E60, A2D4, ABA9, B3BB, DC5F, DD32, F7BB
3395-MS SQL發現模塊。這個模塊能向網絡發送ARP數據包，同時發現MS SQL Server端口。其他函數負責連接額讀取遠程注冊表內容。
35E9-文件系統發現。
3F45-管道后門。打開一個新的全局可見的Windows管道，接收并執行加密的命令。“magic”字符串說明加密的協議是“tttttttt”。
存在32位和64位版本。
已知的管道名稱：
其他已知變體：6364, 3F8B, 5926, A90A, DDF0, A717, A36F, 8816, E85E, E927
使用這些數據來定位Chrome保存的登錄信息
其他已知 變體：B656
該模塊收集的信息
其他已知變體：992E，AF68，D49F
其他已知變體：F3F4
ActiveDirectory詳細路徑
它有兩個導出函數其中一個的名字是"Getreport"
存在32位和64位版本。
其他已知變體：E8C7，EE6E
生成系統報告的XML標簽
內部名稱“d3dx9_27.dll”。執行基于時間的事件。
其他已知變體：FA84
列舉文件名稱和目錄，檢查它們是否存在。
其他已知變體：880B
使用合法WinPcap驅動器“npf.sys”。檢測NBNS（NetBIOS協議）感興趣的請求并發送響應
網絡過濾器基于BPF庫。HTTP和WPAD的payload由外部提供.
虛假HTTP響應及相關狀態信息
其他已知變體：A7EE
其他已知變體：EF2E
搜索文件、檔案及implements routines中的信息并提取：
創建擴展名為“.fg4”的臨時文件。
其他已知變體：EB18，C091
感興趣的文件擴展名及其對應的狀態信息列表
8172——嗅探攻擊。執行 NBNS（NetBIOS協議）名稱解析來欺騙：
附加功能：該組件能夠在硬編碼模板中新建shellcode blob。
81B7——驅動程序管理
其他已知變體： C1B9
8446——Oracle DB和ADOdb客戶端
8912——處理加密文件，收集系統信息
已知互斥體和映射名：
其他已知變體： D19F, D2EE
9224——運行控制臺應用程序。使用桌面"default"創建進程,附加到命令行窗口,把i/o重定向到命名管道.
92DB——修改cmd.exe shell。
9F0D（64位）， D1A3（32位）——NPF.SYS這個驅動是伴隨著VFS插件一起分發的,它有合法的簽名.。它被用來執行嗅探攻擊。
A4B0——網絡調查
B6C1 - WNet API。為WnetAddConnection2和WNetOpenEnum函數提供wrappers
其他已知變體：BC4A
C25B——嗅探攻擊。運行一個偽造SMB服務器來誘騙其他電腦用NTLM進行驗證。
ED92——文件系統調查
EF97——文件操作動作
其他已知變體：F71E
一般來說,刻畫黑客的犯罪過程是一件很困難的事情,duqu2.0尤甚.
duqu除了使用大量的代理來隱蔽自身的犯罪行為外,還額外使用了一些小伎倆:比如它會在代碼中植入幾個虛假的標記,ugly.gorilla&romanian.antihacker, LZJB算法,前者會讓我們錯誤的認為此次攻擊事件是由中國人干的或者這是一次來自羅馬尼亞的黑客攻擊,后者會讓我們錯誤的認為這個木馬來源于miniduke家族.
duqu的攻擊具有多地域特征,受害者既有西方國家,也有中東和亞洲國家.關于duqu背后的黑客我們發現了很有趣的一點,那就是他們不僅會盜竊,還會偷方便盜竊用的工具.比如為了投放木馬他們在2011年攻擊了匈牙利的一家管理數字證書的企業.
duqu2.0的攻擊目標和duqu1.0的攻擊目標有很多重合的地方.伊朗核設施和一些工控企業始終是他們覬覦的目標.
對一家網絡安全公司來說,承認系統被入侵是一件不可想象的事情,但是對卡巴斯基來說不是這樣的,因為我們秉承公開透明的原則,基于對用戶安全的考量,我們選擇公布了此次事件的調查結果.---|||||||||---|||||||||為了用戶的信任 我們會戰斗到底。
