這篇文章將為大家詳細講解有關CS偽裝下的loader樣本該怎么分析，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

10年積累的成都網站制作、成都做網站經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站制作后付款的網站建設流程，更有澤庫免費網站建設讓你可以放心的選擇與我們合作。

0x01 開源情報收集

樣本下載鏈接：https://app.any.run/tasks/ffc1ecff-e461-4474-8352-551db7e7b06f/

常用平臺:VT，微步，哈勃 app.any.run, joesandbox

圖一：VT檢測

木馬實錘

沙箱跑一下看一下行為：

圖二：沙箱行為分析

可以看到用GET請求訪問C&C服務器下載了一個二進制binary文件。

點開binary文件查看詳情：

圖三：惡意binary

dump下來wireshark數據包，過濾http請求同樣可以發(fā)現該二進制文件

圖四：抓包分析

查詢C&C服務器ip：

圖五：ip檢測

現在對該惡意軟件已經有了初步了了解，下面進行數據包分析，看看能不能找到有用的信息。最直觀的看到就是使用了非常見的端口連接，還有發(fā)現一個有趣的現象：

圖六：數據包分析

竟然是肉雞主動連接的C&C服務器，讓我聯想到了CS馬。這種手法類似于反彈shell，好處就是可以繞過防火墻限制，如果對方是內網ip，你無法直接發(fā)起連接請求，方便持久化控制等等。

0x02 樣本基本信息

用exeinfo查殼，標準的32位VC編譯的程序

圖七：樣本信息

用Process Monitor監(jiān)控行為

圖八：軟件行為

具體每一項的圖略了，大概看了一下讀取了注冊表的某些鍵值，設置了某些鍵值對的值，很多對IE瀏覽器的設置，代理，Cache等等。用createfile()函數讀取了本地一些文件，但是沒有在磁盤創(chuàng)建文件的行為，也沒有刪除文件的行為。網絡行為監(jiān)控可以看到send,receive動作，應該是從C&C服務器接收了下一階段的惡意負載。重點看了一下注冊表里面沒有找到用于持久性控制的鍵值修改。

0x03 binary分析

IDA靜態(tài)分析

原則：先靜后動
載入IDA看一下導入表,看到了很多標志性的API
反調試：

查詢用戶默認區(qū)域，呦呵，還是有針對性的呀

反調試：

分配內存，因為惡意樣本會從C&C接受binary文件，但是沒有寫入磁盤，猜測就是用來這個API開辟了一段內存空間，在內存中執(zhí)行payload。

但是有一點很疑惑，沒有看到與網絡操作有關的API函數和庫。

看靜態(tài)字符串

靜態(tài)分析程序流程

就兩個函數，我重點分析了第二個函數sub_453960(),因為第一個函數點進去看沒有什么實質性的操作，在初始化處理，創(chuàng)建互斥體等等。

我采取的辦法是直接對照著IDA，在OD中把第二個函數完整的執(zhí)行了一遍，花費了大概三個半小時，這估計是最笨的方法了吧。但是至少搞清楚了程序流程。關鍵函數是sub_4534B0()，在它來到關鍵函數之前，惡意軟件還設置了某幾個文件夾的屬性，如C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Cookies，難道要竊取cookie？

調試后定位到關鍵函數，其實這個應該就是主函數，ida沒有識別出來：

程序用VirtualAlloc()開辟了一段內存，&unk_515000里面存的是程序硬編碼的payload，sub_44F3DC()的作用相當于strcpy()，將payload復制到v1，然后把v1當函數執(zhí)行。其實payload就是一段機器碼。從00515000—0051531F，更有意思的是在payload尾部發(fā)現了C&C服務器的ip地址。而且之后調試發(fā)現，整個程序都是使用的這種手法來執(zhí)行自己的payload。

payload分析：

OD動態(tài)分析

第一步：關閉樣本的aslr，方便進行分析和調試。
載入peview

偏移是15E，放入hex編輯器，我看很多大佬都用010editor

修改完成后，載入OD即可
反調試是用hideod過的，手工也可以，直接修改PEB塊中的值。
直接從關鍵函數處開始展示：

因為是32位系統(tǒng)，默認是eax寄存器存放函數返回值，調用完VirtualAlloc()后返回值存放的是分配內存的首地址，0002000，也就是說payload會被復制到這里，并執(zhí)行。

并且該內存頁屬性，RWE，符合條件。

數據窗口跟隨，在執(zhí)行完sub_44F3DC()后payload被復制于此。

