Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    863108471

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

微信截图_20221214085509.png

Check Point Research(CPR)對臭名昭著的Azov勒索軟件進行了分析,分析表明,Azov能夠修改某些64位可執行文件以執行自己的代碼。在過去的幾周里,CPR在其社交媒體以及Bleeping Computer上分享了對Azov勒索軟件的初步調查結果。接下來,我們將介紹Azov勒索軟件的內部工作原理及其技術特點。

主要發現Azov最初是作為SmokeLoader殭屍網絡的有效負載而引起注意的,該殭屍網絡通常存在於假冒盜版軟件和破解網站中。

Azov與普通勒索軟件不同的是它對某些64位可執行文件的修改以執行自己的代碼。在現代互聯網出現之前,這種行為曾經是惡意軟件氾濫的必經之路。可執行文件的修改是使用多態代碼來完成的,這樣就不會被靜態簽名潛在地破壞,並且也適用於64位可執行文件。

這種對受害者可執行文件的攻擊性多態感染導致了大量感染Azov的公開可用文件。每天都有數百個與Azov相關的新樣本提交給VirusTotal,截至2022年11月,該樣本已超過17000個。使用手工製作的查詢,可以只搜索正確的Azov樣本,而不使用木馬化的二進製文件。

VirusTotal查詢以搜索與Azov相關的樣本:

1.png

1.2.png

VirusTotal查詢——Azov相關樣本

VirusTotal查詢僅搜索正確的Azov樣本,而不搜索木馬化二進製文件:

2.png

VirusTotal查詢——僅原始Azov樣本

豐富的樣本使我們能夠區分Azov的兩個不同版本,一個更老,一個稍新。這兩個版本共享它們的大部分功能,但較新版本使用了不同的勒索通知,以及銷毀文件的不同文件擴展名(.azov)。

3.png

新版本的Azov的贖金通知

4.png

舊版本的Azov的贖金通知

技術分析使用FASM在程序集中手動製作;

使用反分析和代碼混淆技術;

原始數據內容的多線程間歇性覆蓋(循環666字節);

在受損系統中後門64位“.exe”文件的多態方式;

“邏輯炸彈”設定在特定時間引爆。下面分析的樣本被設置為在UTC時間2022年10月27日上午10:14:30引爆;

沒有網絡活動,沒有數據洩露;

利用SmokeLoader殭屍網絡和木馬程序進行傳播;

有效、快速且不幸無法恢復的數據清除器;

研究人員專注於新Azov版本的原始樣本(SHA256:650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e-如上所述,與舊版本相比,功能上沒有重大差異)。這是一個64位的可移植可執行文件,已用FASM(平面彙編程序)組裝,只有1段.code (r+x),並且沒有任何導入。

5.png

FASM編譯器的檢測

6.png

只有一個“.code”部分,沒有導入

code字段分為三個部分,通過查看其熵最容易看出。首先,有一個高熵部分包含加密的shell代碼。之後是實現解包程序的純代碼,然後是熵非常低的最後一部分,似乎由用於構造勒索信的純字符串組成。

7.png

“.code”部分的熵

打開程序由於Azov的整個代碼都是手工編寫的,因此有必要執行一些IDA魔術和清理工作,以將代碼塑造成可以反編譯和理解的狀態。完成此操作後,過程start_0()就可見了。這段代碼將shellcode解包到新分配的內存中,然後將執行傳遞給它。

8.png

輸入函數start_0

函數AllocAndDecryptShellcode()中的解包程序被故意創建得看起來比實際更複雜。但實際上,它是一個簡單的種子解密算法,使用xor和rol的組合,其中key=0x15C13。

9.png

AllocAndDecryptShellcode函數中的解包程序

我們在下面提供了簡化程序邏輯的Python實現:

10.png

下一階段分為兩個主要程序:一個負責清除文件,另一個負責為可執行文件設置後門。

11.png

將執行轉移到清除和後門邏輯

清除程序清除程序首先創建一個互斥鎖(Local\\\\azov),以驗證惡意軟件的兩個實例沒有同時運行。

12.png

清除程序——互斥鎖創建

如果成功獲得互斥鎖句柄,Azov會通過木馬(類似於後門程序)64位Windows系統二進製文件msiexec.exe或perfmon.exe並將其保存為rdpclient.exe來創建持久性。在SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run上創建一個註冊表項,指向新創建的文件。

13.png

持久性創建

清除程序使用觸發時間——有一個循環,被分析的樣本檢查系統時間,如果不等於或大於觸發時間,則休眠10秒,然後再次循環。樣本觸發時間為2022年10月27日。

14.png

樣本觸發時間為2022年10月27日

一旦這個邏輯炸彈被觸發,清除器邏輯就會遍歷所有設備目錄,並對每個目錄執行清除程序,從而避免某些硬編碼的系統路徑和文件擴展名。

