可能有人會說這標題很瘋狂，但我把它稱之為“星期三”。

這款較為新穎的惡意軟件是一個老的2012 CVE的java攻擊包(可能針對SecurityManager)的負載。壓縮與解壓縮的在VirusTotal/Malwr上都沒有查到，所以這又是一個0day啊。

利用IDA進行初步檢測，報出一個錯誤：

估計制作這家伙的兄弟也知道, 遲早某一天它會被像我這樣的人拿來瞅瞅的。確實有許多的修改可以用來攪亂反匯編結果，而絲毫不影響Windows上的運行。

用CFF Explorer來看看，發現NT頭部的一個錯誤在“Data Directories”的“Delay Import Directory RVA”項中。CFF很好的為我們指出0×00000040值是錯的。將其清零就可以解決此問題。

保存修改的exe,在IDA中重新打開，之前的錯誤提示就消失了，一切正常。

在IDA里簡單的過一眼就可以知道這是一個MFC程序。我咋知道的呢?在導入表的Library字段很清晰的表明了。

當然了，該程序被壓縮了。沒有節表修改，典型的內存壓縮。

這就意味著靜態的分析不再有效，我們需要動態分析來獲得更多的信息。來吧，操起Immunity。

在開始immunity和虛擬機之前，exe文件里有些有趣的東西，沒有很明顯的在IDA里出現，但在CFF explorer里我們可以看到。首先，有幾個隱藏在資源目錄的文件凸顯出來。

第一個是PNG文件。

然后是一個html文件。

在IfranView(最好的圖像查看器)里瀏覽下該PNG文件，僅顯示了一個很小的黑圖片，這顯然不足55kb大小。所以，里面肯定隱藏了點啥。呆會再來收拾它。

來吧，到你了,html文件。用notepad++加載清理，可以看到一些瀏覽器檢測代碼：

為啥這里僅是簡單的放在了資源節表里，而不同其他代碼一起壓縮處理?真是個謎啊。先在腦海中記著這些資源節表，稍后處理。現在回頭來解壓這家伙。

首先開啟Immunity調試器和VirtualBox，加載我們的anti-anti-debug python插件。

現在將這貨運行起來，待其完全運行之后檢測內存。

可以看到有些內存區間被標記為可讀可寫可執行(RWE)，分別在00910000，00930000，00940000和00970000。檢測一番，發現4個當中僅有3個包含著代碼。該程序仍然有3個隱藏的代碼?太酷了吧。

現在我們要從內存中導出程序到文件里，便于后續的分析。使出OllyDumpEx，填入0090區間，可看到00910000和00970000的程序同原始的程序在大小、節表和屬性上都匹配。而00950000處的內存與其他的不同：有不同的節表，不同的大小。一定是隱藏著彩蛋啊。

利用‘Binary(Raw)’模式而不是重新構建模式導出exe文件，這樣可以保證導出的數據的完整性。

2個無用的節表表明程序被UPX進行壓縮了。運行upx工具確認了這一點。意味著我們可以砸出彩蛋了。

新的exe文件正確的解壓后多出了40KB，現在我們終于可以在IDA里瞅瞅了。看下strings，有些有趣的信息：

這是啥?HTTP請求信息。看起來這貨使用POST請求回傳數據啊。

你可能會問C&C服務器在哪呢?似乎不在程序的明文里。還記得前面提到的資源節表嗎?再來看看彩蛋的資源節表吧。

瞧，http://31.207.6.161。作者就這樣將其放在明文里，讓我們撿了個大便宜。想通過隱匿來獲取安全，沒門。

我知道你在想啥，主程序運行起來是啥樣呢?就讓我們來看看吧：

一運行起來，就自動的關閉了我的process explorer，我要運行任務管理器都會被一閃而過的消息窗提醒“任務管理器已經被管理員禁用”。 我也很想展示下截屏，但我動作實在沒它那么迅速。動用Immunity打開，發現原始的“golden_egg.exe”不再運行。另一個名為“zpNvNKSi.exe”的程序從臨時文件夾運行起來了。根據hash比較，其實是同一個程序：

喜歡我的哈希程序嗎?到這下載吧。

