前不久,360安全中心率先發布了MBR木馬——「隱魂」的預警,對木馬入侵過程分析《史上反偵察力最強木馬「隱魂」:撐起色情播放器百萬推廣陷阱》后發現,「隱魂」的反偵察能力極高,堪稱迄今最複雜的MBR木馬。360安全中心隨即對該木馬展開了持續追蹤,本篇是對其篡改主頁的行為詳細介紹。
1 摘要
首先,我們來進一步了解「隱魂」木馬的反偵察能力和複雜性。
(1) 隱蔽性極高:「隱魂」木馬會通過掛鉤磁碟底層驅動實現自我保護,普通的ARK工具或查殺類工具無法深入磁碟底層,難以有效檢測到MBR被修改;同時,應用層代碼在TimerQueue中調度,目前除了利用調試器進行反覆測試外,根本沒有其他方法能檢測該系統觸發機制;另外,內核LoadImage掛鉤代碼在Nt節的空白區域,這部分在未知內存區域執行的代碼也是檢測工具的一大盲區。
(2) 對抗性極強:為了與檢測工具及殺軟對抗,「隱魂」使用簽名和PDB文件名方式,禁止一系列驅動載入,即使載入成功相關功能函數也會被IAT掛鉤。
(3) 兼容性極高:「隱魂」是目前支持系統範圍最廣的MBR木馬,從Windows XP到Win10X64位最新系統的均支持,兼容性遠遠超過2016年開始活躍的暗雲Ⅲ木馬。
其次,我們再來說一下「隱魂」木馬在篡改主頁時是如何清理犯罪現場的。
(1) 聲東擊西:不同於直接在瀏覽器進程中添加參數的劫持方式,「隱魂」為了躲避查殺,採取了結束原瀏覽器進程——創建新的系統進程——再創建新瀏覽器進程的方式繞了個大圈才完成主頁篡改。
(2) 釜底抽薪:「隱魂」會把大多數殺軟的正常掛鉤全部抹掉,使得瀏覽器主頁失去安全類軟體的保護。
接下來,將從WindowsNt系統載入前 (BootKit) 、系統載入后(RootKit)、注入桌面進程explorer
改首頁共三部分對木馬的執行流程進行詳細分析。
2 NT系統載入前
2.1 MBR部分
將自身代碼拷貝到 0×600處執行。
圖1
而後使用int 13 42擴展讀功能讀取0×1個扇區到 0x7c00,
位置是由bp指定的。
圖2
讀取:
圖3
而後跳轉到 0x7c00處繼續執行。
圖4
跳轉:
圖6
這次相同位置連續讀取 0×20個扇區:
圖7
定位位置:
圖8
讀取20個扇區:
圖9
然後將代碼拷貝到 0×101000 大小為0×1400。
圖10
而後跳轉到 0×10100處執行:
圖11
然後預留高端地址0×14 = 20KB頁面 用來存放代碼。
圖12
將自身代碼拷貝到高端地址:
圖13
跳轉到 0x9a400 處執行掛鉤代碼。
圖14
然後掛鉤int13中斷:
圖15
掛鉤后:
圖16
掛鉤處代碼為 0x9a400 + 45 = 0x9a445。
圖17
2.2 Int13掛鉤部分
Int13掛鉤中斷被執行,搜索硬編碼並掛鉤:
圖18
掛鉤函數為:
圖19
掛鉤后函數被修改為:
圖20
2.3 BootMgr部分
當系統控制權交給BootMgr 16位代碼后,
準備轉移給32位代碼執行時掛鉤中斷被執行。
相關函數為:
圖21
跳轉:
然後直接搜0×400000 地址並掛鉤
圖22
從BootMgr PE節信息中搜可執行代碼,自帶反彙編引擎搜索ImgpLoadPEImage對 LdrRelocateImageWithBias的調用,然後Patch對該函數調用。
掛鉤前該處調用為:
圖23
特徵碼為:
圖24
搜到后特徵碼 0xc0000221 及 0x20B后,
找到下一個Call調用機器碼為0xE8且指令長度為5即為搜索成功。
圖25
后掛鉤:
圖27
Winload掛鉤函數為:
圖28
2.4 WinLoad部分
當系統執行到bootmgr!BmpTransferExecution 將控制權轉移給Winload時候,
掛鉤函數HookWinLoad被執行。
先將 LdrRelocateImageWithBias 函數地址放置在堆棧上,等掛鉤Winload函數執行完畢后就
調用LdrRelocateImageWithBias 接著執行原來的流程。
後續的掛鉤執行都是如此,並未恢復原先代碼。
圖29
調用為:
圖30
按系統分別掛鉤:
圖31
然後同樣是搜索ImgpLoadPEImage對 LdrRelocateImageWithBias的調用,然後Patch對該函數調用,該部分代碼同BootMgr一樣。
掛鉤后函數為:
圖32
先將恢復對函數LdrRelocateImageWithBias的調用:
而後將 0x9aa9a函數放置在堆棧上等待被調用:
圖34
LdrRelocateImageWithBias調用完成後 HooNt函數被執行(0x9aa9a):
圖35
先恢復堆棧後續執行流程 將winload!ImgpLoadPEImage+0x67d放置在返回地址處:
圖36
通過反彙編引擎搜調用代碼搜IoInitSystem 對 IopInitializeBootDrivers的調用。
圖37
3 NT系統載入后
3.1 載入ShellCode部分
當系統執行到 Nt 中 IoInitSystem 對IopInitializeBootDrivers調用時候,惡意代碼被執行。
先將函數 IopInitializeBootDrivers 放置堆棧上,然後關閉防寫恢復原始掛鉤處代碼,而後將後續載入木馬代碼函數地址(LoadTheShellCode)放置堆棧上。
圖38
當函數IopInitializeBootDrivers 調用完成後, 再次將Nt正確函數返回地址放置堆棧上。
圖39
而後將ShllCode1代碼映射,大小為0xca0。
圖40
校驗代碼並執行。
3.2 ShellCode1部分
該部分功能為讀取磁碟指定位置代碼並載入ShellCode2。
先獲取相關函數地址,
後讀取磁碟數據檢測完整並獲取大小,大小為0x4a000。
圖41
然後為第二塊ShellCode申請內存大小為 0x4c08。
申請后執行:
圖42
3.3 ShellCode2部分
該部分主要為解壓之前讀取的資源數據並查找載入其中/bin/i386/bootmgr NE文件並載入。
校驗完整性,並解壓數據:
圖43
然後為第三塊NE 格式ShellCode申請空間大小為0x1f00,準備執行,並將資源作為參數傳入。
圖44
3.4 ShellCode3部分
主要為載入 /bin/i386/kernel 到內存並執行,Kenel部分為內核關鍵代碼部分。
圖45
拷貝NE文件資源,大小為0×10380:
圖46
而後幫第四塊ShellCode修正導入表重定位並執行。
圖47
3.5 ShellCode4部分
該部分為內核關鍵代碼,包含注入代碼掛鉤LoadImage 反內核調試代碼。
入口出先斷開內核調試:
圖48
而後讀取磁碟數據並保存:
圖49
創建設備跟應用層交互:
圖50
而後重載內核獲取一些導出符號,佔滿情況下,用於清理掛鉤回調:
圖51
設置LoadImage回調主要後續用於APC注入svchost跟explorer用來修改用戶主頁。
將真正函數地址LoadImageNotify作為參數傳入。
圖52
查找節後面空閑區域,將自身掛鉤代碼拷貝過去。
圖53
拷貝代碼:
圖54
代碼為:
圖55
其中AAAAAAAA 為佔位後續將填入實際地址。
然後載入第五塊ShellCode,並且掛鉤:
圖56
而該掛鉤會反覆被檢測執行:
圖57
掛鉤函數為:
圖58
LoadImage中判斷svchost.exe進程創建:
圖59
如果是svchost.exe進程創建:
圖60
判斷是否為指定的svchost.exe:
圖 61
主要通過命令行方式判斷:
圖62
匹配命令行后準備注入代碼:
圖63
將APC NormalRoutine設置為Ne 入口點 得到執行:
圖64
Exploer注入代碼:
圖65
3.6 ShellCode5部分
該內核塊功能主要為防止被檢出查殺。
獲取簽名公司列表信息:
圖66
代碼:
圖67
而後調用ShellCode4中設置LoadImage回調函數。
圖68
在回調中判斷驅動是否有PDB信息,分三種情況Patch
1 如果沒有PDB符號信息且匹配簽名 則直接Patch入口點。
圖69
2 如果有PDB信息,一些常見的工具,也Patch入口點,如gmer.pdb,Win64AST.pdb。
圖70
3 如果Pdb有 且hash 比對一致則導入表 Hook:
圖71
還會IAT Hook文件操作函數,防止查殺類驅動讀取文件恢復鉤子。
ZwCreateFile:
圖72
IofCallDriver:
圖73
防止文件簇讀取方式:
圖74
獲取文件保護列表函數:
Patch函數:
圖76
圖 77
4 篡改主頁部分
4.1 ShellCode1部分
APC注入Explorer.exe后,入口點修正導入表 ,創建線程並載入改首頁模塊。
圖78
線程函數中申請執行空間,並將代碼拷貝。
圖79
然後修正導入表,重定位:
圖 80
執行入口點函數:
圖81
4.2 ShellCode2部分
初始化系統模塊名字,掛鉤時候使用:
圖82
初始化恢復鉤子列表,發現這些函數一旦被掛鉤就直接恢復。
圖83
將原始代碼備份,並保存到鏈表中,頭部指令最多長度為0×20。
圖84
然後打開首頁頁面地址:
圖 85
其中共享內存區數據為:
圖86
然後枚舉所有載入模塊 IAT掛鉤CreateProcessW函數。
圖87
掛鉤回調函數為:
圖88
主要掛鉤Shell32.dll對CreateProcessW函數調用。而後檢測之前的初始化的系統函數是否被Hook,進行恢復。
圖89
CreateProcessW掛鉤中判斷創建進程是否為瀏覽器列表之一:
圖91
而後創建verclsid.exe 為傀儡進程,修改主頁:
圖92
而後創建傀儡進程:
圖93
將代碼映射到傀儡進程QueueUserAPC APC函數:
圖94
4.3 ShellCode3部分
該部分代碼為QueueUserAPC 注入到 verclsid.exe 中執行。
入口點為從PEB LDR中獲取信息,修正重定位修正導入表:
圖95
然後Patch傀儡進程入口點。
圖96
而後在調用CreateProcessW創建帶有命令行的瀏覽器進程
圖97
圖98
svshost部分
主要為創建TimerQueue中回寫LoadImage回調並回寫MBR:
該部分代碼難以有效檢出。
創建:
圖99
給驅動發送命令寫入:
圖100
5 尾聲
「隱魂」木馬創下了兩周內攻擊量上百萬次的記錄,可謂迄今傳播速度最快的MBR木馬。其高超的反偵察能力及複雜的利用技巧讓不少檢測手段力不從心,如今其攻勢雖然放緩但遠不曾停止,被推廣利益驅使的作者很有可能繼續興風作浪,通過遠程控制的方式實施對個人數據及財物的大規模攻擊。
不過網民們也不用過分擔心,360安全衛士不僅率先對「隱魂」木馬展開了查殺,還可以完美攔截各類MBR頑固木馬的攻擊。目前,360安全中心也正在對「隱魂」木馬進行持續追蹤,如有新成果將第一時間與大家分享。
圖101