Criakl勒索病毒分析簡要
前言
病毒分析很心酸,真的會禿頭。
這個是關於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是一樣的。可以知道病毒作者在變種a的基礎上加了一層保護,形成的變種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 protected] -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入口: pushebp movebp, esp addesp, 0FFFFFFF4h moveax, offset InitRoutineTable call@@InitExe// moveax, ds:off_442C20 moveax, [eax] callunknown_libname_291 movecx, ds:off_442AB4 moveax, ds:off_442C20 moveax, [eax] movedx, off_441498 call@TApplication@CreateForm moveax, ds:off_442C20 moveax, [eax] call@TApplication@Run call@@Halt0

如何定位?很簡單的。先用Delphi_Decompiler檢視Form,一旦找到Form,直接在IDA裡面跟就能找到具體的函式,最後OD下斷點即可!
Dephi採用的是Fast函式呼叫方式,也就是說前面3個引數用暫存器EAX,EDX,ECX儲存,剩下的引數利用棧儲存,返回值返回的是指標而非資料,這就需要逆向分析時先用OD轉到Hex視窗,在用裡面的地址值去檢視具體的資料。
參考自: https://www.52pojie.cn/thread-141040-1-1.html
5.2 加密過程定位
整個分析過程中關於加密過程所浪費的時間佔了60%的時間。但是也沒有分析出什麼特別有效的東西(寫不出解密工具),把我這幾天的小小體會分享一下。
一拿到函式流程,很dan疼,可以看到流程異常複雜,之前的勒索病毒都是利用windows提供的CSP加密,所以加密流程不是很複雜(比這個明瞭)。全篇2600的程式碼量也是非常大的了,那麼如何去分析呢??


我的做法是先找入口FirstFile,出口FindClose,中間過程FindNNext。確定了三個點,之後只需要在迴圈裡面進行就好了。然後就是除錯了。
2600多行的程式碼除錯起來相當麻煩,所以我先對其下斷點,首先是遞迴函式,一個斷點,有個rename
下一個斷點,剩下是關於WriteFile下斷,以及其他的重要的函式(PS:還要下一個硬體斷點,emmmm忘記在哪裡了)如圖:

每當停下來的時候,就可以利用IDA檢視交叉引用了。檢視資料流的過程。