APT蔓靈花分析

 病毒樣本下載來源於i春秋逆向版主Crazyman_Army主題帖《記一次蔓靈花APT組織針對巴基斯坦定向的樣本分析》，樣本連接：https://bbs.ichunqiu.com/thread-50002-1-1.html

 對於我的而言，看過APT分析報告，可是不多逆向相關得惡意代碼，畢竟樣本少，既然發現了一枚，走過路過不能錯過。

 ☛APT（Advanced Persistent Threat）是指高級持續性威脅，特別有針對性得方式。

 我的對於APT的理解✎：APT是綜合了社會工程學，人性弱點，系統漏洞等等，多方因素協調惡意代碼發起Attack，長期潛伏，時效長達半年或者更久，收集大量的數據爲attack作準備。有組織，有紀律，是一名合格的"間諜"，隱蔽性很強（代碼的隱蔽性），運行方式獨特，難以查殺。
✃ 
線上惡意代碼分析以下：

                    圖片一：線上分析
 經過在線分析，與原貼中殺毒識別的個數略有差別，這是一個被明確且已能被防範的樣本。
✃  
手動分析以下：
一、Exinfo PE查看文件信息，以下所示：

                    圖片二：樣本信息
經過Exinfo PE觀察，樣本沒有加殼，並且是c++編寫的，是圖形用戶界面程序（GUI）。 
✃ 
二、IDA靜態分析：

                    圖片三：GUI流程

                    圖片四：過程化流程
下面在IDA中具體的分析一下代碼，先看圖片三中的GUI流程，以下所示：

                    圖片五：GUI代碼分析
 經過ShowWindow第二個參數填入SW_HIDE數值（也就是0），意味着建立了一個隱藏窗口，調用sub_401330去執行惡意代碼。
 進入函數sub_401330以後，發現了大量的數據的初始化及循環解密字符串的環節，以下所示：

                    圖片六：數據初始化

                    圖片七：字符串解密
 根據我的習慣，遇到着這狀況就要動態調試，單純的靠靜態去分析有些麻煩，下面經過動態分析去還原這些數據的操做。
✃  
三、OD動態調試：
 主要分析sub_401330函數都幹了那些事情，首先初始化了一堆數據，如圖片六所示，而後又結束進程？句柄參數仍是NULL，以下所示：

                    圖片八：TerminateProcess
 句柄爲空，返回值會是INVALID_HANDLE無效的句柄值，接下來經過字符串運算獲取了註冊表（自啓動路徑），以下所示：

                    圖片九：獲取自啓動路徑
接下來拷貝了獲取的字符串，以下所示：

                    圖片十：拷貝
運算字符串獲取msdtcv，以下所示：

                    圖片十一：msdtcv
拼接成msdtcv.exe，以下所示：

                    圖片十二：msdtcv.exe
 這時候已經拼接成一個後綴爲.exe的程序了，按照通常的套路基本都是查找資源，鎖定資源釋放到某一個文件夾下，運行釋放的可執行代碼，終止當前進程，其實這個套路也是，只不過是拷貝了本身，以下所示：

                    圖片十三：_mkdir
先在C盤下建立了一個文件夾，應該是準備來文件夾下拷貝或者寫入資源，以下所示：

                    圖片十四：字符串拼接
 如上圖用了rep movs 彙編指令進行了文件夾路徑與msdtcv.exe拼接，高級語言的就是strcat函數，既然路徑野拼接出來了，接下來理論是要該路徑的程序落實，獲取了當前程序運行路徑，接着獲取了Open字符串，以下所示：

                    圖片十五：Open
 感受前奏應該快完了，但是發現了一個新函數，不用說應該前奏還沒結束，繼續跟如新函數一探究竟，以下所示：

                    圖片十六：SHGetFolderPathA
 官方給出的函數解釋Deprecated. Gets the path of a folder identified by a CSIDL value.，獲取CSIDL路徑，這個函數已廢棄。繼續接着看，以下所示：

                    圖片十七：cmd命令
 看到了上面字符串格式：copy "" "" 拷貝當前數據到c:\intel\msdtcv.exe，與猜想的步驟吻合，確實要拷貝了，既然cmd無非那幾個函數能夠做爲參數執行cmd指令WinExec、ShellExecute、CreateProcess等API來實現，樣本中用到了ShellExecute與CreateProcess，繼續分析，以下圖所示：

                    圖片十八：reg cmd命令
 利用cmd進行自啓動，這個函數運算拼接獲取了這些即將會被用到的字符串，向下繼續分析，遇見了函數以下：

                    圖片十九：sub_401F00函數
對於數據則很簡單，有編程基礎的人沒有一點難度，貼上一張IDA轉成C以後的圖：

                    圖片二十：Reg API
打開及檢索AppId鍵值，若是存在則寫入路徑c:\intel\msdtcv.exe，以下所示：


                    圖片二十一：設置成功

 爲何要在Environment下的AppID中設置呢？HKEY_CURRENT_USER根鍵中的信息的修改都會致使對HKEY_USERS.Default中子鍵信息的修改，修改當前用戶環境，AppId設置爲運行路徑，後面會使用cmd的命令，調用%AppId%環境變量啓動且退出，以下所示：

