virustracker · 2015/06/12 14:34git
from:https://securelist.com/files/2015/06/The_Mystery_of_Duqu_2_0_a_sophisticated_cyberespionage_actor_returns.pdfgithub
今年年初,卡巴斯基實驗室在安全掃描過程當中,檢測到了幾個影響了自家內部系統的網絡入侵行爲。算法
接着咱們大範圍調查了這些入侵事件。咱們分析發現了一個全新的木馬平臺,這個平臺出自Duqu APT小組之手。Duqu APT小組是世界上最神祕,水平最高的APT小組。這個小組從2012年開始銷聲匿跡,直到今天又捲土重來。咱們分析了這新一輪攻擊,結果代表這是2011年Duqu木馬的升級版,懷疑與Stuxnet木馬有關。咱們把這個新木馬和相關的平臺命名爲"Duqu 2.0"。sql
Duqu利用了0-day漏洞CVE-2015-2360(WindowsKernel中的漏洞)和另外兩個0-day漏洞,攻擊了卡巴斯基實驗室。微軟在2015年6月9日修復了第一個漏洞,另兩個漏洞在近期也獲得了修復。shell
Filename:隨機 / 根據具體樣本而定
MD5 (根據具體樣本而定): 14712103ddf9f6e77fa5c9a3288bd5ee
Size: 503,296 bytes
複製代碼
MSI文件具備一下屬性數據庫
其餘攻擊中使用的MSI文件可能具備另一些屬性。例如,咱們還發現了另外幾個字段:windows
在Windows資源管理器的文件屬性對話框中,能夠查看某些字段。api
這個MSI數據包中有兩個二進制文件:緩存
ActionDll是一個dll文件,ActionData0是一個通過Camellia加密,LZJB壓縮的數據payload(不一樣狀況下的加密算法和壓縮算法也不一樣)。實際上,通過加密或壓縮的二進制數據塊中,會有好幾層可執行代碼。sass
在後面的文章中,咱們詳細地說明了這些組件。
原文件名: 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的攻擊目標有不少重合的地方.伊朗核設施和一些工控企業始終是他們覬覦的目標.
對一家網絡安全公司來講,認可系統被入侵是一件不可想象的事情,可是對卡巴斯基來講不是這樣的,由於咱們秉承公開透明的原則,基於對用戶安全的考量,咱們選擇公佈了這次事件的調查結果.---|||||||||---|||||||||爲了用戶的信任 咱們會戰鬥到底。