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

, which performs process replacement on svchost.exe.

  • If you force the jumps at 0x4019A1, 0x4019C0, and 0x401467 to be taken, and the jump at 0x401A2F to not be taken, the malware performs process replacement using a keylogger from its resource section.

  • The malware uses four different anti-VM techniques:

    • It uses the backdoor I/O communication port.

    • It searches the registry key SYSTEM\CurrentControlSet\Control\DeviceClasses for the string vmware.

    • It checks the MAC address to see if it is the default used by VMware.

    • It searches the process list with a string-hashing function for processes starting with the string vmware.

  • To avoid the anti-VM techniques used by this malware, you can remove VMware tools and modify the MAC address.

  • In OllyDbg, you can apply the following patches:

    • NOP-out the instruction at 0x40145D.

    • Change the instructions at 0x40199F and 0x4019BE to xor eax, eax.

    • Modify the instruction at 0x40169F to jmp 0x40184A.

  • .

    ). This script identifies one anti-VM instruction at 0x401AC8 and highlights it in red. We notice that this is the backdoor I/O communication port being queried via the in instruction. This anti-VM technique is contained in the function named sub_401A80 by IDA Pro. This function returns 1 if it is executing inside a VM; otherwise, it returns 0. There is only one cross-reference from the beginning of the main function, as shown at in .

    to the output from Lab17-03.exe. The following are the new strings found in this lab:

    shows the cross-reference graph for sub_4011C0. The arrows leaving sub_4011C0 show that it calls several registry functions. The function also calls itself, as shown by the arrow that loops back (making it a recursive function). Based on the graph, we suspect that the function is recursively checking the registry for the string vmware. Finally, shows that sub_4011C0 is called from main.

    shows where sub_4011C0 is called at inside the main function. Three parameters are pushed onto the stack before the call, including the registry key, which we saw in the strings listing.

    . If you examine sub_4011C0 further, you will see it loop through the registry subkeys under DeviceClasses. It compares the first six characters (after changing them to lowercase) of each subkey name to the string vmware.

    Since our goal is to have the malware run in our safe environment, we just need to ensure that the jz instruction at is taken; otherwise, the program will terminate immediately. We disable this anti-VM technique by making sure the zero flag is 1 when we arrive at the jz instruction. We can permanently disable this check by changing the test instruction at into xor eax, eax using OllyDbg, as described in .

    Next, we use IDA Pro to check the cross-references for the string GetAdaptersInfo. In , we see the string referenced at .

    that loaded the resource section containing the keylogger. However, the function in this lab appears to have a bunch of code added to the start. Let’s examine that code.

    shows the start of a series of byte moves at . This byte array initialization can be converted to a byte array by double-clicking var_38 and setting it to an array of size 27. We rename the array to Byte_Array to aid our analysis later on.

    takes two parameters: a linked list of IP_ADAPTER_INFO structures and the size of that linked list. Here, the linked list passed in is NULL, and the size will be returned in dwBytes. Calling GetAdaptersInfo_Address with the first parameter set to NULL is an easy way to figure out how much data it returns in order to allocate memory for the linked list structure to be used in a second call to GetAdaptersInfo_Address. This is the reason the malware uses dwBytes in subsequent calls to GetProcessHeap and HeapAlloc.

    shows that the malware uses HeapAlloc at and calls GetAdaptersInfo_Address a second time at .

    at , , and .

    shows the code listing before we apply the IP_ADAPTER_INFO structure offsets and standard constants to the data. To apply the structure, right-click the locations , , and , and you will be given the option to turn numbers into the descriptive strings shown in bold in the right side of the table. Using the MSDN page for IP_ADAPTER_INFO as reference, we learn about the standard constants for Type and see that 0x6 and 0x71 correspond to an adapter type of Ethernet or 802.11 wireless (so the address will be a MAC address).

    In the three comparisons shown in , the malware is checking for Ethernet or wireless interfaces, and then confirming that the adapter address length is greater than 2. If this check fails, the malware loops to the next adapter in the linked list. If the check succeeds, the code shown in will execute.

    shows a call at , which determines if the jz at will be taken. If the jump is not taken, the code will terminate without performing the process replacement.

    sss
    sss

    © RuTLib.com 2015-2018