這種方式相對於直接調用敏感的API來講很聰明，接着又開了註冊表，以下所示：

                    圖片二十二：RegOpenKeyEx
 經過觀察參數，咱們就能夠肯定這是對自啓動鍵值進行相關操做，下面調用了CreateThread函數，以下圖所示：

                    圖片二十三：CreateThread
重點分析一下上圖中標紅處的回調函數，以下所示：

                    圖片二十四：回調函數分析
 意圖很明顯了，樣本字符串的規律來看，這個樣本只要是對字符串賦值，意味着後面必定會有運算解密，果然以下所示：

                    圖片二十五：解密代碼
 上面一段代碼動態解密出來的字符串是ComSpec，其實也就是%ComSpec%環境變量，來看一下，以下所示：

                    圖片二十六：echo %ComSpec%
 前面獲取了大量的cmd指令，又獲取了cmd.exe可執行路徑，下面必須是建立cmd進程，不然那麼多的sub不就白費了.....以下所示：

                    圖片二十七：CreateThread
接下來向cmd.exe寫入執行的數據，完成了cmd命令拷貝，以下圖所示：

                    圖片二十八：WriteFile
 回調函數結束了它的使命，建立了cmd線程且利用匿名管道寫入執行的cmd指令，實現自身拷貝，這段代碼仍是比較有意思。接下來到了分水嶺，也就是當前進程的終點了，以下圖所示：

                    圖片二十九：分水嶺
如圖二十二，咱們明白這是要檢測是否已存在啓動項，若是響應成功則執行以下：

                    圖片三十： 執行1
 那麼上述代碼就結束了exit退出了，而後運行msdtcv.exe，其實仍是本身，我繼續來下看，下面就是網絡相關的操做，接着調用了一個sub_4037b0，這是一個有意思的函數，以下圖所示:

                    圖片三十一：RegOpenKeyEx

                    圖片三十二：MachineGuid
 有意思的代碼如上，MachineGuid？這個就是所謂的超級硬件惟一標識，可是什麼都沒有操做....只是作了判斷獲取了標識符數據，應該另有用處，以下所示：

                    圖片三十三：sub_4037b0返回值
進行了WSA初始化及socket操做，以下所示：

                    圖片三十四：gethostname

                    圖片三十五：sub_402520返回值
接着調用了函數sub_4025B0，函數內容以下所示：


                    圖片三十六：收集系統信息
 函數sub_4025B0裏面大量的採集了操做系統的信息，應該是爲了發送給服務端，爲後續下載的惡意代碼兼容性提供數據支撐，線性分析發現sub_402070函數，收集的數據造成GET請求，包含了系統惟一標識及版本數據等信息，以下所示：

                    圖片三十七：GET報文造成
 數據也收集，下面就發送吧，sub_402890函數包含了完整socket操做，而且發送給了服務器，以下圖所示：

                    圖片三十八：send與recv
還有最後一個函數sub_402BA0，咱們繼續看一下，以下所示：

                    圖片三十九：socket

                    圖片四十：send Data
 經過上面數據咱們發現，仍在是在與服務進行通信，格式化拼接數據發送到服務器端，下面則是下載並寫入本地惡意代碼，以下所示：

                    圖片四十一：獲取絕對路徑
 以上C++代碼環境在windows10 64bit下測試，那麼意味了當前系統的該路徑而且寫入文件數據，比較有意思的，服務端下載的惡意代碼進行了數據解密，經過對文件光標選擇性讀寫數據，抽取真正執行的惡意代碼，而後建立線程，以下所示：



                    圖片四十二：選擇性惡意代碼讀寫
 爲何這樣作呢？爲了混淆免殺，下載下來的惡意代碼爲了不被殺毒軟件查殺，能夠在代碼中進行混淆，不管是從PE偏移點的改變或者是對一些敏感字符的匹配都有可能失效，躲避一些所謂的啓發式查殺，最後在本地生成真正的惡意代碼且執行，以下所示：

                    圖片四十三：運行惡意代碼文件
 最後在收集數據，調用sub_402890函數，也就是上面分析完整的socket操做，如上圖三十八所示，調用圖以下所示：

 最後是獲取了時間與僞隨機數，且這是一個大循環，又會回到當初分水嶺WSACleanup的地方，以下所示：

                    圖片四十四：數據提供
 ✍以上就是整個樣本的分析，其實發現有意思的是字符串獲取的方式以及惡意代碼下載後躲避啓發式查殺的手段。自己程序並不攜帶任何具備惡意性的操做，而是收集了當前系統大量的數據發送服務端（特洛伊），服務器端根據當前系統下載兼容的混淆惡意代碼，在本地進行文件解密且運行，惋惜是下載不下來惡意代碼了....
 最後，有興趣的朋友能夠到文章開頭中Crazyman_Army帖子中下載APT的樣本，學習研究一下。