「隱蜂」來襲：全球首例Bootkit級挖礦殭屍網路木馬

來自專欄漁村安全4 人贊了文章

前言

近兩年比特幣、以太幣、門羅幣等數字貨幣正經歷著全球熱潮，挖礦類病毒木馬的感染量也隨著虛擬貨幣的價格攀升逐步上漲，黑產團伙的商業嗅覺和行動力令人驚嘆，類似「CoinHive」這種網頁挖礦變現平台層出不窮，數百萬級的網站被黑產團伙利用web漏洞植入挖礦代碼。

在去年我們可以看到各類挖礦木馬異常活躍，從利用「永恆之藍」漏洞傳播到伺服器、資料庫弱口令爆破，從Struts2、Weblogic、Jboss等各大Web框架漏洞到IE/Flash0day掛馬傳播，甚至包括被頻繁曝光漏洞的路由器、攝像頭等嵌入式設備都被黑產團伙盯上，各類挖礦木馬可以說一直活躍在全球網路安全攻擊事件的最前線。

在挖礦暴利的引誘驅使下，之前部分用於傳播垃圾郵件、敲詐者的老牌殭屍網路都開始紛紛轉型加入挖礦大軍，更有甚者，個別傳統正牌軟體廠商也都開始沉淪墮落，從我們去年挖掘曝光的「看看影音雲控挖礦」、「電信天翼客戶端挖礦後門」等安全事件中就可以略窺一二，不誇張地說，2017年堪稱挖礦類木馬病毒的爆發元年。

近期，金山毒霸安全實驗室監控到部分用戶系統存在疑似挖礦木馬活動的威脅線索。經過我們的安全研究員的逐層溯源分析，一個已經成型並走向活躍的Bootkit級挖礦殭屍網路被揭開神秘面紗，Bootkit與挖礦木馬的融合也將碰撞出一些不一樣的火花。

本次捕獲的Bootkit樣本從框架設計到代碼細節處理上都非常完善，在隱蔽性、兼容穩定性、反分析對抗等各方面都達到了一個全新高度，病毒代碼的複雜程度、專業程度也為近年所罕見。

從樣本模塊的字元串信息中我們發現該Bootkit的內部項目代號為「Mellifera(蜜蜂)」，所以本次的Bootkit木馬被命名為「隱蜂」，概括來說，「隱蜂」Bootkit木馬的技術特點主要體現在以下幾個方面:

1、對抗分析檢測，隱蔽性很強。

在隱蔽性上「隱蜂」Bootkit木馬近乎極致，

內核模塊的掛鉤地址都通過NT內核模塊代碼間隙的Shellcode中轉實現隱藏；

兩套磁碟驅動劫持過濾機制互相守護；

通過鏡像回調檢測pdb、簽名特徵屏蔽部分安全軟體；

針對PCHunter、PowerTool等常見的ARK工具，掛鉤其核心驅動過濾IRP請求的返回數據，過濾掉自身註冊的各類回調地址；

在木馬的R3層工作模塊中，病毒也會通過腳本實時檢測當前運行環境，一旦發現ARK工具、抓包軟體或者安全軟體，甚至是任務管理器，病毒都會立即結束挖礦活動，小心翼翼地躲藏起來；

在C&C通信升級方面，採用SSTP加密協議，並且使用DGA動態生成。除了內存中的shellcode幾乎沒有太多特徵線索，即便是專業安全人員，檢測分析「隱蜂」Bootkit都是一件很有挑戰性的工作。

2、架構設計靈活，複雜度專業度很高。

從我們的分析過程中看，不管是整體框架的設計還是細節處理都非常專業，比如內核模塊基礎機制設計方面，多種回調介面非常靈活，而且在內核層支持擴展模塊的動態載入卸載，方便隨時擴充內核功能；

還有用於存儲病毒模塊和配置信息的MRFS自定義文件系統和NE插件格式；再比如R3層集成的LUA腳本機制增加了病毒靈活性，病毒還會根據機器配置和使用場景動態調整挖礦資源佔用參數；

最直觀的感受，我們從「隱蜂」病毒中解壓出來的各類內核模塊、R3插件以及配置文件多達50+,病毒代碼結構的複雜程度可見一斑。

3、系統兼任穩定性很好。

系統兼容性一直都是衡量Bootkit技術的重要指標，完成一款兼容度極高的Bootkit是非常有技術挑戰性的一件事情。

