作者論壇賬號：Ironmna

引子

很久前手里的一個樣本，之前因為技術不夠一直沒有詳細分析，最近心血來潮盡我所能詳細分析一下。

樣本概覽

復制代碼 隱藏代碼
文件名：2017-01-31-EITest-Rig-EK-payload-CryptoShield-rad6BF31.tmp.exe
文件大小：93.5Kb（95,744字節(jié)）
文件版本：11,20,2,0
修改時間：2017/2/1 2:03:35
CRC32：e879afbd
MD5：cc882e0f288b8996bfa66cda9a27e137
SHA1：e5686d807ada9e7e953dd2a125fdaf5be958375b

行為分析

運行情況

首先雙擊運行，等待40s左右(一會的分析就能告訴你為什么它這么慢）彈出勒索文檔，大概就告訴你：“你的電腦被我加密啦，我用的RSA-2048”，它還貼心的給你放上了維基百科。總之就是你的重要文檔都被強加密，不交錢的話休想復原了（后續(xù)我們來解決這件事）：

大概查看一下發(fā)現(xiàn)各個文件夾下都產生了這兩個勒索文檔，同時被加密的文件會以“加密串.CRYPTOSHIELD”格式顯示：

同時里面的內容也被加密的無法判斷出這是一個什么類型的文件：

具體行為監(jiān)控

接下來我們查看一下樣本都有哪些行為，火絨劍記錄的行為很多，這里我只貼一下主要的行為。首先病毒將自身移動到系統(tǒng)文件夾并將自身偽裝為SmartScreen軟件：

之后創(chuàng)建了注冊表自啟動項，便于后續(xù)持久化攻擊：

各處創(chuàng)建勒索文檔：

這部分訪問了加密相關的注冊表值應該是使用CSP加密庫進行加密了，同時也能看到文件名被修改了：

接著病毒又刪除了備份文件，停止與備份相關的服務防止用戶進行數據恢復（這里程序名稱不同，因為這是我提取到的子進程，后續(xù)會說到）。

逆向分析

接下來我們從靜態(tài)分析和動態(tài)分析上來搞明白這個程序到底是如何運行的，以及嘗試看看我們是否有挽救數據的機會。

加載器部分

查看導入表

查看導入表發(fā)現(xiàn)幾乎找不到與病毒行為相關的函數，這里猜測此程序應該只是一個加載器，實際程序應該是隱藏在程序某個段中，待此程序加載到內存中進行釋放并執(zhí)行真正的病毒：

靜態(tài)分析

將程序拖入IDA，定位到主函數查看一下主要流程實際上就是先將數據進行解密，解密后再加載至內存運行，專業(yè)上講這叫做：“病毒文件不落地”hhh。實際上也是躲避殺軟檢測的手法之一：

接下來我們主要分析一下病毒數據是如何解密并加載到內存中的。這里看到實際上病毒數據是存儲在了資源段中，程序讀取名為“FSKLJDHFUISDOJGOISDHGIOKDSHUGIJSDOI”的資源并加載到0x7E00大小的內存中（實際上這就是病毒文件的大小，為我們后續(xù)解密資源提供了幫助），加載后經過分析發(fā)現(xiàn)這段數據是被RC4算法加密了，程序先對數據進行RC4解密，之后將病毒進行分段加載到內存中：

RC4算法特征是具有一個256的SBOX，這里就不貼了。我們簡單看下它的加載函數。實際上這就是一個簡易的PE加載器，先將病毒程序分段加載到內存中，然后依次修復重定位表，導入表：

因為主要內容不在這個程序中，這里我們只粗略地分析了過程，接下來我們手動將病毒程序提取出來。

動態(tài)調試提取病毒文件

由于我們在上文看到了程序先將資源文件讀入到內存中對數據進行解密后再進行加載的，那實際上我們斷點斷在解密后的位置就能順利的提取出病毒數據，下圖紅框中便是病毒文件：

寫一個簡單的IDC腳本將內存dump出來即可提取到病毒文件。

病毒主程序

查看導入函數

用到了CryptoAPi相關函數、注冊表相關函數、Socket相關函數。確定了這就是勒索軟件本體，另外這里還用到了很多次網絡連接相關的函數（行為分析沒有查看到應該是我斷網運行的原因= =），猜測會與C2服務器進行通信：

梳理病毒運行過程

由于病毒涉及到很多流程，為了能分析得更加具有條理性這里我先將病毒大概的運行過程貼一下，方便后續(xù)一步一步的分析：

獲取電腦第一個盤的序號作為第一個部分，獲取用戶名并對用戶名數組進行簡單的異或和移位操作得到第二部分。這兩部分共同組成互斥鎖ID避免勒索軟件重復加密：

接下來程序檢測是否存在名為“1FAAXB2.tmp”的文件并且文件內容是否為“AFEE16BC"。第一次運行是不會產生這個文件的，這實際上可以看做一個病毒存檔的文件，一旦用戶電腦中有這種特征就證明已被感染，所以為了讓它閉嘴我們其實也可以手動創(chuàng)建個這個文件【滑稽】:

對于第一次運行的電腦，程序會偽裝到系統(tǒng)目錄同時創(chuàng)建自啟動項便于持久化攻擊：

注冊表情況，這里多了兩個啟動項都是病毒文件：

上述幾部分準備工作完成后接下來開始嘗試對文件進行加密。程序在不同地方多次出現(xiàn)這一部分操作，這其實是程序生成的密鑰文件，主要目的是通過檢測它是否生成來判斷用戶是通過哪種方式加密的(單機情況不會生成這個文件）：

開始檢測系統(tǒng)網絡連通性，程序嘗試與C2服務器進行連接：

如果連接成功程序會隨機導出一個密鑰，接著將密鑰進行RC4加密后存入下面這個文件中：

如果存在密鑰文件就將密鑰文件進行上傳，上傳的參數有三個分別為：唯一序列號、密鑰、用戶代{過}{濾}理：

上傳完成后到達了這一步。這一步是為了獲取密鑰明文形式。如果存在密鑰文件那就直接讀取并進行RC4解密得到key，如果不存在那就對準備好的機器碼解密也能得到key：

這一部分就是被RC4加密的Key了：

這里我事先寫好一個RC4解密腳本，試著將這部分解密一下得到情況如下：

接下來主體加密部分，程序并沒有使用多線程進行加密（這就是之前為什么我等待感染都要等待那么長時間的原因 = =），對三種大小的文件進行加密：

程序循環(huán)對每個盤進行感染，這里注意到如果是U盤或者網絡介質，程序還會將自己偽裝成解密軟件儲存到介質中，這一步是為了產生大范圍感染：

程序列出了一份白名單不感染這些文件夾，這一步為了讓系統(tǒng)能夠正常運行：

程序會感染的文件的后綴名，這里看一下發(fā)現(xiàn)大多都是文檔數據類，不至于系統(tǒng)所有東西都運行不了：

這里開始加密，發(fā)現(xiàn)程序使用了我們之前分析的Key生成一個Hash，用它作為AES加密的key。到這里我們可以思考一下程序使用的是AES對稱加密，如果我們能得到Key文件，至少在用戶單機被感染的情況下我們是可以完全解救的：

加密完文件后，這里還會對文件名進行一下簡單的加密：

最后這里我們簡單梳理一下作者對文件的加密邏輯，在大小符合0~256M這區(qū)間的文檔，程序將文件進行直接加密，而對于過大的文件選擇直接改名不進行加密（無語）：

緊接著程序在每個感染的文件夾內寫入兩個勒索文檔：

程序還會嘗試去刪除密鑰文件防止用戶拿到進行解密。這一部分對于網絡感染的用戶實際上是基本無解的（其實可以嘗試一下數據恢復密鑰文件）：

這一部分在行為分析部分我們已捕捉到了，程序最后還會刪除系統(tǒng)中的所有備份文件，防止用戶進行系統(tǒng)恢復：

最后彈出兩個勒索文檔，提示用戶電腦已被綁架：

分析部分到此為止，我們已經將程序全部的行為分析出來了，接下來我們嘗試去解決解密的問題。

數據恢復

目前所知的情況如下：

1. 程序使用AES對稱加密。

2. 程序會在單機和聯(lián)網上產生兩種不同的加密方案。

3. 單機情況下AES的key以RC4加密的形式儲存在程序內。

4. 聯(lián)網情況下AES的key儲存在文檔內，最后程序會刪除。

那么對于聯(lián)網感染用戶來說，我們有兩種辦法得到key：

1. 在生成密鑰時進行Debug追蹤，在程序刪除前即可拿到Key。

2. 使用專業(yè)的數據恢復手段恢復出Key。

對于第一種方式這就是純廢話，因為用戶并不會在得知這是勒索病毒的情況下進行debug運行（皮一下），而第二種辦法也希望渺茫。但是對于單機用戶情況就完全不同了，因為我們的Key是明晃晃的儲存在程序中，我們只要拿到Key就完全可以恢復出數據，為此我寫了一個Demo用于測試解密，解密情況如下所示，成功的解密出了文件名和數據：

使用的是Win7自帶的視頻，測試是正常的，文中用到的各種文件都在附件中：

總結

自認為這一次對文件的分析還是比較全面的。另外吐槽一下分析病毒真是一個花費時間的活，對某個前輩所說的“病毒分析很多時候就是人對抗人”不能再認同了。

樣本見論壇原文。

論壇原文地址：https://www.52pojie.cn/thread-1485004-1-1.html