程序開始執(zhí)行payload，經過對payload的調試，作用是通過loadlibrary()函數加載wininet庫，這也解釋了為什么在導入表里面沒有找到與網絡操作相關的API函數信息。找到所需API函數地址后，開始與C&C服務器通信。

我們直接對00020068和0020086處下斷點即可。調試的時候可以很明顯的感覺到有時鐘機制在阻礙動態(tài)分析，直接在關鍵點下段，繞過即可。

00020068處是進行網絡通信時用到的API函數的ASCII碼

00020086處用了一條jmp eax指令來執(zhí)行API函數

因為之前通過沙箱分析和流量分析知道，第一個樣本會連接C&C服務器下載第二段payload，大體思路就是通過VirtualAlloc()函數分配一塊內存，然后通過InternetReadFile()指令讀取payload到內存。

查了一下VirtualAlloc()傳參次序：

LPVOID VirtualAlloc{
LPVOID lpAddress, // 要分配的內存區(qū)域的地址
DWORD dwSize, // 分配的大小
DWORD flAllocationType, // 分配的類型
DWORD flProtect // 該內存的初始保護屬性
};

從右向左進行傳參，網上查了一下，當Address參數為null時，系統(tǒng)將會決定分配內存區(qū)域的位置，并且按64-KB向上取整(roundup)。

這個位置是隨機的，之后會調用InternetReadFile()，將第二段負載讀到此處。

此處下一個硬件執(zhí)行斷點

第二段payload已經被讀入

程序開始執(zhí)行第二段payload

循環(huán)解密payload

解密出來就是一個PE文件

把PE文件dump出來
查殼

一個dll文件

VT分析

之前分析復現過APT28的一個樣本，手法和這個程序差不多，最終也會釋放一個惡意的dll。Dll文件有的是用rundll32執(zhí)行，有的是直接在內存里加載dll，執(zhí)行里面函數，這樣dll就不用落地了，就算exe程序被捕獲了，dll核心功能也不會被獲取到。本例中是直接在內存中進行執(zhí)行。

說一下要點：因為之前有CTF經驗，在靜態(tài)分析時快速識別出來base64算法和AES算法。
Base64碼表：

Base64算法實現：

‘=’補齊：

發(fā)現了用于AES加密的S盒：

標準的HttpSendRequestA系列API進行網絡請求：

動態(tài)調試時，發(fā)現了url。

通過分析數據包，原本以為像普通馬一樣，收集本機敏感信息，壓縮上傳至C&C服務器，結果這個馬更加狡猾。這個惡意的dll相當于還是一個downloader，它通過去連接這個url，類似于心跳包檢測的機制，根據頁面回顯或提前設置好的標志位，來決定執(zhí)行的操作。是執(zhí)行惡意功能還是sleep。執(zhí)行惡意功能應該就是去下載真正的惡意負載。

0x04攻擊流程

這個樣本的適用場景應該是APT組織攻擊或紅隊攻擊中，通過滲透測試成功向目標上傳了CS馬，但是由于CS的易檢測的特制，不適于現代實現持久化控制的目的。所以在cs馬中硬編碼了一段payload，與C&C服務器進行通信下載了一個binary。通過xor操作達到免殺的目的，這個binary的作用相當于一個downloader，用于下載下一階段的惡意負載。通過對請求的url的判斷，提高了自己的隱蔽性，在合適的時機被攻擊者喚醒。樣本還有一個亮點是全程沒有落地，通過VirtualAlloc()分配內存，將payload復制進內存進行執(zhí)行，給我逆向分析的過程中帶來了不少的麻煩。樣本檢測通過社區(qū)的yara規(guī)則即可檢測為惡意樣本。

0x05 IOC

Main object :“3F37FC95AA5C8F7C304AA0DFC3FFBF2E”
SHA256: F6E04B3710044F76666468559FD2B6688CCAC091284D138E461C2257C387D7D3
SHA1: 4BB7B4AE2CC8C5D6C8EF1704A9B027878190D028
MD5: 3F37FC95AA5C8F7C304AA0DFC3FFBF2E
Connections
IP 8.210.181.149
HTTP/HTTPS requests
URL http://8.210.181.149:16678/activity
URL http://8.210.181.149:16678/9jhQ

0x06 關聯分析

關聯分析用的是奇安信的平臺

關于CS偽裝下的loader樣本該怎么分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

分享文章：CS偽裝下的loader樣本該怎么分析
文章網址：http://chinadenli.net/article6/gjcjog.html

成都網站建設公司_創(chuàng)新互聯，為您提供軟件開發(fā)、響應式網站、網站收錄、定制開發(fā)、網站制作、云服務器

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