從我們的分析過程來看，「隱蜂」在系統引導過程中的掛鉤時機選擇、掛鉤點特徵搜尋和代碼細節處理上都非常完善，支持主流windows操作系統版本，同時兼容X86/X64架構。「隱蜂」Boot劫持代碼中也可以看到一些Bootkit前輩的身影，堪稱後輩中的集大成者。

從我們的監控數據來看，本次的「隱蜂」Bootkit木馬變種從3月初開始測試傳播，得益於其強悍的隱蔽性和對抗分析能力，到至今的三個多月都不曾被外界發現曝光。

病毒的項目版本號也從0.1迭代至目前的1.x，在經歷了幾輪網頁掛馬和流氓捆綁的傳播小高峰後，該殭屍網路已經逐漸成形，預估目前全網的感染用戶50w+。

病毒母體在傳播渠道和技術利用上也都非常有特點，通過白利用和系統漏洞組合穿透主流安全軟體的防禦體系，後續有機會我們會繼續展開分享。

順便說點題外話，「隱蜂」Bootkit木馬的攻擊活動並不是首次被發現，在2017年活躍過一段時間，早期變種的功能模塊相對簡單，主要用於劫持瀏覽器導航主頁，友商安全團隊曾經捕獲到並命名為「隱魂」木馬，稱之為「史上反偵察力最強木馬」。

但是比較惋惜的是分析報告中沒有任何IOC信息，並且抹去了幾乎所有可能被外部溯源分析的特徵線索，所以在較長時間內一直沒有被外界熟知，我們也是在本文發布前對近兩年的Bootkit類木馬進行橫向對比時意外發現，出於尊重，我們延續傳統將此Bootkit變種命名為「隱蜂」。

對抗網路黑產任重而道遠，單個團隊的力量總是有限的，在基礎安全情報的開放共享方面，希望我們都可以做地更多一點，否則很多披露報告就失去了它本來的意義。

本次發現的「隱蜂」Bootkit樣本和相關技術細節會對安全友商開放，可以通過官方郵箱發送郵件和我們聯繫。最後還要感謝下用戶@guying195在分析取證過程中給予的極大支持配合，這樣的用戶對我們來說也是一種莫大幸運。

正文

如上圖，按照Bootkit類木馬傳統的「boot+rootkit+plugin」三層架構，我們也會分為3個章節進行講解，上篇部分主要包含「隱蜂」木馬的「Boot劫持」和「內核Rootkit」兩個關鍵部分。成文倉促難免有疏漏之處，歡迎留言指正。

一、Boot啟動劫持階段

1、MBR引導代碼劫持

「隱蜂」bootkit木馬對MBR引導代碼的感染處理比較有特點，與之前其它MBR類Bootkit不同的是，它通過在正常MBR啟動代碼基礎進行Patch，劫持活動分區表項，打斷原本應該跳轉到PBR（Partition Boot Record）引導系統啟動的正常流程，引導至磁碟末尾的病毒代碼上繼續執行。

劫持分區表後，病毒從磁碟末尾病毒代碼起始處讀取1個扇區到0x7C00，校驗扇區末尾是否為0xAA55，通過驗證則繼續下一個步的Loader代碼，反之則恢復BP指針，保證系統正常引導啟動。

2. BootCode解碼與載入布局

如上段所訴，loader代碼被拷貝到0x7C00繼續執行，這部分loader代碼主要負責將磁碟末尾的BootCode代碼數據拷貝到內存進行解碼、載入布局和參數填充，並且恢復7C00處的MBR引導代碼備用。

完成這些以後病毒代碼流程就進入bootkit經典核心部分，從掛鉤INT13中斷直到最終注入NT內核。解碼和載入布局的這部分代碼不涉及技術核心部分，流程略顯瑣碎，不再贅述細節，關鍵步驟和內存布局如下圖所示：

3. INT13 掛鉤

掛鉤INT13中斷服務是bootkit使用的經典技巧之一，掛鉤成功以後可以在PBR讀取系統引導程序(NTLDR/ BootMgr)時獲得一個合適的時機進行特徵搜索和Patch。「隱蜂」在這部分的處理上並沒有太大差異，如下圖:

INT13的掛鉤代碼中搜索和Patch特徵碼主要包括以下幾點：

