前言
病毒分析很心酸,真的會禿頭。
這個是關于Criakl勒索病毒安全預警:https://baijiahao.baidu.com/s?id=1621544930994823264&wfr=spider&for=pc感謝這些安全專家吧,唉。不說了。頭發真的都掉完了~~~
一:目錄
- 1.目錄
- 2.Ioc
- 3.行為分析
- 4.樣本分析
- 5.技術總結
二:IoC
2.1 母文件
- 1.樣本名稱:ab82cb53a9c89f2e808288957be88b38.vir
- 2.樣本md5:ab82cb53a9c89f2e808288957be88b38
- 3.是否加殼:UPX
- 4.編譯語言:vc++
- 5.樣本來源:來自于網絡收集
2.2 子文件
- 1.樣本名稱:3bd50eabb01b9561afa046b34729b104.vir
- 2.樣本md5:3bd50eabb01b9561afa046b34729b104
- 3.是否加殼:無
- 4.編譯語言:Borland Delphi(2.0-7.0)
- 5.樣本來源:母文件中釋放而來
2.3 url
三:行為分析
行為分析:

四:樣本分析
4.1 母體文件(Crikl.d)
- 加載名為ZZZZZ的資源文件,利用ResourceHack查看,可以明顯看到文件被加密了。


- 解密資源文件,解密算法不做分析,直接OD運行跑起來就好了。根據查看Hex很明顯看出來這是一個可執行文件

- 在調試過程中,發現病毒并沒有采用明文的方式構建字符串,而是將字符串加密了,發現調用了幾個關鍵的函數如下,可以知道Criakl使用了較為常見的傀儡進程的技術:
- ZwUnmapViewOfSection:解除文件映射關系
- VirtualAllocEx:分配內存空間
- WriteProcessMemory:寫進程內存
- SetThreadContext:設置進(線)程上下文
- ResumeThread:喚起主線程


- 根據PE結構修復PE節區表:不然進程是跑不起來的。如下也符合Delphi程序的節區表特性


- 接下來,我們已經得到了PE數據了,我們需要做的是將惡意代碼dump下來。如圖:可以發現這是一個偽裝成壓縮包的惡意程序,但是這個程序dump出來是有問題的。


- 但是這個程序是可以運行的,根據追蹤,發現他在temp目錄下釋放了一個ycvA文件,而且發現這個文件是一個PE文件。并且執行的流程都和我們dump出來的一樣。我們有理由懷疑這個是同一個文件。



- 巧合的是:我得到兩份Criakl病毒樣本,一份是變種a,一份是變種d,其中釋放出來的惡意(同dump出來的文件),和變種a的MD5是一樣的??梢灾啦《咀髡咴谧兎Na的基礎上加了一層保護,形成的變種d。

4.2 子文件(Criakl.a)
程序流程分析
以下是第一種情況:不是由變種d創建的進程引發的。
- 第一步:Dephi程序,直接定位到關鍵函數

- 第二歩:利用Iswow64函數判斷當前計算機的位數,如果是32位機器,構造Program Files

- 第三步:構造c://Program Files//Rarlab目錄

- 第四步:檢查進程的默認SID,這一步的目的是為了判斷本進程是否由Criakl.d創建的進程。

- 第五步:如果C://Program Files//RarLab目錄不存在,創建該目錄,用于存放是否的惡意文件

- 第六步:判斷當前執行的文件是否有RarLab目錄下釋放的惡意文件執行的。

- 第七步:如果不是從RarLab下執行的惡意代碼,則將當前執行的惡意樣本寫一份,釋放到RarLab目錄下


- 第八步:將釋放的文件的時間修改為和svchost.exe一樣,目的還是為了迷惑受害者。

