臭名昭著的惡意軟件僵尸網(wǎng)絡(luò) Emotet 在 2020 年 10 月底陷入低迷，又在 2020 年 12 月 21 日再次活躍。Emotet 充當惡意軟件的橋頭堡，在失陷主機上安裝其他惡意軟件。目前，觀察到 Emotet 在野分發(fā) TrickBot。立陶宛的國家公共衛(wèi)生中心遭到了 Emotet 的攻擊，Emotet 感染了其內(nèi)部網(wǎng)絡(luò)，并開始下載其他惡意軟件。這導(dǎo)致立陶宛國家公共衛(wèi)生中心暫時禁用了電子郵件系統(tǒng)，直到惡意軟件被從內(nèi)部網(wǎng)絡(luò)中刪除。

[[427452]]

本文將會介紹 Emotet 的新 Loader 并與前期使用的 Loader 進行對比。二者在解壓縮的順序、文件的新屬性和新的混淆方法上存在差異，與此同時還會討論使用的檢測逃避技術(shù)。

差異

執(zhí)行流程

最終的 Payload 執(zhí)行前要執(zhí)行多個步驟：

觀察最近收集的樣本，減少了執(zhí)行的步驟：

原因尚不清楚，但是猜測是因為較長的執(zhí)行過程無法有效降低檢測率。Emotet 使用一種被稱為反射加載的技術(shù)來在所有階段進行加載，那么如果某個安全產(chǎn)品可以檢測到反射加載這個行為，則多次使用也無助于規(guī)避檢測。

另一個可能的原因是，攻擊者試圖逃避專門為 Emotet 創(chuàng)建的啟發(fā)式檢測方法。因為先前的執(zhí)行流程非常長，這變成了一個獨特的特征。如果檢測到如此長的執(zhí)行流程也就可以發(fā)現(xiàn) Emotet，所以更改執(zhí)行流程的常讀可能會有所幫助。

Loader

Loader 也進行了一些更改。第一個變動是從可執(zhí)行文件切換到 DLL。該 DLL 文件具有導(dǎo)出函數(shù) RunDLL和 Control_RunDLL，這使檢測由 Emotet 引起的感染成為可能。如果使用與導(dǎo)出匹配的參數(shù)啟動了進程 rundll32.exe，則系統(tǒng)就是被 Emotet 被感染了。

import “pe” 
private rule emotet_exports 
{ 
condition: 
pe.exports(“RunDLL”) or pe.exports(“Control_RunDLL”) 
} 
private rule is_dll 
{ 
condition: 
pe.characteristics & pe.DLL 
} 
rule emotet 
{ 
condition: 
is_dll and emotet_exports 
} 

混淆技術(shù)

通過 Loader 提取得到的 Payload 使用了一種新的混淆技術(shù)，使用多個按位運算而非單個位運算來在局部變量中設(shè)置值。這種混淆在不執(zhí)行代碼的情況下非常難以理解，調(diào)試過程也十分繁瑣。

相似之處

解密算法

Payload 加密后存儲在 Loader 中，此前開發(fā)針對 Emotet 進行靜態(tài)解密提取 Payload 的工具仍然有效，沒有改變加密算法。

代碼混淆

除上述混淆技術(shù)外，代碼還包含一個復(fù)雜的條件分支和不必要的跳轉(zhuǎn)指令，這讓分析代碼執(zhí)行順序變得異常困難。

隱藏數(shù)據(jù)

Payload 通過不列出 Windows API 的名稱或者任何有意義的字符串來隱藏功能。研究人員必須通過調(diào)試才能知道 Payload 的功能，字符串以加密形式存儲，API 使用名稱的哈希值進行解析。

進化

2020 年末，Emotet 的進化在盡可能地降低檢出的概率。由于感染的數(shù)量甚多，跟蹤 Emotet 的不斷進化至關(guān)重要，它的變動很可能會造成大面積的感染。

參考來源：DeepInstinct