回看曾經(jīng)的王者Emotet
臭名昭著的惡意軟件僵尸網(wǎng)絡 Emotet 在 2020 年 10 月底陷入低迷，又在 2020 年 12 月 21 日再次活躍。Emotet 充當惡意軟件的橋頭堡，在失陷主機上安裝其他惡意軟件。目前，觀察到 Emotet 在野分發(fā) TrickBot。立陶宛的國家公共衛(wèi)生中心遭到了 Emotet 的攻擊，Emotet 感染了其內部網(wǎng)絡，并開始下載其他惡意軟件。這導致立陶宛國家公共衛(wèi)生中心暫時禁用了電子郵件系統(tǒng)，直到惡意軟件被從內部網(wǎng)絡中刪除。
本文將會介紹 Emotet 的新 Loader 并與前期使用的 Loader 進行對比。二者在解壓縮的順序、文件的新屬性和新的混淆方法上存在差異，與此同時還會討論使用的檢測逃避技術。
差異
執(zhí)行流程
最終的 Payload 執(zhí)行前要執(zhí)行多個步驟：
觀察最近收集的樣本，減少了執(zhí)行的步驟：
原因尚不清楚，但是猜測是因為較長的執(zhí)行過程無法有效降低檢測率。Emotet 使用一種被稱為反射加載的技術來在所有階段進行加載，那么如果某個安全產品可以檢測到反射加載這個行為，則多次使用也無助于規(guī)避檢測。
另一個可能的原因是，攻擊者試圖逃避專門為 Emotet 創(chuàng)建的啟發(fā)式檢測方法。因為先前的執(zhí)行流程非常長，這變成了一個獨特的特征。如果檢測到如此長的執(zhí)行流程也就可以發(fā)現(xiàn) Emotet，所以更改執(zhí)行流程的常讀可能會有所幫助。
Loader
Loader 也進行了一些更改。第一個變動是從可執(zhí)行文件切換到 DLL。該 DLL 文件具有導出函數(shù) RunDLL和 Control_RunDLL，這使檢測由 Emotet 引起的感染成為可能。如果使用與導出匹配的參數(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
- }
混淆技術
通過 Loader 提取得到的 Payload 使用了一種新的混淆技術，使用多個按位運算而非單個位運算來在局部變量中設置值。這種混淆在不執(zhí)行代碼的情況下非常難以理解，調試過程也十分繁瑣。
相似之處
解密算法
Payload 加密后存儲在 Loader 中，此前開發(fā)針對 Emotet 進行靜態(tài)解密提取 Payload 的工具仍然有效，沒有改變加密算法。
代碼混淆
除上述混淆技術外，代碼還包含一個復雜的條件分支和不必要的跳轉指令，這讓分析代碼執(zhí)行順序變得異常困難。
隱藏數(shù)據(jù)
Payload 通過不列出 Windows API 的名稱或者任何有意義的字符串來隱藏功能。研究人員必須通過調試才能知道 Payload 的功能，字符串以加密形式存儲，API 使用名稱的哈希值進行解析。
進化
2020 年末，Emotet 的進化在盡可能地降低檢出的概率。由于感染的數(shù)量甚多，跟蹤 Emotet 的不斷進化至關重要，它的變動很可能會造成大面積的感染。
參考來源：DeepInstinct