1） 搜索特徵碼「83 C4 02 E9 00 00 E9 FD FF，主要針對XP系統的Ntldr模塊，針對此處的Patch主要為了繞過代碼完整性校驗機制。

2） 搜索特徵碼「8B F0 85 F6 74 21/22 80 3D」，主要針對XP系統的OS Loader模塊，通過Hook跳轉到後續保護模式代碼。

3） 搜索特徵碼「8A 46 ?? 98 3D 00 00 75 03 E9 03 00 E9 35 00」，主要針對VISTA+版本系統的BootMgr模塊，通過Hook跳轉到後續保護模式代碼。

4. BOOTMGR掛鉤

前段中INT13的掛鉤代碼中針對BootMgr(16位)的Hook對X86和X64做了兼容處理，以Win7 X86系統為例，成功掛鉤BootMgr(16位)後效果如下:

BootMgr(16位)的掛鉤觸發以後，啟動流程式控制制權再次被病毒代碼接手，隨後從00400000h基址處定位代碼段，通過內嵌的微型反彙編引擎對特徵碼進行遞進搜索，繼續對BootMgr(32位)的關鍵位置進行掛鉤，首次被掛鉤的函數為ImgpLoadPEImage! LdrRelocateImageWithBias，特徵碼搜索過程如下:

病毒代碼對LdrRelocateImageWithBias被調用處的call地址進行Patch，將代碼流程劫持到9AA7Eh；通過對BootMgr(32位)的模塊功能和掛鉤點的調用堆棧分析，就不難發現病毒選定此處作為掛鉤點的原因：

5. WINLOAD.EXE掛鉤

在對winload.exe的掛鉤處理上，依舊選用了ImgpLoadPEImage! LdrRelocateImageWithBias這個調用點，特徵碼搜索過程都是相同的，另外針對winload架構不同分別處理，保證兼容X86和X64系統。通過此處的掛鉤，病毒代碼在winload.exe載入系統內核ntoskrnl.exe時可以再次截獲代碼執行權。此處細節不再贅述，如下圖:

如上圖所示，當winload!LdrRelocateImageWithBias處的掛鉤代碼被觸發時，流程被引導到病毒函數9AA8Ch處，在這裡病毒代碼進行二次掛鉤跳轉，掛鉤函數保存了當前模塊的鏡像基址，並通過覆寫當前函數棧內容，等winload!LdrRelocateImageWithBias原函數執行完再次獲取觸發控制，完成調用後hook。

6. ntoskrnl.exe掛鉤

上述掛鉤點觸發以後，病毒代碼被引導到9AA9Ah函數處，開始對NT內核模塊ntoskrnl.exe進行掛鉤。首先恢復winload!LdrRelocateImageWithBias調用返回地址，保證掛鉤代碼執行完以後返回正常流程；

然後病毒代碼開始尋找ntoskrnl.exe的INIT區段，然後通過函數交叉引用和指令參數字元串特徵定位到IoInitSystem!IopInitializeBootDrivers調用指令地址，在尋找到的區段間隙處拷貝shellcode，最後填充API表、設置參數並掛鉤IoInitSystem!IopInitializeBootDrivers調用。細節過程入下圖:

當NT內核調用IoInitSystem!IopInitializeBootDrivers時，之前區段縫隙填充的shellcode被觸發，這裡病毒代碼首先將IopInitializeBootDrivers原地址填寫到堆棧，保證原函數正常調用；然後關閉防寫恢復該處的掛鉤，最後將下一階段的hook函數地址填寫堆棧，這樣在BootDrivers初始化完畢以後，再次拿到內核代碼控制權，最後填充原函數返回地址，載入執行後續shellcode。過程如下圖:

從上圖末尾的shellcode開始，病毒代碼就開始進入bootkit內核驅動模塊的載入過程，這部分代碼包括三層的shellcode跳轉處理，最終從磁碟末尾的讀取後續核心模塊的代碼數據，解密解壓處理後得到自定義文件系統(Mixed ROMFS)鏡像，解析出內核loader模塊「/bin/i386/bootmgr」(變異PE)裝載並執行。限於篇幅這裡不再贅述細節，三層shellcode跳轉過程描述如下圖：

至此「隱蜂」病毒的「Boot啟動劫持階段」結束，病毒代碼從MBR劫持一路掛鉤跳轉直到進入到內核「Rootkit」階段，後續將開始載入真正的內核模塊，完成Ring3插件主模塊注入、病毒磁碟數據保護回寫以及殺軟ARK對抗等操作。

