幫助眾多惡意軟體逃避檢測：針對一款Delphi加殼器的分析
概述
為了繞過靜態或動態分析工具，惡意軟體往往會使用加殼或加密的方法，這樣的方法已經被惡意軟體開發者廣泛使用。然而目前，惡意軟體使用多種新型技術，不斷嘗試逃避分類和檢測，而反病毒產品則不斷擴充自己的樣本庫，二者間實際上已經在進行著一場“軍備競賽”。例如，我們發現在地下論壇提供了許多加密服務，他們聲稱所製作的惡意軟體，完全無法被反病毒產品、沙箱或其他終端解決方案檢測到。與此同時，我們還看到安全產品在對正常的使用者行為資料進行建模，並嘗試著將其作為識別惡意軟體特徵的一種有效方案。
Delphi加殼
我們所分析的樣本，帶有Delphi的簽名（如下圖所示），與使用IDR（Interactive Delphi Reconstructor）分析時的Delphi程式碼構造一致。
藉助Delphi程式語言，我們能夠輕鬆編寫使用Windows API函式的應用程式或專案。實際上，一些惡意軟體編寫者使用預設庫進行偽裝，試圖妨礙靜態分析的轉移過程，並試圖使應用程式在動態分析中“看起來合法”。下圖就是在某論壇中討論這種技術的一篇帖子。
惡意軟體的分發
我們觀察到，目前存在具有多個不同主題的惡意郵件，會分發使用這一加殼器進行加殼的Payload。
其中的一個典型例子是電匯惡意郵件，郵件中會包含一個文件檔案作為其附件（雜湊值：71cd5df89e3936bb39790010d6d52a2d）。在該文件中，包含一個惡意巨集，也就是其Payload。惡意郵件的內容如下圖所示。
另一個比較典型的例子，是詢問報價主題的惡意郵件，它以一個包含漏洞利用的文件作為附件（雜湊值：0543e266012d9a3e33a9688a95fce358），該文件利用公式編輯器存在的漏洞來投放Payload（如下圖所示）。
這一示例中的文件，會從http[://]5[.]152.203.115/win32[.]exe的位置獲取Payload。經過分析，其Payload實際上是Lokibot惡意軟體。
對使用者活動進行檢查
加殼器需要儘量確保它不是在分析環境中執行。一般來說，計算機使用者在一段時間內就會更改一些應用程式的視窗大小（包括移動位置、縮放等）。因此，該加殼器的第一個變種會首先呼叫GetForegroundWindow API檢查是否使用者已經更改視窗大小3次以上，如果沒有，則不會執行任何功能。這一部分的程式碼如下圖所示。有趣的是，通過這樣簡單的技術，其實就可以防範一部分常用的沙箱。
為了確認使用者的活動，加殼器的第二個變體使用GetCursorPos和Sleep API檢查滑鼠游標移動，而第三個變體使用GetLastInputInfo和GetTickCount API檢查系統空閒狀態。
從PE資源中提取實際Payload
原始Payload被拆分成多個二進位制Blob，並存儲在資源目錄的各個位置，如下圖所示。
為了定位並組裝實際Payload的位元組，加殼器程式碼首先直接從資源段內的硬編碼資源ID讀取內容。它的前16個位元組形成一個XOR金鑰，用於使用滾動XOR（Rolling XOR）解密其餘位元組。解密的位元組實際上表示內部資料結構，如下圖所示。加殼器使用它，來引用各種資源ID的加密和混淆緩衝區。
然後，加殼器從加密緩衝區中讀取值，從dwStartResourceId開始，直到dwStartResourceId+dwNumberOfResources，同時通過讀取dwChunkSize塊中的內容，將其儲存到一個特定的位置。當最終的資料緩衝區準備完成後，會使用前面提到的滾動XOR演算法，以及上述結構中新的金鑰，對其進行解密，從而生成核心Payload可執行檔案。這個指令碼可用於靜態提取實際的Payload。
惡意軟體真實的家族分類
我們對樣本中的二進位制檔案進行提取並去殼，最終它們都被識別為Lokibot惡意軟體家族。此外，我們還發現了Pony、IRStealer、Nanocore、Netwire、Remcos和nJRAT惡意軟體系列，以及一些加密貨幣挖掘惡意軟體。使用該加殼器的惡意軟體家族分佈如下圖所示。由於惡意軟體的種類比較多樣，所以也就意味著有很多惡意軟體開發人員都在使用這種“加密服務”或“加密工具”，以試圖逃避反病毒機制的檢測。
結論
這些加殼和加密服務，無疑是為惡意軟體開發人員提供了一種簡單方便的選擇。他們可以將保護真正Payload的這部分工作外包出去，並且獲得非常有效的結果。我們所分析的加殼器採用了反分析技術，從而嘗試繞過沙箱。針對於此，如果研究人員能在模擬真實使用者行為的沙箱環境中對惡意軟體進行分析，那麼無疑這樣的機制就會變得不再有效。
IoC
853bed3ad5cc4b1471e959bfd0ea7c7c
e3c421d404c08809dd8ee3365552e305
14e5326c5da90cd6619b7fe1bc4a97e1
dc999a1a2c5e796e450c0a6a61950e3f
3ad781934e67a8b84739866b0b55544b
b4f5e691b264103b9c4fb04fa3429f1e