1. 程式人生 > >惡意程式碼分析實戰 Lab19

惡意程式碼分析實戰 Lab19

lab19-01

1IDApro開啟看到解碼程式碼如下


od除錯的時候顯示說無法作為及時偵錯程式除錯,所以只能用windbg,雖然麻煩了點

解碼後程序先跳到003a0464


接著在464處,馬上呼叫003a03bf函式


步入檢視程式又呼叫003a039e函式


步入檢視函式,這段函式很短,可以很容易看出來是在得到kernel32的base地址,看30h是的搭配peb結構地址,1ch是得到InInitializationOrderLinks連結串列項,並且得到第二個連結串列項的偏移8的dllbase,這裡認為kernel是第二個被初始化的,win7下就不一定是這樣了.


接著返回函式,注意到接下來呼叫了很多的003a0352函式,可以知道這個函式是得到一些kernelAPI地址的函式


進入003a0352函式檢視,注意到函式003a0331函式呼叫,推測這是得到雜湊值的函式,注意到後面的比較就知道不難推測這個函式作用,這裡的24h是kernel的base也就是第一個引數,kernelbase+3ch為了得到PE頭地址,然後78h得到的是匯出表的rva


所以edx現在是匯出表地址,他的18h偏移是numberofnames,1ch偏移是addressoffunctions,20h是addressofnames,24h是addressofnameordinals

所以不難看出來上面函式在偏移20h的addressofnames

看一下雜湊演算法,可以看到是跟課本一樣


為了知道6次呼叫都得到那些API地址可以在函式003a0352內部jne後面一個mov指令設定斷點然後db esi檢視函式名,如第二次是得到GetSystemDirectoryAPI地址


通過這種方法知道分別得到loadlibrary GetSystemDirectory Terminateprocess getcurrentProcess winExec這五個API地址

得到這幾個API之後首先呼叫ebp-4也就是loadlibrary引數是eax裡面的URLMON.dll



接著得到urldownloadtofileAPI地址放在ebp-18h


接著呼叫ebp-8的GetSystemDirectory


接著呼叫ebp-18h就是urldownloadtofileAPI我們看一下引數url和filename就好


接著呼叫ebp-14h執行那個1.exe程式


然後呼叫ebp-10h得到當前程序控制代碼,然後呼叫ebp-ch結束當前程序


分析結束

lab19-02

函式先提權

然後呼叫sub_401000函式,這個函式得到如下字串,得到的是系統預設瀏覽器的絕對路徑名


函式sub_401180函式是執行這個瀏覽器


接著sub_401230實現shellcode注入,shellcode在asc_407030


跳到asc_407030處按c使得IDApro將他識別為程式碼


看到解碼很簡單異或E7就好,我用winhex將這段shellcode拷貝出來儲存在shellcoade19-02.bin然後在和E7異或,最後用IDApro開啟就可以靜態分析shellcode的原始碼了

會發現程式的幾個函式呼叫和流程和我們之前分析的lab19-01很像,同樣的到kernel32,dll的base

然後得到loadlibrary的地址

接著呼叫loadlibrary得到ws2_32.dll


為了動態分析,使用lab19-01同樣的分析方法可以得到








得到兩個dll所需要的API後,呼叫如下函式


然後是建立套接字


建立連線


看下引數sockaddr其中02c8a8c0指的是ip192.168.200.2(c0:a8:c8:02) 1234 0002指的13330(0x3412)埠和2(AF_INET)


連線成功會建立cmd程序,建立反向shell

注意建立程序之前的引數設定,下圖這裡的esp為startupinfo結構體,他的48h開始是程序的標準輸入標準輸出和標準錯誤,都被賦值為eax(來自esi來自之前建立套介面的返回值)

    



最後會呼叫getcurrentprocess和terminateprocess結束程序



執行結果反向shell成功


lab19-03

用推薦工具檢測是否存在指令碼


然後winhex開啟pdf,搜尋JavaScript

將那一段拷貝出來得到找到攻擊負載



找到負載就可以用課本提供指令碼提取處shellcode,然後用課本提供那個.exe執行惡意程式碼,動態分析了

要知道都得到那些API的地址的方法之前兩個程式碼分析已經講過不再贅述,直接給出結論,匯入如下函式


直接看程式碼

分配堆


設定檔案指標,然後讀取資訊到之前建立的堆中(sub_13D內部會呼叫readfile)


得到臨時檔案目錄


再sub_EB內部會建立檔案foo.exe,然後會把之前堆裡面的資料寫到檔案


然後建立foo.exe程序


後面是基本一樣的操作,又寫了一個bar.pdf檔案再臨時檔案目錄下

最後呼叫shellExecute啟動這個pdf檔案,檔名在第三個引數向上追溯就知道對那個檔案操作


這個程式沒有動態分析驗證,是因為覺得前面兩個分析的夠多了,這個程式碼也不難看出,只要知道了每個call都是在呼叫那個API(像我上面那樣註釋)就不難理解程式碼主要在做什麼,當然很多細節沒有分析道,畢竟只是靜態分析,比如每個函式的引數具體是什麼如果沒有動態分析是很難確定的,但是不妨礙我們靜態分析推測,比如上面的一些對檔案的操作,我們不難推測都是對原來的.pdf檔案的讀寫操作,顯然後面寫的兩個exe和.pdf檔案之前都存在最開始的.pdf檔案,這是很顯然的,即使不用動態分析我們也應該有這樣的自覺

分析結束