二、NT內核Rootkit階段

在前段「Boot啟動劫持階段」結尾，我們提到了病毒代碼使用了「Mixed ROMFS」自定義文件系統(以下簡稱MRFS)來存儲配置信息和插件模塊，而且插件模塊也使用了從PE格式變異而來的NE格式，從這些精心設計的系統格式也可以從側面窺探出「隱蜂」病毒幕後團伙的專業程度。這兩類文件結構對我們後續的分析過程比較重要，在最後的Ring3層工作插件中都會多次使用到，所以在「NT內核Rootkit階段」真正開始之前，我們先來簡單了解下這兩種文件格式。

1. 文件系統(MixedROMFS)文件結構與NE插件格式

「隱蜂」病毒使用的「MRFS」類似於linux系統下常見的ROMFS等文件系統，但目前沒有找到公開資料描述過「MRFS」，所以我們暫時認定「MRFS」是病毒作者自定義的一套文件系統格式。從病毒的文件解析代碼中反推出的關鍵欄位和結構如下圖:

「MRFS」的文件結構主要包括鏡像頭、文件信息頭和文件數據三大部分，文件信息頭是一個層級結構，主要包含了文件路徑層級信息和對應文件塊偏移信息。這個FS鏡像包含了後續所有內核模塊、配置信息和注入R3的主模塊等文件，文件目錄結構解析結果如下:

另外的「NE」模塊插件格式相對簡單，可以看作一種變異的PE文件格式，病毒作者抹去了PE文件的DOS頭和NT頭標記、區段名稱等信息，進行修復以後即可還原為標準PE文件。在「NE」模塊插件的代碼入口或者外層調用處，一般通過導入表IAT和重定位表修復填充實現動態載入。

2. 「bootmgr」解析載入「kernel」核心模塊

「/bin/i386/bootmgr」模塊是一個loader模塊，主要負責解析載入真正的內核核心模塊「/bin/i386/ kernel」，填充重定位表和IAT表完成自載入過程，隨後從「MRFS」鏡像中解析出kernel文件，進行重定位和導入表處理後直接調用。過程如下圖:

3. 核心模塊「kernel」

「kernel」是「隱蜂」病毒Rookit階段的核心模塊，從模塊整體的設計架構中，可以看出「隱蜂」病毒作者在Windows內核方面的具備非常豐富的開發經驗。

病毒作者在「kernel」模塊中設計提供了鏡像通知回調、磁碟過濾回調，內核擴展模塊載入等一系列基礎框架機制，並導出相關的服務介面，最終完成病毒磁碟數據回防寫、殺軟ARK對抗以及R3插件主模塊的注入等關鍵操作。

另外內核擴展插件機制設計也非常靈活，支持動態載入卸載，方便病毒隨時擴展升級內核功能。「kernel」模塊功能比較複雜，部分介面需要結合調用上下文去分析說明，但核心功能可以總結為以下幾個關鍵點：

a、IoCreateDriver創建自定義的核心驅動對象，符號鏈接為隨機GUID，該驅動對象用於導出內核模塊的核心功能給Ring3層進行調用。

比較有特點的是，驅動對象的派遣函數其實是代理中轉函數，通過維護一個鏈表對象，指向自定義的控制派遣函數對象，這樣的設計可能是為了後期擴展更靈活。這部分的介面功能比較繁雜，後續我們會在R3調用處結合上下文進行說明。

b、PsSetLoadImageNotifyRoutine註冊鏡像載入通知回調，與普通的鏡像回調函數不同的是，病毒將一段shellcode代碼拷貝到NT內核模塊代碼段末尾空隙，由這段shellcode引導真正的回調函數，這樣將回調函數地址隱藏到NT內核鏡像中；

另外此處的回調函數同樣是一個代理中轉函數，維護一個鏡像通知回調函數數組，這樣可以在系統原有機制外實現靈活擴展，導出介面給其他內核擴展模塊使用；

最後向鏈表中添加了負責注入Ring3的鏡像載入回調函數，在選擇合適時機創建WorkerRoutine並通過APC機制注入svchost進程。

病毒代碼會映射目標地址空間並預載入Loader模塊「stub.bin」，填充載入關鍵參數，包括「subsystem」（核心模塊）等，最終將病毒流程引導到Ring3層工作階段。後續Ring3層的工作模塊載入和技術細節我們會在下一章中詳細闡述。

