應急響應中分析64位惡意dll的小故事
*本文作者：tahf，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載。
前言
作為一名沉迷於安全技術的小白，近期在對公司一臺Win7客戶主機進行安全應急響應時，捕獲到一個64位dll形式的惡意程式，於是對其展開分析，收穫很多。下面想結合取證分析的過程，從取證經過、動靜態分析、破解加密等角度入手，與大家分享一些綜合性的惡意程式分析方法，相互啟發，相互學習。也許有些方法比較基礎，望各位大佬勿噴~
提供dll樣本以便大家茶餘飯後分析著玩玩~
連結： ofollow" rel="nofollow,noindex" target="_blank">https://pan.baidu.com/s/1y7ylCgRU2khpVaYhlIngsw 密碼：xut0
取證經過
某使用者向SRC反映最近自己的郵箱賬號被盜，作為應急中心的一員，我與團隊成員一起對該使用者的電腦進行了初步的取證和排查。
個人對個人主機排查的常用思路是：
可疑程序
網路流量
啟動項
檔案比對
但為了達到攻擊持久化的目的，惡意程式往往會對系統進行駐留，因此對啟動項進行檢測排查是一個非常重要的環節。下面先推薦一款比較好用的常規自啟動檢測工具。
autoruns.exe
是一款出色的啟動專案管理工具，作用就是檢查開機自動載入的所有程式，例如硬體驅動程式，windows核心啟動程式和應用程式。它比windows自帶的msconfig.exe還要強大，通過它我們還可以看到一些在msconfig裡面無法檢視到的病毒和木馬以及惡意外掛程式，還能夠詳細的把啟動專案載入的所有程式列出來。比如logon、explorer還有IE上載入的dll跟其它元件。
但autotuns也不是萬能的，比如dll劫持等部分特殊的啟動方式也無法檢測到。作為取證人員，平時應該多多蒐集和積累攻擊者使用的奇淫巧技。
由於個人在對dll劫持方式有較多的瞭解和實踐，同時結合檔案比對，終於發現主機` C:\windows\` 目錄下多了一個叫midimap.dll的動態庫，基本可以斷定為可疑程式，便對其展開分析。
動靜態分析
首先我們對載入該dll的程序做了監控和分析。
dll劫持技術分析：
根據以往經驗，可以利用工具和相關命令迅速確定是哪些程序載入了這個midimap.dll，推薦2種簡便方法。
tasklist /m XXX.dll
以管理員許可權執行` tasklist /m` 命令，可以獲得所有程序中載入的動態連結庫，也可以具體到某一個dll對應的程序，見下圖。
Process Explorer
非常好用的一款增強型工作管理員軟體，讓使用者能瞭解看不到的在後臺執行的處理程式，能顯示目前已經載入哪些模組，分別是正在被哪些程式使用著，還可顯示這些程式所呼叫的 DLL程序，以及他們所開啟的控制代碼。
綜上，可確定是explorer.exe程序載入了midimap.dll。
同時，我們利用一臺乾淨的win7虛擬機器對explorer.exe載入midimap.dll的過程進行了分析。使用Process Monitor軟體對explorer.exe程序的行為進行了監控並設定了過濾條件，如下圖。
可發現正常情況下，explorer.exe應載入位於` C:\windows\system32\` 目錄下的midimap.dll，但由於exe載入dll有一定的搜尋順序，會首先在同目錄下查詢對應的dll檔案。因此將惡意的midimap.dll檔案放置在` C:\windows\ ` 目錄下即可實現dll劫持。
行為分析
除了對惡意程式進行直接的靜態分析和動態跟蹤除錯，我們還常使用其他工具和手段對惡意程式的行為進行監控和分析，尤其在對一些較難逆向的複雜程式進行分析時，結合行為監控將大大提高分析效率。這裡也簡單介紹2款工具。
Procmon
Process Monitor是一款能夠實時顯示檔案系統、登錄檔與程序活動的高階工具，是微軟推薦的一個系統監視工具。增加了程序ID、使用者、程序可靠度、等等監視項，可以記錄到檔案中。它的強大功能足以讓其成為你係統中的核心元件以及病毒探測工具。
檔案監控軟體
利用檔案監控軟體往往能對惡意程式的讀寫的檔案的路徑進行快速定位。
在對該惡意動態庫進行分析時，我們使用Procmon工具對explorer.exe（載入惡意dll）程序的行為進行了監控，在敲擊鍵盤和移動滑鼠時，會伴有檔案讀寫的行為，定位到` C:\Users\Windows\Appdata\Local\Microsoft\Windows\Caches\caches_version.db` 疑似為惡意程式產生的記錄檔案。
使用010editor開啟caches_version，疑似加密的記錄檔案。
靜態分析
用IDA對正常路徑` C:\windows\system32\` 下的midimap.dll與在` C:\windows\` 下的惡意midimap.dll進行對比。可見惡意dll匯出函式與正常dll的完全相同。
但對惡意程式進行初步分析後，可發現其實現了函式轉發，將功能的呼叫轉至正常路徑下的動態庫。
下圖是從惡意dll中提取的字串資訊，根據經驗，再結合函式匯入表中呼叫` GetKeyState，GetClipboardData，GetWindowsTextA` 等函式，基本可以確定該惡意dll的大致功能，即為鍵盤記錄工具。
目前，惡意dll的功能基本有了大致的判斷，下面我們希望通過動態除錯的方式來嘗試將加密的記錄檔案caches_version中的內容進行解密。
破解記錄加密演算法
下一步我們希望通過靜態分析+動態除錯該dll的方式來破解記錄的加密演算法。
由於它是一個x64的dll，可使用x64dbg工具來除錯（可切換至中文）。
分析發現惡意dll在dll被載入後，在DllMainCRTStartup中建立了一個執行緒，該執行緒為鍵盤記錄執行的執行緒。
由於新建立的執行緒是惡意功能運轉的執行緒，應跳入該執行緒中進行除錯。這裡遇到個小坑，一開始想通過x64dbg跳入新建立的執行緒中進行除錯，在新執行緒地址設定了軟硬體斷點，但除錯過程中總是異常退出，懷疑與x64dbg的Dllload64.exe有關。所以我自己用VS2010寫了一個x64的exe使用loadlibrary來載入這個惡意dll。用x64dbg來除錯該exe，在dll被load後，可在記憶體模組中找到這個dll，並在dll中搜索跨模組呼叫函式，線上程地址處下硬體斷點，即可成功跳入執行緒中除錯。
同時，可以搜尋當前模組中的所有字串，來找到其記錄的路徑。或者除錯下CreateFile也可以。
該路徑下caches_version.db檔案就是記錄擊鍵結果的加密檔案，與前期行為監控的結果一致。
我們若想還原出加密檔案的內容，便可以對惡意程式中呼叫讀寫檔案函式的上文進行分析。一般都是對資訊加密後再寫入檔案。因此容易找出加密寫入檔案的函式，sub_180001820(LPCVOID lpBuffer)，通過F5轉換為虛擬碼，經過分析，對虛擬碼的功能進行了註釋。
注意到一個長度為6的字串，而且在程式碼中為引用了3次，後面兩次均為生成加密表用。
重點看sub_1800025B0和sub_1800026B0兩個函式（在sub_180001820被呼叫），動態除錯下，可以發現sub_1800025B0函式每次生成的東西都是一樣的。
再分析除錯sub_1800026B0函式。
一樣的問題，sub_1800026B0函式中每次生成的變換表也是一成不變的。也就是說我們通過動態除錯得到的第2個表總是不變的，那麼我們就可以直接將其提取出來，而不必分析前面生成它的演算法，大大節省了時間！然後我從生成完這個表的之後開始除錯，思路是用C語言來記錄各個暫存器的操作，在棧中被加密和地址和加密用的表可以當作陣列處理。
最終整理髮現，所以被加密的位元組永遠都是異或0xE7來實現加密。所以解密其記錄檔案時，只要異或一個0xE7即可。之前看似複雜的加密過程，沒想到完全沒有加入隨機性，最終其只不過是簡單異或加密而已，這應該是攻擊者在設計加密演算法時的重大失誤。解密後的檔案如下圖。
同時也說明在做加密時，一定要增加演算法的隨機性，比如可以根據前一個輸入來生成加密的表，讓前後有關聯性。否則只是單位元組一對一的加密，都可以不分析演算法，直接試驗一些輸入再分析下輸出即可搞定！（比如：在分析記錄路徑時，可以使用檔案監控程式，然後不斷敲擊鍵盤，由於其程式需要不斷想某檔案中寫入資料，所以檔案監控很容易抓到這種頻繁的改動，從而得出路徑。在加密方面，可以先判斷其是否是單位元組一對一變換，這種可以通過連續敲入10個字母a，10個字母b來驗證，如果加密記錄結果中有連續出現10個同樣的位元組，說明其加密很有可能是單位元組一對一變換。那麼就很容易繞過其加密演算法實現解密。）
感悟
這次是自己第一次分析並除錯x64的dll，既積累了分析dll劫持的方法手段，又對x64dbg工具有了更多的實踐，並填補了跳入執行緒除錯的小坑。作為一名踏上安全之路的技術小白，在低頭忙於手頭工作的間隙，抬頭眺望遠方，深感安全之路漫長曲折。雖然在學習和實踐技術時總會跳入各種坑，也常常被難題卡住，一路艱難困苦。但只要不放棄，不忘初心，總有一天當你驀然回首，會發現之前挖過的坑，熬過的夜，吃得的苦，受過的寂寞都是一名安全從業者路途中最動人的風景~ 共勉~
*本文作者：tahf，本文屬 FreeBuf 原創獎勵計劃，未經許可禁止轉載。