Книга: Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software
Назад: Lab 1-4 Solutions
Дальше: Lab 3-2 Solutions

.

shows that only kernel32.dll is imported.

. We begin by clicking Lab03-01.exe in the process listing and select View ▸ Lower Pane View ▸ Handles. In this view, we can see that the malware has created the mutex named WinVMX32 at . We also select View ▸ Lower Pane View ▸ DLLs and see that the malware has dynamically loaded DLLs such as ws2_32.dll and wshtcpip.dll, which means that it has networking functionality.

. We include RegSetValue and WriteFile to show changes the malware makes to the filesystem and registry.

. Notice that there is only one entry for WriteFile, and there are nine entries for RegSetValue.

, we often need to filter out a certain amount of noise, such as entries 0 and 3 through 9 in . The RegSetValue on HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed is typical noise in the results because the random number generator seed is constantly updated in the registry by software.

We are left with two interesting entries, as shown in at and . The first is the WriteFile operation at . Double-clicking this entry tells us that it wrote 7,168 bytes to C:\WINDOWS\system32\vmx32to64.exe, which happens to be the same size as that of the file Lab03-01.exe. Opening Windows Explorer and browsing to that location shows that this newly created file has the same MD5 hash as Lab03-01.exe, which tells us that the malware has copied itself to that name and location. This can be a useful host-based indicator for the malware because it uses a hard-coded filename.

, which matches the strings listing shown earlier. (To be sure that the malware has a chance to make additional DNS requests, if any, perform the analysis process a couple of times to see if the DNS request changes or use the NXDOMAIN functionality of ApateDNS.)

We complete the network analysis by examining the Netcat results, as shown in the following listing.

C:\>nc -l -p 443 \7⌠ëÅ¿A :°I,j!Yûöí?Ç:lfh↨O±ⁿ)α←εg%┬∟#xp╧O+╙3Ω☺nåiE☼?═■p}»╝/ º_∞~]ò£»ú¿¼▬F^"Äμ▒├ ♦∟ªòj╡<û(y!∟♫5Z☺!♀va╪┴╗úI┤ßX╤â8╫²ñö'i¢k╢╓(√Q‼%O¶╡9.▐σÅw♀‼±Wm^┐#ñæ╬°☻/ [⌠│⌡xH╫▲É║‼ x?╦ƺ│ºLf↕x┌gYΦ<└§☻μºx)╤SBxè↕◄╟♂4AÇ

It looks like we got lucky: The malware appears to beacon out over port 443, and we were listening with Netcat over ports 80 and 443. (Use INetSim to listen on all ports at once.) We run this test several times, and the data appears to be random each time.

A follow-up in Wireshark tells us that the beacon packets are of consistent size (256 bytes) and appear to contain random data not related to the SSL protocol that normally operates over port 443.

sss
sss

© RuTLib.com 2015-2018