勒索軟件最新趨勢(shì)——使用NSIS安裝程序逃避檢測(cè)。惡意軟件家族在不斷尋求隱藏代碼、阻止復(fù)制及逃避檢測(cè)的新方法。勒索軟件遞送的最新趨勢(shì)是使用帶加密有效載荷的Nullsoft腳本安裝系統(tǒng)(NSIS)。很多知名勒索軟件均采用該技術(shù)，比如Cerber、Locky、Teerac、Crysis、CryptoWall及CTB-Locker。
我們很少看到多個(gè)家族一直使用相同的打包方法。在本文所述情況中，有效載荷依賴安裝程序來執(zhí)行，解密的惡意軟件有效載荷不會(huì)接觸磁盤。使用NSIS打包方法使我們較難采用批量采集技術(shù)采集和發(fā)現(xiàn)惡意軟件。傳入的樣本可能只包含負(fù)責(zé)解壓縮的DLL，不包含加密的有效載荷或NSIS安裝程序。在本文中，我們將看看該種遞送機(jī)制如何運(yùn)作，為何使用這樣的機(jī)制，及這種機(jī)制對(duì)試圖研究惡意軟件的研究人員提出的挑戰(zhàn)。
這種遞送方法為何很流行?
該攻擊途徑以垃圾郵件下載器的有效載荷為起始。不知情的用戶打開包含惡意JavaScript或Word文檔的電子郵件附件。惡意安裝程序(檢測(cè)為NSIS / ObfusRansom。*)在%TEMP%中下載、啟動(dòng)并釋放一個(gè)DLL文件和一個(gè)加密數(shù)據(jù)文件。安裝程序隨后加載負(fù)責(zé)解密和執(zhí)行加密有效載荷的DLL。解包器DLL從NSIS安裝程序的導(dǎo)入地址表中竊取五個(gè)API。然后，DLL將加密文件讀入內(nèi)存，轉(zhuǎn)到文件中的隨機(jī)硬編碼偏移量，并解密解壓縮、寫入內(nèi)存及執(zhí)行加密惡意軟件有效載荷所需的其他API。這種依賴性使得靜態(tài)分析、仿真及復(fù)制變得更加困難，并產(chǎn)生了一種解密勒索軟件不接觸磁盤的遞送系統(tǒng)。在分析這些打包器時(shí)，我們未發(fā)現(xiàn)提交到任何知名樣品處理網(wǎng)站(比如VirusTotal)的解密的惡意軟件可執(zhí)行的樣本。
打包器執(zhí)行
以上流程圖總結(jié)了該打包器的基本執(zhí)行流程，發(fā)現(xiàn)各種水平的混淆均采用該流程，但功能上等同。我們選擇了一個(gè)混淆程度較低的樣本(MD5: F9AE740F62811D2FB638952A71EF6F72)，以方便技術(shù)解釋。
大多數(shù)版本還嘗試一定的代碼流混淆來延遲靜態(tài)分析。我們觀察到的兩種常見的代碼流混淆方法是結(jié)合可報(bào)警Sleep調(diào)用的QueueUserAPC：
或結(jié)合除零的結(jié)構(gòu)化異常處理：
這些方法均不是該遞送方法所獨(dú)有，在執(zhí)行靜態(tài)分析時(shí)也不是很難看到。一旦進(jìn)入主函數(shù)，惡意軟件首先進(jìn)行反混淆三個(gè)亂碼字符串。在某些情況下，在樣本上運(yùn)行“字符串”即可查看，如以下截圖所示：
大多數(shù)情況下，這些字符串包含“Kernel32”( Microsoft API調(diào)用)和由安裝程序釋放的加密文件的名稱。以下是正在解密的Kernel32的樣本。所有這三個(gè)字符串都以類似的方式進(jìn)行反混淆。
反混淆算法：
混淆字符串內(nèi)存：
反混淆字符串內(nèi)存：
字符串被反混淆后，惡意軟件接下來會(huì)創(chuàng)建一個(gè)指向安裝程序內(nèi)存空間的指針，并保存FirstThunk和OriginalFirstThunk的偏移量(“thunk”是一個(gè)自動(dòng)生成的代碼段，用于協(xié)助調(diào)用另一個(gè)子例程)。本質(zhì)上，OriginalFirstThunk是導(dǎo)入名稱表，F(xiàn)irstThunk是導(dǎo)入地址表。
解包器DLL然后遍歷OriginalFirstThunk，查找直接從相應(yīng)的FirstThunk條目竊取和保存其地址所需的五個(gè)API的名稱。該循環(huán)使用一些基于字符串大小和字母位置的基本邏輯來準(zhǔn)確獲取其所需的API。
GetProcAddress：
GetModuleHandle：
GetFileSize：
GlobalAlloc：
ReadFile：
這五個(gè)竊取的API用于將加密的文件讀入內(nèi)存，然后在其中解密其所需的第二層API。
打包器接下來準(zhǔn)備有效載荷。當(dāng)父NSIS安裝程序運(yùn)行時(shí)，其釋放的其中一個(gè)文件是加密和壓縮的文件。該文件是打包器正準(zhǔn)備啟動(dòng)的惡意軟件的主要有效載荷。正如我們提到的，我們的研究表明，該有效載荷可以是各種惡意軟件(包括若干勒索軟件變體)的有效載荷。
惡意軟件首先使用CreateFile API打開有效載荷的文件句柄。有效載荷名稱和擴(kuò)展名是已經(jīng)反混淆的字符串之一。
ECX值(文件名)：
惡意軟件獲取解密和讀取文件所需的文件大小。然后使用文件大小為將要讀入內(nèi)存的文件新分配一塊內(nèi)存：
加密的文件現(xiàn)已存儲(chǔ)在內(nèi)存中，惡意軟件開始通過解密API的名稱來處理這個(gè)文件。我們研究的每個(gè)樣本都具有API名稱和硬編碼在樣本中的解密密鑰的位置。我們還發(fā)現(xiàn)，這兩項(xiàng)通常可以在文件的第一個(gè)0x1FFF字節(jié)中找到。API字符串的解密使用簡(jiǎn)單的算法在一個(gè)循環(huán)中完成。
加密API：
該代碼混淆程度可能極高(視樣本而定)。我們反編譯了該樣本，并將此循環(huán)中使用的解密算法簡(jiǎn)化為了如下所示的相關(guān)行：
do{
api = *(api_base + counter);
key = ~*(counter + randomoffset);
*(api_base + counter) = api & key | ~key & ~api;
++counter;
}while ( counter
我們可以看到此處的“加密”是非常基礎(chǔ)的。我們發(fā)現(xiàn)的一些樣本具有稍微不同的解密算法，但都是對(duì)存儲(chǔ)的密鑰的非常基本的算術(shù)運(yùn)算。該函數(shù)對(duì)密鑰和加密值進(jìn)行按位AND一次，然后再對(duì)這些值NOTed。然后對(duì)結(jié)果按位ORed。在我們的樣本組中，被解密的字符串總是相同的，因此迭代次數(shù)保持恒定，為0x14A (330)。
解密的API：
下一個(gè)主要任務(wù)是有效載荷本身的解密。下圖顯示了加密有效載荷的內(nèi)存位置：
整個(gè)文件不經(jīng)過解密流程(僅可執(zhí)行文件本身經(jīng)過)。惡意軟件使用從GetFileSize收集的大小和硬編碼值來確定要解密的字節(jié)數(shù)。
我們樣本中有效載荷的解密算法與API解密算法相同。
基于循環(huán)結(jié)束時(shí)間，與API解密流程有一個(gè)小的明顯不同之處。如上所示，ebx保存要解密的字節(jié)數(shù)，而現(xiàn)在充當(dāng)計(jì)數(shù)器。
解密的有效載荷：
文件和API現(xiàn)已解密，隨后惡意軟件解壓縮其有效載荷。惡意軟件作者使用標(biāo)準(zhǔn)Windows API執(zhí)行壓縮，并在解密后通過調(diào)用RtlDecompressBuffer再次使用。在這個(gè)API中，推送到棧上的“2”表示使用的壓縮類型。根據(jù)Microsoft文檔，2代表LZ解壓縮。
有效載荷在內(nèi)存中完全解密和解壓縮后，我們現(xiàn)在可以使用Windbg的“.writemem”函數(shù)轉(zhuǎn)儲(chǔ)功能完整的獨(dú)立有效載荷。這讓我們可以研究有效載荷并確定其是否是已知的勒索軟件變體，但是，這些具體的有效載荷尚未被常見的惡意軟件研究網(wǎng)站觀察到。
現(xiàn)在需要進(jìn)行設(shè)置，以在內(nèi)存中執(zhí)行此有效載荷。解密的有效載荷從不接觸磁盤，有助于降低被檢測(cè)到的可能性。第一步是調(diào)用處于掛起狀態(tài)的CreateProcess。惡意軟件在此進(jìn)程中執(zhí)行：
CreateProcess API后，惡意軟件使用標(biāo)準(zhǔn)的進(jìn)程空白技術(shù)。在準(zhǔn)備將其有效載荷寫入新線程過程中使用了VirtualAlloc、GetThreadContext、ReadProcessMemory及NtUnmapViewofSection。WriteProcessMemory將未加密的有效載荷復(fù)制到新線程中。接下來一個(gè)Sleep和ResumeThread調(diào)用啟動(dòng)線程。線程啟動(dòng)后，惡意軟件立即終止父線程。
總結(jié)
這些樣本的核心功能非常簡(jiǎn)單，未展現(xiàn)任何新的行為，但遞送方法提出了一個(gè)新的有意思的挑戰(zhàn)。在帶加密有效載荷的NSIS安裝程序中遞送勒索軟件已被證明是遞送各種惡意軟件的獨(dú)特而有效的方法。目前，已研究的所有樣本都只包含勒索軟件的變體，但我們可以猜測(cè)，其他家族的惡意軟件也在使用這種技術(shù)。我們已經(jīng)觀察到了廣泛的反仿真方法、強(qiáng)的代碼混淆技術(shù)及硬編碼值的差異。字段和API所用的加密通常非常弱，并不是逆向或檢測(cè)的主要挑戰(zhàn)。原因很可能是一個(gè)威脅實(shí)施者在分發(fā)多種形式的勒索軟件，或者是多個(gè)威脅實(shí)施者在使用相同的組來分發(fā)其勒索軟件。
| 