c、另外一個重要功能就是磁碟對象劫持相關對抗機制，主要用於保護病毒MBR和存放病毒代碼數據的磁碟扇區，並在關機時機進行回寫感染。

病毒作者在這裡巧妙地設計了兩套劫持過濾機制，並且在這兩套劫持的派遣函數中互相守護，摘除掉一方的劫持掛鉤會被另外一處劫持重新恢復。

一類是「磁碟對象劫持」技術，申請內存構造虛假設備/驅動對象並填充關鍵欄位結構，搜尋磁碟上層設備對象擴展，再將其保存下層對象的成員填充為前面構造的虛假設備對象，這樣就可以過濾磁碟驅動發送的所有IRP請求，劫持派遣函數中除了對「IRP_MJ_SCSI」請求進行過濾處理外，還有針對「IRP_MJ_POWER」（關機通知）的處理，這裡主要是提供介面給其他內核擴展模塊和R3，方便對病毒MBR相關代碼進行關機回寫；

另外一類，劫持磁碟埠驅動(ATAPI)的「IRP_MJ_SCSI」派遣函數，與鏡像載入通知回調的機制類似，這裡同樣將劫持函數的shellcode頭拷貝到NT內核代碼段末尾實現隱藏，並且也是通過代理函數中轉鏈表實現靈活擴展。

d、載入內核擴展模塊「guard.kext」和「mprot.kext」完成內核對抗擴展功能。這裡需要首先說明的是，在內核擴展模塊載入機制中，「kernel」模塊導出了一個比較重要的功能擴展介面「mpsi.dll」。

這個介面主要封裝了前面「kernel」模塊實現的鏡像回調、磁碟過濾等機制，一共22個導出功能函數，內核擴展模塊kext以序號導入的形式引入「mpsi.dll」，在動態載入kext擴展模塊處理IAT的時候進行了特殊處理，將所有「mpsi.dll」的導入函數引導到「kernel」模塊的一個代理中轉函數上。

「guard.kext」 內核擴展模塊對應的配置文件為" /etc/register.js"，該模塊通過前面「kernel」模塊提供的介面註冊鏡像載入通知回調，對載入的驅動鏡像進行PDB名稱、數字簽名、Hash等特徵過濾，滿足特徵的則patch驅動文件入口點，直接返回錯誤狀態碼STATUS_INSUFFICIENT_RESOURCES，實現對抗安全軟體與ARK工具類軟體。

除了上述直接對抗安全軟體和ARK工具驅動載入外，病毒還會對載入鏡像的PDB、原始文件名等特徵計算Hash匹配。

我們分析認為主要是針對主流的ARK工具，病毒會掛鉤ARK工具驅動中IofCompleteRequest等關鍵函數，對ARK工具交互的IRP請求進行過濾，劫持隱藏之前「kernel」模塊註冊的鏡像載入回調和磁碟驅動派遣劫持等函數地址，防止專業安全人員通過PcHunter、PowerTool等常見的ARK工具檢測發現異常掛鉤。

另外一個關鍵的內核擴展模塊是「mprot.kext」，其對應的配置文件為"/etc/sandbox.js"，該模塊主要負責保護病毒MBR和磁碟末尾BootCode，通過「kernel」模塊提供的「IRP_MJ_POWER」過濾回調介面註冊保護函數，在系統關機時重新檢查回寫病毒MBR和BootCode。這裡病毒註冊了兩套關機回調函數，一套用於內核擴展自身，一套用於Ring3層觸發保護。

上篇的分析到此暫告一段落，下篇中我們會針對Ring3層的挖礦模塊工作機制展開分析，敬請期待。

附錄(IOC):

升級URL:

sstp://*.http://gatedailymirror.info/upd.pkg

sstp:// *.http://redteamshop.info/upd.pkg

sstp:// *.wefoundsome.xyz/upd.pkg

sstp:// *.http://foundrosysquad.info/upd.pkg

sstp://http://ask.thesupporthelp.com:443/mlf_plug.zip.sig

礦池地址:

stratum+tcp://http://data.supportithelp.com:8080

本機構賬號將持續關注和發布各類安全熱點事件，歡迎大家關注我們哦！

想查看更多過往的報告？可以點擊下面哦

我們的知乎文章匯總：點擊查看

我們的微博：漁村安全的微博

我們的微信公眾號：漁村安全