廣告時間結束了。現在很清楚該程序做啥了——禁用任務管理器，終止不受歡迎的程序，從臨時文件夾運行。檢查msconfig發現添加了2個自啟動文件。

我對它們都進行了檢查，確認正是原始程序的完全拷貝。

將程序附加到immunity，檢測程序內存和線程數目(“t”鍵)，顯示出該程序是多線程的。我數了下，12個線程。

我猜測這些線程互相監控對方，以防被終止。然而將主程序掛起，用Process Explorer打開它，觀察內存，通過檢測，發現了一些IDA strings未看到的內容：

大膽猜測一下，我認為這貨會檢查這些程序，如果發現它們運行就強制結束它們。這就解釋了當該程序運行時，process explorer為啥就被終止了。要運行這些工具就有點難了，有regedit，LordPE，wireshark，regmon，filemon，procmon，tcpview，taskmgr以及Windows Defender。吼吼，我沒看到Process Explorer的小伙伴Process Hacker啊。

再來說內存，上面表明程序要么是混淆了那些字符串，要么就是進行了再次的壓縮。不管哪個，把它揪出來。

對那些我們在Process Explorer中看到的字符串進行unicode格式的搜索，可以看到‘taskmgr’在.data節中。 關于這些字符串，難道IDA騙了我們?完全不是這樣的。再看一遍，慢慢的利用二分法搜索一遍，的確可以看到這些字符串。 我猜IDA進行搜索時，默認的不顯示unicode字符串。你可以在IDA中通過’alt+A’ 快捷鍵，選擇6選項來更改。

檢查這些新的unicode字符串，似乎該惡意軟件還有更多的功能。

這才有趣啊。因為這貨阻止了Wireshark的運行， 我們需要定位到負責終止功能的地方，并進行修復。咋做呢?對TerminateProcess() API調用進行定位。這在IDA里很容易就能做到。在導入節表里我們看到一個對TerminateProcess的引用。

似乎是段循環，利用“CreateToolhelp32Snapshot”API遍歷進程名稱，如果滿足條件，就終止掉它們。那些我們之前看到的黑名單似乎驗證了這一點。

那我們能做點啥呢?改變程序的運行邏輯，使其不再調用TerminateProcess，也就沒啥影響了。檢查該部分的外部引用(Xref’s, eXternal REFerenceS), 可以看到函數為00401D2A所調用。有個‘jnz’指令負責決定是否調用那段負責查詢、終止進程的過程處理。如果我們能修復這段程序，使其不再調用，將其跳過，就可以運行黑名單上的程序啦。

開搞吧。 我比較喜歡用immunity進行修復，一是它簡單，二來我也比較熟悉。定位到運行程序的子過程部分，進行條件跳轉的指令在‘0x00401d4e’。將那片區域進行nop填充，使得指令流返回，而不是跳轉到終止黑名單進程的00401d2c處。

繼續運行程序，開啟一個被黑名單的程序進行測試。“regedit”也可以正常運轉了，“process explorer”也沒有被終止，我們成功了。

現在我們可以利用wireshark進行仔細的網絡行為分析了，文件和注冊表的分析利用procmon，好好的擺弄Process Explorer處理吧。

用Process Explorer看到程序通過80端口向我們前面挖掘出的C&C服務器發送一個syn包。

Wireshark顯示的更多。可以看到發向HTTP C&C服務器的syn包，也有一串的向未知域名的DNS請求。這是咋回事? 

服務器會繼續回調，但我不想讓它這樣。可以修改“golden_egg.exe”中的資源節表，使其指向我自己的HTTP服務器，檢查它的功能。還有很多可以干的，現在我們已經獲得所需要的了，有了C&C地址，解壓了程序，也有了它的HTTP特征以及它的行為。案子就這樣結束了。又是一個收獲的“星期三”啊。

如果你想下載該惡意程序，自己進行分析，可以在此進行下載，密碼是‘infected’。

來源聲明：本文來自Joe Security的博文《0day Wednesday——Newish Malware That Came Across My Desk》

原文地址：http://www.gironsec.com/blog/2013/12/0day-wednesday-newish-malware-that-came-across-my-desk/