15.png

系統路徑和文件擴展名

16.png

清除時省略的文件擴展名

每個文件都被“間歇性”清除,這意味著666字節的塊被隨機噪聲覆蓋,然後一個大小相同的塊保持完整,然後一塊再次被覆蓋,依此類推,直到達到4GB的硬限制,此時所有其他數據都保持完整。作為隨機源,樣本使用未初始化的局部變量(例如,char buffer[666]),這實際上意味著隨機堆棧內存內容。

17.png

間歇性數據清除

18.png

數據清除程序的示例跟踪

清除完成後,新的文件擴展名.azov將添加到原始文件名中。清除文件的典型文件結構如下所示。

19.png

清除文件的示例結構

後門程序在遍歷文件系統以搜索要進入後門的文件之前,創建一個名為Local\\\\Kasimir_%c的互斥鎖,其中%c替換為正在處理的驅動器的字母。

20.png

後門程序——互斥鎖創建

TryToBackdoorExeFile()函數負責解密滿足特定條件的64位“.exe”文件進行後門。

21.png

通過預處理條件的文件進入TryToBackdoorExeFile函數

這些具體條件可簡化如下:

預處理條件:它不是文件系統位置清除列表的一部分;

文件擴展名為“.exe”;

文件大小小於20MB;

處理條件:該文件是64位可執行文件;

包含入口點的PE部分有足夠的空間用於注入shellcode植入程序,以保留PE的原始入口點(shellcode起始地址將放在原始入口點的地址);

File size==PE size(PE大小是手動計算的);

處理條件都在TryToBackdoorExeFile()函數中檢查。

22.png

TryToBackdoorExeFile函數

一旦文件滿足所有預處理和處理條件,它就被認為適合適合進行後門操作,並將其推入BackdoorExeFile()函數。

23.png

函數TryToBackdoorExeFile的鄰近圖

函數BackdoorExeFile()負責可執行文件的多態後門。它首先獲取原始代碼段(通常是.text段)的地址,然後在幾個位置隨機修改其內容。在將shellcode的主要blob注入到修改的代碼部分之前,某些常量值將被更改,整個shellcode將使用與前面描述的惡意軟件解包期間使用的相同的加密算法和密鑰重新加密。後門文件寫回磁盤後,三個編碼的數據結構被追加到它的末尾,這是勒索軟件運行所需的有效資源(例如,一種模糊形式的勒索通知)。

24.png

函數BackdoorExeFile的鄰近圖

儘管存在多態後門,但解包和後門過程中使用的加密/解密算法是一致的,可用於Azov檢測。

25.png

使用與解包期間相同的算法和密鑰重新加密shellcode的主blob

反分析和代碼混淆技術防止使用軟件斷點——如果設置了軟件斷點,使用例程將已經解密並正在執行的部分shellcode複製到新分配的內存中,然後將執行轉移到它,遲早會導致異常。在這種情況下,有必要使用硬件斷點。

26.png

防止使用軟件斷點的反分析技術

不透明常量——用產生相同結果常量值的代碼例程替換常量。 (這可以在負責計算常量偏移量的例程中反复看到,而不是直接使用它們,以便直接調用可以被間接調用取代)

27.png

不透明常數

語法混亂——用語義上不地道或完全擴展的等效指令替換指令。這方面的一個例子可以在負責解析導出目錄的程序中找到;另一種是用直接或間接jmp重複替換調用。兩者如下圖所示。

28.png

語法擴展

29.png

在調用中使用間接跳轉和直接跳轉

下面可以看到解析導出目錄的程序集的簡化版本。

30.png

垃圾代碼——插入垃圾字節,導致沒有有意義的指令,甚至根本沒有指令。

不透明謂詞——jz/jnz乍一看似乎是一個條件跳轉,但實際上條件總是滿足或總是不滿足,並且有效地充當無條件跳轉,使靜態分析混淆。這兩種混淆都可以在函數FindGetProcAddress()中看到。

31.png

垃圾字節插入和不透明謂詞混淆

調用-返回濫用——使用push-ret或Call而不是jmp。

32.png

控制間接

Volatile Homebrew IAT ——一個動態分配的結構,包含API函數地址,被用作嵌套結構,作為參數推送給需要使用特定WIN API例程而不是使用普通導入的函數。

33.png

動態創建的IAT類結構用作嵌套結構

總結儘管Azov樣本在第一次被發現時被認為是一個普通的勒索軟件,但當進一步調查時,我們發現了非常先進的技術——手工製作的組裝,將有效載荷注入可執行文件以打開後門。

儘管還不知道其幕後組織,但唯一可以肯定的是,所有這些分析都證實了Azov是一種先進的惡意軟件。