近期，火絨安全實(shí)驗(yàn)室收到用戶反饋稱自己下載的 Telegram 漢化文件安裝后造成系統(tǒng)異常，火絨安全工程師第一時(shí)間為用戶提供技術(shù)支持，提取樣本并進(jìn)行分析。分析過程中發(fā)現(xiàn)該程序在對 Telegram 程序進(jìn)行漢化的同時(shí)還 “悄悄” 釋放惡意后門文件，執(zhí)行遠(yuǎn)控操作，危害極大。目前，火絨安全產(chǎn)品可對上述病毒進(jìn)行攔截查殺，請廣大用戶及時(shí)更新病毒庫以提高防御能力。
樣本執(zhí)行流程圖如下所示：
在此，火絨工程師建議大家在下載軟件時(shí)，盡量選擇官方網(wǎng)站或正規(guī)可信的應(yīng)用商店，同時(shí)安裝可靠的安全軟件保護(hù)設(shè)備免受惡意軟件和病毒的侵害。目前，火絨 6.0 已上線公測，在沿襲核心功能的基礎(chǔ)上，專注終端安全，精細(xì)化查殺，多重技術(shù)深入布局，安全防護(hù)再次升級；歡迎大家前往火絨官方網(wǎng)站下載體驗(yàn)。
一、樣本分析
起始漢化安裝包是一個(gè)捆綁了惡意文件的 exe 程序，附帶 vmp 殼干擾分析：
雙擊運(yùn)行程序時(shí)，其會先執(zhí)行正常的 telegram 漢化操作，鏈接到正常 telegram 程序并改變界面語言：
但在執(zhí)行正常操作的同時(shí)，會在內(nèi)存中解密出第一階段 payload ，其為一個(gè)惡意 dll，用于在內(nèi)存中加載執(zhí)行：
Payload1：加載通用.dll
從內(nèi)存中 dump 出 dll 進(jìn)行分析，其名稱為 “加載通用.dll”。有一個(gè) Hello 的導(dǎo)出函數(shù)，但不執(zhí)行任何操作，所有操作都在 DllMain 中進(jìn)行：
該 dll 以易語言編寫并由黑月編譯器編譯，特征字符串如下：
在執(zhí)行過程中會先進(jìn)行一些檢測操作，通過判斷 SxIn.dll 是否存在來檢測 360 的虛擬沙盒。檢查 SystemTray_Main 的窗口屬性是為了避免重復(fù)操作，因?yàn)樵诤竺娴牟僮髦袝袑⒃摯翱趯傩栽O(shè)置為隱藏的代碼：
隨后開始初始URL部分，計(jì)算文件自身 MD5 并獲取前 16 字節(jié)部分作為URL路徑進(jìn)行拼接，并生成 FPTOKEN 用于后續(xù) http 通訊：
通信相關(guān)的函數(shù)是通過 WinHTTP 的 COM 對象接口來調(diào)的，數(shù)據(jù)傳輸時(shí)使用的域名是 http://taobc.tv ，利用前面生成的 URL 路徑及FPTOKEN 以驗(yàn)證請求的有效性：
接收到的數(shù)據(jù)為加密數(shù)據(jù)，如下圖所示：
在接收到回傳的通信數(shù)據(jù)后，dll 會獲取多個(gè)系統(tǒng)特定位置路徑，作為后續(xù)投放第二階段 Payload 使用：
隨后通過 ResponseBody 字段來提取加密部分?jǐn)?shù)據(jù)，并解密出新的 PE 文件：
第二階段 payload 下發(fā)的路徑選在 Videos 目錄，dll 會創(chuàng)建 VSTELEM 文件夾，并繼續(xù)創(chuàng)建隨機(jī)文件夾用以投放第二階段載荷：
通過在循環(huán)中讀取并定位解密數(shù)據(jù)中的 PE 文件，陸續(xù)投放 rzrue.exe（隨機(jī)文件名，與文件夾同名）、Language.dll、update.dll 到前面指定的目錄中：
其中，如果檢測到文件不存在的話，就會連接第二個(gè) C2 進(jìn)行告知：
完成前面的文件投放后，dll 還會接著以 SYSTEM_START.lnk 快捷鍵的方式投放到開機(jī)啟動目錄中實(shí)現(xiàn)持久化：
隨后創(chuàng)建進(jìn)程，執(zhí)行下落的 rzrue.exe 文件并等待線程執(zhí)行，如果進(jìn)程執(zhí)行正常，就會更改前面提到的 SystemTray_Main 窗口屬性，用以避免重復(fù)操作：
如果 WaitForSingleObject 返回 WAIT_TIMEOUT 超時(shí)，同樣會連接新的 C2 進(jìn)行告知：
payload2
釋放的文件中 rzrue.exe 是白文件，用于加載同目錄下的 Language.dll 并調(diào)用其中導(dǎo)出函數(shù) LangDLLMain 和 SetRegPath，但實(shí)際上并沒有 SetRegPath 導(dǎo)出函數(shù)，關(guān)鍵操作都在 DllMain 中：
被加載的 Language.dll 同樣由 vmp 加密來干擾分析：
Language.dll 被加載后會讀取同目錄下的 Update.log，Update.log 是一個(gè)加密的字節(jié)碼文件，其最終會被解密成 dll 并在內(nèi)存中加載執(zhí)行：
XTFG110.dll
由 Update.log 解密出來的 dll 名為 XTFG110.dll，只有一個(gè)導(dǎo)出函數(shù) “Fu*ck”。其中 DllMain 函數(shù)主要負(fù)責(zé)初始化操作，F(xiàn)u*ck 導(dǎo)出函數(shù)主要負(fù)責(zé)通信操作：
XTFG110.dll 同樣是易語言編寫：
在 DllMain 中，先初始化要連接的 C2 及端口等數(shù)據(jù)：
隨后在 C:\ProgramData 目錄下創(chuàng)建 Lexicon 目錄，并在其中創(chuàng)建相關(guān)文件夾，猜測是用于后續(xù)控制過程中的配置寫入以及起到標(biāo)識操作已完成的作用：
將執(zhí)行目錄設(shè)置為當(dāng)前路徑，方便后續(xù)操作：
接著該 dll 會根據(jù)預(yù)設(shè)的標(biāo)志執(zhí)行指定的操作，這些操作包括休眠，文件創(chuàng)建，進(jìn)程注入等：
其中進(jìn)程注入操作依舊是將 Update.log 解密后（該 dll 自身）寫入到其它進(jìn)程內(nèi)存中繼續(xù)執(zhí)行：
最后掛鉤鍵盤事件，監(jiān)聽鍵盤記錄：
導(dǎo)出函數(shù)執(zhí)行
導(dǎo)數(shù)函數(shù) Fu*ck 是指定執(zhí)行的，在前面 DllMain 初始化的文件和域名基礎(chǔ)上，主要執(zhí)行通信部分的操作，獲取系統(tǒng)信息進(jìn)行傳輸并接收 C2 的下一步指令：
系統(tǒng)信息收集：
在接收數(shù)據(jù)前，該函數(shù)會先收集系統(tǒng)信息進(jìn)行傳輸，包括設(shè)備名稱，頻率等：
并且函數(shù)還會檢查上一階段文件存在情況，做好記錄：
最后函數(shù)會收集系統(tǒng)相關(guān)注冊表及計(jì)劃任務(wù)的存在情況：
對于收集到的信息，進(jìn)行整理后會以加密的形式進(jìn)行發(fā)送：
傳輸數(shù)據(jù)如下圖所示：
數(shù)據(jù)接收：
在前面將收集到的系統(tǒng)數(shù)據(jù)發(fā)送后，函數(shù)進(jìn)入新的循環(huán)中開始接受 C2 數(shù)據(jù)。接收數(shù)據(jù)具體實(shí)現(xiàn)如下：第一次獲取數(shù)據(jù)時(shí)，其會先定位回傳數(shù)據(jù)的第 7 個(gè)字節(jié)（從 0 開始算），以此作為新緩沖區(qū)的長度進(jìn)行第二次數(shù)據(jù)獲?。?/p>
對于接收的所有數(shù)據(jù)同樣需要解密后才能進(jìn)行操作，解密邏輯同前面加密一樣：
然后進(jìn)入數(shù)據(jù)處理函數(shù)中，其中第二次獲取數(shù)據(jù)的第一字節(jié)會作為判斷值來決定分發(fā)情況。根據(jù)不同的值，跳轉(zhuǎn)到不同的執(zhí)行分支中，其中包括系統(tǒng)信息獲取、進(jìn)程注入、下發(fā)插件等等，以此實(shí)現(xiàn)對受害者主機(jī)的完全控制，這里不再一一分析：
二、附錄
C&C：
HASH：
絡(luò)服務(wù)商&site=cntaobao&s=1&charset=utf-8)
