總結

1.計算Sleep類函數延時時間與實際流逝時間是否匹配可判斷環境是否為正常。對沙箱來說，跳過Sleep節約時間成本是有必要的不可省去，但可適當處理GetTickCount類函數，使其與延時時間匹配。

2.對于動態解密，打好斷點動態分析比靜態分析省時間，至少對我這種剛上路的菜狗來說是這樣。

3.CertEnumSystemStore可作為CertEnumSystemStore替代品用于執行Shellcode。

前言

近日，筆者參加了浙江護網，在攻擊隊停止攻擊的那一天凌晨，Windows服務器被攻破大量失分，早晨溯源時拿到了這一份名為chrome.exe的木馬樣本。

木馬HASH

SHA256:7fbe93d7c29b4ea4ce918f3d16a74d2930120f44d00862bdc0a1f8289954e010 MD5:a5f06c8e88e200a860e83a6bdd197752 SHA1:7e5675f8c84b800a1290dd7422be1f10c2302c4d

正文

這份木馬被火絨報毒，從報毒界面可以得到關于此樣本的兩條信息，

64位Windows程序。

大概率是CobaltStrike后門。

既然很可能是CobaltStrike后門，那直接上傳哈勃、微步一把梭看一看木馬行為?？善婀值氖巧诚渚礄z測出網絡連接行為，且被鑒定為安全，這激起了我的好奇心。

拖入IDA，在主函數頭部發現了exit(0)，則五行偽C代碼很有可能是反沙箱的代碼，若是沙箱直接exit，非沙箱執行下邊的解密、執行操作。

為驗證這五行代碼是否起到我預料的效果，我用c實現了一份類似功能的exe準備傳入微步沙箱，若微步沙箱的程序運行截圖中存在"sandbox!!!"則代表檢測到沙箱。

#define HIDWORD(x) (*((DWORD*)&(x)+1)) //IDA int main() {int v3; // ebx__int64 v4; // kr00_8v3 = GetTickCount64(); // 反沙箱Sleep(300u);v4 = (int)(-300 - v3 + GetTickCount64());printf_s("v4:%d\n",v4);if ((int)((HIDWORD(v4) ^ v4) - HIDWORD(v4)) > 100)printf_s("sandbox!!!\n");elseprintf_s("none!!\n");system("pause");return 0; }

在微步沙箱中v4為負數，檢測到沙箱，而在自家Windows虛擬機內則返回正常，可見代碼有效。

猜測這段代碼的原理是沙箱為了節省運行時間，處理了Sleep或SleepEx類的API，導致此類API無法正常延遲，通過記錄時間檢測是否跳過延時即可判斷是否存在沙箱。

將jg條件跳轉噶了，避免其轉入exit，保存后傳入沙箱。?

可見能正常分析出網絡行為。?

運行完反沙箱部分便是解密shellcode，這里是帶key的xor解密。?

解密完畢后修改內存為PAGE_EXECUTE_READWRITE屬性用于后續執行shellcode。

此樣本另外有趣的一點是他沒有使用CreateThread的方式執行shellcode，而是使用Crypt32.dll中的CertEnumSystemStore，降低殺軟查殺樣本的可能性。

通過查詢微軟官方文檔可知，此API會為每個找到的系統存儲調用參數四提供的回調函數，這給shellcode提供了執行的機會。

為進一步分析加載器，需得到解密后的shellcode。

直接對CertEnumSystemStore下斷點，在執行前一刻dump下解密后的pfnEnum開頭的0x40255大小的內存，拖入IDA.?

shellcode開頭，調用sub_4022F，進入函數。?

開頭pop rdx將返回地址取到rdx，對返回地址后續進行一系列解密操作。在sub_4022f處下斷，重新dump整個shellcode(這里注意斷下后取消斷點再dump，否則會將軟件斷點int3 也dump下來)，拖入IDA。?

又是解密。依法炮制。?

這一次下方0X7D位置可見經典的PE程序特征了，未見MZ頭部，但可根據PE結構推測出文件頭位于0x2F位置,0x2F位置剛好又是MZ頭部，將DOS頭復用作為代碼執行空間，節省空間。

繼續看上方的loc_2F,MZ頭部的0x4D5A對應的pop r10后做了一次逆向操作，隨后調用了sub_16023.

進入25行的sub_16383。

根據讀gs:[60h]以及ROR4可以推測sub_16383主要功能是根據HASH獲取API地址。

在shellcode+0x160DF(sub_16383返回地址)打下斷點，將木馬運行起來，分析sub_16023的v13可知，

v13結構如下。

typedef struct _API {PVOID GetModuleHandleA;PVOID GetProcAddress;PVOID LoadLibraryA;PVOID LoadLibraryExA;PVOID VirtualAlloc;PVOID VirtualProtect; }API, * PAPI;

再下邊就是在內存展開、修復導入表...最后找到入口點并執行，所以sub_16383功能為內存加載Dll。

將Dll Dump出來，拖入IDA。

EAT中發現ReflectiveLoader,而原生CobaltStrike木馬所Map的Dll也同樣導出了ReflectiveLoader，且IAT也極為相似，基本可以判斷這個就是最后的功能DLL。

加載器部分分析完畢。

總結

1.計算Sleep類函數延時時間與實際流逝時間是否匹配可判斷環境是否為正常。對沙箱來說，跳過Sleep節約時間成本是有必要的不可省去，但可適當處理GetTickCount類函數，使其與延時時間匹配。

2.對于動態解密，打好斷點動態分析比靜態分析省時間，至少對我這種剛上路的菜狗來說是這樣。

3.CertEnumSystemStore可作為CertEnumSystemStore替代品用于執行Shellcode。

有價值的評論：

huoji120LV.5(這家伙太懶了，還未填寫個人描述！)

這能所謂的反沙箱是因為 沙箱會加速sleep但是不會加速gettickcount.導致前者和后者的時間結果不對.沙箱把gettickcount加速后就好了.但是國內的現在技術能力可能是不太行的

總結

以上是生活随笔為你收集整理的反沙箱CobaltStrike木马加载器分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。