對Avzhan DDoS bot的深入介紹及樣本的層層分析

自2010年以來，Avzhan DDoS機器人一直被人們所知，但最近我們又在野外看到了它，中國的路過式攻擊（drive-by attack）可以將其刪除。在本文中，我們將深入研究其功能，並將捕獲的樣本與過去描述的樣本進行比較。

分析樣本

· 05749f08ebd9762511c6da92481e87d8——主要樣本,被開發工具包刪除

· 5e2d07cbd3ef3d5f32027b4501fb3fe6——打開(Server.dll)

· 05dfe8215c1b33f031bb168f8a90d08e——2010年的版本(參考樣本)

行為分析

安裝

部署完該惡意軟體之後，它會以一個隨機的名字將自己複製到一個系統文件夾中，然後刪除原始樣本:

其實現持久性的方法是通過假冒一種Windows服務對自身進行註冊。當然,此操作需要管理員許可權,這意味著為了實現成功安裝,樣本必須提高許可權運行。bot沒有UAC旁路功能,所以它只能依靠一些外部滴管、使用漏洞利用或社會工程。

添加註冊表鍵的樣本,與註冊一個新的服務有關:

我們也在已安裝的服務列表中發現了該惡意軟體:

有趣的是，這個被刪除的主要樣本也被另一個惡意軟體感染，Virut是一個非常古老的家族(並且在64位系統上崩潰)。一旦部署完成，它就開始感染磁碟上的其他可執行文件。關於Virut的更多內容，我們將在另一篇文章中討論。

網絡流量

我們可以看到該bot連接到它的CnC:

檢查網路流量，我們發現了發送的信標。它是一種二進位格式，並包含收集的關於受害者系統的信息:

這裡的信標與Arbor Networks描述的2010的一個信標非常相似。伺服器響應的是單個NULL位元組。

在實驗期間,我們沒有捕獲由該bot執行的與典型DDoS活動有關的流量。不過,通過代碼我們可以清楚地看到它具有這些功能。

樣本內部

階段1:載入程序

樣本是以一種打包的形式傳播的。主要樣本的原始名稱是Cache.dat,其輸出一個函數:lp

在Ip內部，我們可以很容易地看到該函數創建一個變數、用字元串填充該變數，然後返回該變數:

然而，就在函數Ip下面，我們發現另一個看起來可讀的函數:

通過其特性，我們可以看到它是一個很好的候選函數，在之後的過程中該函數可以解包並安裝payload:

1 它需要一些硬編碼的緩衝區並對其進行處理，這看起來像是對payload進行了混淆處理。

2 它在未打包的payload的輸出表中搜索函數「StartupService」，它給我們提示，未打包的內容是一個PE文件。

3 最後，在payload中調用找到的函數。

我們可以通過在調試器下觀察執行來確認這一點。在解碼函數被調用之後，我們看到緩衝區變成了一個新的PE文件:

此時，我們可以轉儲緩衝區，對其進行修剪，並單獨分析它。事實證明，該緩衝區是bot的核心，執行所有的惡意操作。PE文件是原始格式，因此不需要進行映射。此外，載入器將分配另一個內存區域，並且在該內存區域將payload映射到Virtual Format，以便該payload可以執行。

反轉儲技巧

該惡意軟體使用了幾個技巧來避免自動轉儲。首先，載入的payload與頁面的開頭沒有對齊:

如果我們此時轉儲，我們還需要取消映射(即通過pe_unmapper)，因為此時payload在Virtual Format中。然而，也有一些令人不快的意外:載入器使用完重新定位表和資源後，二者就被刪除。這就是為什麼在映射之前轉儲payload通常更可靠。然而，payload中的一些數據可能也會被載入。因此，如果我們不把這兩個版本都轉儲，可能會丟失一些信息。

在2010年的版本中，最外層已丟失。該惡意軟體是通過一個可執行文件傳播的，這個可執行文件相當於從當前樣本中取出的payload。

階段2:核心

按照前面提到的步驟，我們獲得了名為Server.dll的核心DLL。並且發現該核心非常陳舊——該散列是一年多前第一次在VirusTotal上看到的。然而，當時並沒有詳細描述它，所以我認為它仍然值得分析。

相比之下，2010年的樣本並不是一個DLL，而是一個獨立的EXE。然而，通過字元串，以及在BinDiff的幫助下進行的比較，我們可以看到驚人的相似之處，這證明了核心並沒有發生太大的變化。

執行流程

執行從導出函數——StartupServer開始。在開始的時候，該樣本調用包含非ASCII碼的OutputDebugStringA。有趣的是，該內容並不是隨機的。之前在載入器中使用了相同的位元組，即在payload中執行該函數之前。然而，其目的仍然是未知的。

該樣本還試圖檢查當前的DLL是否已經由導出一個函數「lp」的主模塊載入。如果是，就調用該函數:

正如我們所記得的，恰好具有該名稱的函數是由外層導出的。該函數應該檢索bot的配置，比如CnC地址和Windows服務名。在被檢索之後，數據會被複制到bot的數據部分(配置會硬編碼到bot中)。

在此之後，惡意軟體將繼續其主要功能。我們可以看到，檢索到的數據和硬編碼的數據後來被傳遞給了安裝該服務的函數:

根據相應的註冊表鍵的存在，惡意軟體會區分這是第一次運行還是已經安裝好了。根據這些信息，它可以採取不同的路徑。

如果該惡意軟體還沒有安裝，它將繼續安裝並退出：

否則，它將運行其主要服務功能

主要的服務功能是負責與CnC的通信。它部署了一個線程，它讀取命令並部署適當的操作:

功能

首先，該bot連接到CnC，並發送一個包含有關受害者系統的信息的信標:

收集的信息是詳細的，包含處理器特性和互聯網速度。在行為分析中這些數據被發送。

在成功的信標之後，它會部署主循環，在那裡監聽來自CnC的命令，解析它們，然後執行：

正如我們所看到的，惡意軟體可以充當下載器——它可以從CnC提供的鏈接中獲取並部署一個新的可執行文件：

CnC還可以推動主bot的更新，並指導bot將自己完全刪除。

但是，最重要的功能是在幾個不同的DDoS攻擊中，可以遠程部署到任何指定的目標上。由CnC提供目標地址以及攻擊ID。

在為這些攻擊準備的請求中，我們可以看到熟悉的字元串，其目的已經在2010年的報告中描述。我們可以看到畸形的GET請求:

作為替代，它可以使用一個有效的GET請求，例如:

泛洪函數被部署到一個新的線程中，並在循環中重複請求，直到啟用了停止條件。例子如下：

結論

該bot很簡單，由一個不複雜的actor物件準備。從功能上看，多年來其變化也不大。唯一增加的功能是混淆惡意軟體，並賦予其外部層添加配置的能力

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！