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

, we know that we are probably dealing with some form of process injection. Therefore, our first goal should be to determine the code that is being injected and into which process. Examining the strings in the malware, we see some notable ones, including explorer.exe, Lab12-01.dll, and psapi.dll.

Next, we use basic dynamic techniques to see what the malware does when it runs. When we run the malware, it creates a message box every minute (quite annoying when you are trying to use analysis tools). Procmon doesn’t have any useful information, Process Explorer shows no obvious process running, and no network functions appear to be imported, so we shift to IDA Pro to determine what is producing the message boxes.

A few lines from the start of the main function, we see the malware resolving functions for Windows process enumeration within psapi.dll. contains one example of the three functions the malware manually resolves using LoadLibraryA and GetProcAddress.

, we should rename dword_408714 to myEnumProcessModules at .

After the dynamic resolution of the functions, the code calls dword_408710 (EnumProcesses), which retrieves a PID for each process object in the system. EnumProcesses returns an array of the PIDs referenced by the local variable dwProcessId. dwProcessId is used in a loop to iterate through the process list and call sub_401000 for each PID.

When we examine sub_401000, we see that the dynamically resolved import EnumProcessModules is called after OpenProcess for the PID passed to the function. Next, we see a call to dword_40870C (GetModuleBaseNameA) at , as shown in .

will execute, and the handle hProcess will be used to manipulate the process.

, we see a call to VirtualAllocEx at . This dynamically allocates memory in the explorer.exe process: 0x104 bytes are allocated by pushing dwSize at . If VirtualAllocEx is successful, a pointer to the allocated memory will be moved into lpParameter at , to be passed with the process handle to WriteProcessMemory at , in order to write data to explorer.exe. The data written to the process is referenced by the Buffer parameter in bold.

In order to understand what is injected, we trace the code back to where Buffer is set. We find it set to the path of the current directory appended with Lab12-01.dll. We can now conclude that this malware writes the path of Lab12-01.dll into the explorer.exe process.

If the malware successfully writes the path of the DLL into explorer.exe, the code in will execute.

, the calls to GetModuleHandleA and GetProcAddress (in bold) will be used to get the address to LoadLibraryA. The address of LoadLibraryA will be the same in explorer.exe as it is in the malware (Lab12-01.exe) with the address of LoadLibraryA inserted into lpStartAddress shown at . lpStartAddress is provided to CreateRemoteThread at in order to force explorer.exe to call LoadLibraryA. , we select explorer.exe in the process listing, and then choose View ▸ Show Lower Pane and View ▸ Lower Pane View ▸ DLLs. Scrolling through the resulting window, we see Lab12-01.dll listed as being loaded into explorer.exe’s memory space. Using Process Explorer is an easy way to spot DLL injection and useful in confirming our IDA Pro analysis. To stop the pop-ups, we can use Process Explorer to kill explorer.exe, and then restart it by selecting File ▸ Run and entering explorer.

sss
sss

© RuTLib.com 2015-2018