- 第九步:最后執行C:Program FilesRarLabyvcA.vir文件
以下是第二種情形:不是由變種d創建的進程引發,但是創建進程的文件目錄是在RarLab下
- 判斷是否帶有參數install以及計算機的位數,然后設置注冊表run鍵,最后執行感染流程。但是這里作者是通過0號參數是文件名寫入run鍵下的,但是作者沒有對獲取的文件名做驗證,導致如圖獲取的文件名是位于桌面的分析樣本,實際中,應該是位于RarLab目錄下的樣本。
以下是第三種情況:是由變種d創建的進程引發的。
- 第一步:判斷當前進程是否是在C:DOCUME~1hackyLOCALS~1TempRarLab目錄下,如果是則執行感染機制,否則創建該目錄,用來釋放惡意文件。
- 第二歩:和第一種情況相同,修改文件訪問時間,并且創建新的進程。然后退出本進程
執行流程分析
- 判斷C:Program FilesRarLabwinrar.tmp文件是否存在如果winrar.tmp文件存在
- 第一步:讀取winrar.tmp里面的數據。然后創建d.bat
- 第二步:之后的這個判斷永遠為假,對其交叉引用發現只有使用,沒有修改部分,也就是說這個變量是一個常量字符串。兩個比較必為假。不知道作者這步的意義是什么?【存疑】
如果winrar.tmp文件不存在
- 第一步:生成36輪次的隨機數,然后獲取本地時間,這些隨機數和時間用于以后修改被感染文件的文件名。格式為隨機數字符串+日期+時間+隨機數(字符串),
- 第二歩:然后經過9層加密后得到字符串,這個字符串是形成加密文件的名稱的組成部分以及后期加密用的數據元
- 第三步:以Post提交請求,但是這個網站現在已經訪問不了了,應該執行CC服務器的職責。
- 第三步:創建RarLab/winrar.zip,內容是之前的數據數據+這次產生的隨機數據
- 第四步:獲取本地磁盤盤符信息,然后進行26次循環,遍歷和加密文件
- 第五步:創建d.bat,用于刪除所有的.dat和.exe文件,以及做本地回環測試
加密流程分析
整個加密流程,差不多分析了兩天,里面的工程量異常巨大,頻繁調用了相同的結構,但是這些結構都是采用了隨機數進行加密,不清楚作者的真實意圖是什么,經過分析了部分加密樣本的形式,可能存在以下特征(這只是我的個人猜測):對于較小的文件,采用填充隨機字段+附加數據的方式加密文件,對于大文件,直接附加數據的方式加密。
- 首先對于x://windows目錄不進行加密
- 先讀取文件的內容,讀取完畢后,在判斷文件末尾是否存在{CRYPTENDBLACKDC}字段
- 進行了40輪次數據加密,由于程序使用了Randomize(),造成了加密的數據很大程度是隨機的。
- 對于大文件來說,Criakl直接附加額外的數據,一般是通過GetPostion函數獲取的設備相對位置和被加密文件的MD5值,并寫入文件的末尾。
- 接下來將一些數字寫入,這些數據分別代表的參數由
ReOpenBuff.cBytes
,ReOpenBuff.szPathName
,ReOpenBuff.szPathName[32]
等等。
- 然后寫入一個通過兩次設備相對位置獲取的一個字符串32位字符串
- 然后附加一個隨機字符+時間+隨機字符的機器ID,以及文件名和結束的感染標志
- 最后修改被感染文件名:filename+id-{id}-email-email@gmail.com-ver-4.0.0.0.cbf
五:技術總結
5.1 Delphi程序逆向
首先逆Delphi程序有一個神器:Delphi_Decompiler,而delphi編譯出來的PE文件可能會有CODE,DATA,BSS,.IDAta,tls,.rdata,.rsrc這些段。.rsrc段比較重要,這里除了一般的資源以外,還有工程信息和DFM資源信息,這一節開始部分是常規的資源表。Delphi程序(exe)常見的入口點如下,InitExe會從.rsrc讀取出資源里的drm,然后調用StartExe來從InitRoutineTable讀取所有的FunTable,挨個執行對應的Routine。CreateForm創建Form是整個程序初始化的主要流程:
delphi exe入口:
push ebp
mov ebp, esp
add esp, 0FFFFFFF4h
mov eax, offset InitRoutineTable
call @@InitExe
mov eax, ds:off_442C20
mov eax, [eax]
call unknown_libname_291
mov ecx, ds:off_442AB4
mov eax, ds:off_442C20
mov eax, [eax]
mov edx, off_441498
call @TApplication@CreateForm
mov eax, ds:off_442C20
mov eax, [eax]
call @TApplication@Run
call @@Halt0
,把我這幾天的小小體會分享一下。
一拿到函數流程,很dan疼,可以看到流程異常復雜,之前的勒索病毒都是利用windows提供的CSP加密,所以加密流程不是很復雜(比這個明了)。全篇2600的代碼量也是非常大的了,那么如何去分析呢??
我的做法是先找入口FirstFile,出口FindClose,中間過程FindNNext。確定了三個點,之后只需要在循環里面進行就好了。然后就是調試了。
2600多行的代碼調試起來相當麻煩,所以我先對其下斷點,首先是遞歸函數,一個斷點,有個rename
下一個斷點,剩下是關于WriteFile下斷,以及其他的重要的函數(PS:還要下一個硬件斷點,emmmm忘記在哪里了)如圖:
每當停下來的時候,就可以利用IDA查看交叉引用了。查看數據流的過程。
原文鏈接:https://www.anquanke.com/post/id/170624