此文發(fā)表于《電子數(shù)據(jù)取證與網(wǎng)絡犯罪調查》（第五輯），一度在硬盤里遍尋不見，幸好張老師有留存。年紀是大了，記性差許多vs 調試 找不到dll，還是覺得放在這里有個保障。今天是“人民警察節(jié)”，就以這種方式紀念下。
感慨：在分析木馬程序時，我會關心兩個問題，一是分析的最終目標是什么？應該是上線控制端；二是我經(jīng)歷了什么？就是在不斷抽絲拔繭過程中努力達成目標。當回頭總結時，才發(fā)覺作者平淡無奇之下隱藏著一顆玲瓏剔透的心(編程手法和技巧)，蘊含著他的思想和造詣，這也是木馬能不斷突破防線的原因。
曾以為，只是一次例行的勘驗，但恰如那句廣告詞，簡約而不簡單。最終我收獲了啟迪，打破了思維定式：①抓包分析中，始終抓不到上線地址，一度懷疑人生。后來才發(fā)覺：木馬在其體內設置了延時（14544秒=4小時）處理，對木馬程序我們根本不會抓包持續(xù)這么長時間；同時它對我們的使用習慣很了解：當長時間抓包時喜歡用輕量型的（我就是），但程序中恰恰對這款抓包工具進行特別限制，兩方面決定了我們抓取不到上線地址。②程序分析中，我忽略漏掉了sleep(時長)函數(shù)，編程中我們常使用sleep來緩沖延時，但僅僅是幾秒，沒想到木馬是4個小時，大跌眼鏡。③最后，作者用直接發(fā)送控制代碼來執(zhí)行相應的操作，這種情況在CS木馬中較少見。因為這種方式常見于木馬，多見于驅動程序中。但在深入調試跟蹤線程的過程中對值的含義沒查到文檔對其具體動作不詳，留下遺憾。
下面言歸正傳，開始分析過程。
一、現(xiàn)場情況
內網(wǎng)服務器一臺192.168.100.249， 2008，內網(wǎng)主機十幾臺，監(jiān)控設備若干。
二、勘驗過程
1、抓包：只發(fā)現(xiàn)訪問網(wǎng)站的行為，未發(fā)現(xiàn)有攻擊行為。
圖1
2、可疑程序分析
到現(xiàn)場后，發(fā)現(xiàn)業(yè)主用360掃了一堆可疑文件，其中就包括了這個系統(tǒng)目錄中的.exe文件。以下我們圍繞這個來展開。
1）.exe分析
當.exe運行后，會釋放兩個dll文件，這里為：ugmkn.dll和uvsln.dll（兩個dll名字每次生成都不同），放置在c:\\目錄下（圖2）。
圖2
發(fā)現(xiàn)系通過 .exe來加載運行dll（圖3、圖4），
圖3
圖4
.exe將自身加入注冊表啟動項，位于c:\\下（圖5）
圖5
.exe每啟動一次都會產生兩個不同名的dll文件（圖6），但互斥體(圖15)保證它不會重復運行，
圖6
這里出現(xiàn)一個問題（圖7），加載的dll的路徑指向，而實際dll文件又在下，導致該找不到該dll文件。但實際上又能運行，不影響它的加載，有點奇怪。這里涉及到和的區(qū)別，在64位系統(tǒng)中目錄下放置的是64位程序，而將32位程序放置在目錄下，微軟這么做也是繞人。所以，兩個32位的dll在目錄下存在，但工具標記顯示又在下，所以顯示為找不到，懷疑這是工具的問題。
圖7
2）ugmkn.dll的逆向分析
圖8
在此注冊表項（圖8）下，如果發(fā)現(xiàn)有這些殺軟，由發(fā)送控制碼干掉。
圖9
1FA0：，1630的上一層，禁掉微軟防火墻(圖10)；
圖10
沒找到這兩個文件（圖11），奇怪。
圖11
利用函數(shù)來執(zhí)行命令sc stop ，隱藏GUI（圖12）；
圖12
啟動aav服務（圖13）；
圖13
程序入口指向（圖14）：
圖14
執(zhí)行以下命令：
net stop
net stop
sc start=
sc start=
sc stop
.exe -k
總結：該ugmkn.dll功能為：停止安全防護服務或進程，創(chuàng)建 C:\ Files\KAV\.sys程序；創(chuàng)建啟動aav、服務。
3）uvsln.dll的逆向分析
3-1、函數(shù)：入口
圖15
（圖15）創(chuàng)建互斥體后，啟動了“、、”三個線程。
①線程：通過.dll(將c:\\\.dll復制成c:\users\\\local\tmp\3DBD.tmp)底層來調用連接193.166.255.171:8080（沒有使用傳統(tǒng)的bind、send之類的微軟函數(shù)），完成后關閉；這里間隔 14280秒訪問一次（圖16）。
圖16
②線程：通過.dll底層操作注冊表、文件項等，完成后關閉。
圖17
將自己復制到系統(tǒng)目錄中后，添加到啟動項（圖17）。
③線程:遍歷當前的盤符，循環(huán)執(zhí)行.exe
圖18-1
圖18-2
在圖18-1中有個函數(shù)，我跟蹤到線程中發(fā)現(xiàn)這里是創(chuàng)建盤符的虛擬文件創(chuàng)建（圖18-2）。
這里的=（圖18、圖19），
圖19-1
圖19-2
在圖19-2中跟蹤到時發(fā)現(xiàn)調用參數(shù)如圖中右下角所示的參數(shù)。
我們利用工具對:進行解讀（圖20）：
圖20-1
圖20-1中解讀出來，相當于語句：# (RAGE, 0x500, , )。這里的：0x500是微軟自留的內部功能，我沒查到它的具體含義，但查了網(wǎng)上很多都是0x500vs 調試 找不到dll，估計這是個固定搭配。有解釋為以上設備類型定義一個設備的唯一標識功能號（功能不詳），用十六進制表示，轉換為十進制后的有效范圍是：0-2047是保留給微軟，2048-4095是為OEM和IHV保留，其它功能代碼定義大于4095。在跟蹤調試的過程中發(fā)現(xiàn)這個0x500(圖19-2)還真是非常關鍵，雖然執(zhí)行后有了返回值但沒搞明白這個動作到底要做什么，有點遺憾！
在調試的過程中，始終達不到if (v5==7)這個條件，一直在圖18至圖20中循環(huán)，為了進入調試時就強行改變判斷進入，發(fā)現(xiàn)圖20-2，
圖20-2
我們來看看圖19-1中的函數(shù)：
圖20-3
作用是遍歷文件擴展名為’.exet’和最后一個字符為’t’的就刪除該文件；如果文件擴展名為’.exe’和最后一個字符為’e’的就執(zhí)行.exe文件；
，的一些說明，可了解下。
3-2、抓包分析
知道系加載dll，就對重點抓包，捕獲到193.166.255.171這個IP，我們現(xiàn)就對這個IP進行抓包（圖21）：
圖21
過了很久很久后，出現(xiàn)（圖22）了取指令包動作：
圖22
出現(xiàn)了ip:193.166.255.171指向的域名，url為 :8080/sa13/d.txt(已不可訪問)，懷疑是個指令文檔。通過逆向該段代碼及抓包驗證后，發(fā)現(xiàn)這個木馬很“鬼”，每隔14544秒(4個小時)的“潛伏”后再訪問（圖23）。這就解釋了當時我們在現(xiàn)場時沒有抓到這個域名的原因，這點給我們提了個醒。
圖23
（圖23）在整個抓包過程中，僅有數(shù)量很少的幾個包出現(xiàn)，很“謹慎小心”啊。
同時，在其體內發(fā)現(xiàn)有“.exe、”字符串（圖24）。是浩藝網(wǎng)吧收銀及管理軟件的主進程，有意思。如果窗口標題為“”就退出（不允許抓包）。
圖24
4）在對193.166.255.171查詢后，發(fā)現(xiàn)：這是個C&C（圖25），在這個IP下面羅列出了有這么多的木馬指向這里，紅框中列出的是我們這個木馬。
圖25
5）再次抓包查看進程（圖26），發(fā)現(xiàn)進程指向了（DAG生成新的域名），但ip:193.166.255.171:8080不變。
圖26
至此，程序分析完成。
三、結論
木馬構成：由.exe運行釋放出兩個dll文件，由來加載運行這兩個dll文件。其中一個dll與IP：193.166.255.171:8080的由DAG算法惡意生成的域名進行通訊。:8080/sa13/d.txt因失效而內容也不可知。
木馬特點：一是利用win底層直接硬編碼調用.dll(應用程序網(wǎng)絡相關模塊)，盡量少使用微軟函數(shù)，導入表中有些敏感函數(shù)都沒出現(xiàn)，使分析起來難度加大；二是由直接發(fā)送控制碼來操作，工具軟件無法監(jiān)測到；三是通訊時采取間隔4小時方式，非常隱蔽。
驅動文件.sys沒有找到而未開展分析。