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

, let’s begin by opening the file with IDA Pro and looking at the function imports. Many functions in the list provide little information because they are commonly imported by all Windows executables, but a few stand out. Specifically, Cre-ateProcessA, GetThreadContext, and SetThreadContext indicate that this program creates new processes and is modifying the execution context of processes. The imports ReadProcessMemory and WriteProcessMemory tell us that the program is reading and writing directly to process memory spaces. The imports LockResource and SizeOfResource tell us where data important to the process may be stored. We’ll focus first on the purpose of the CreateProcessA function call found at location 0x0040115F, as shown in .

, we see a push 4, which IDA Pro labels as the parameter dwCreationFlags. The MSDN documentation for CreateProcess tells us that this is the CREATE_SUSPENDED flag, which allows the process to be created but not started. The process will not execute until the main process thread is started via the ResumeThread API.

At , we see the program accessing the context of a thread. The hThread parameter for GetThreadContext comes from the same buffer passed to CreateProcessA at , which tells us that the program is accessing the context of the suspended thread. Obtaining the thread handle is important because the program will use the thread handle to interact with the suspended process.

After the call to GetThreadContext, we see the context used in a call to ReadProcessMemory. To better determine what the program is doing with the context, we need to add the CONTEXT structure in IDA Pro. To add this standard structure, click the Structures tab and press the INS key. Next, click the Add Standard Structure button and locate the structure named CONTEXT. Once you’ve added the structure, right-click location 0x004011C3 to allow the resolution of the structure offset, as shown in . As you can see, the offset 0xA4 actually references the EBX register of the thread by the [eax+CONTEXT._Ebx].

, at , the program increments the PEB data structure by 8 bytes and pushes the value onto the stack as the start address for the memory read.

, we see the parameters pushed onto the stack for a call to VirtualAllocEx.

, we see a loop at where the loop counter var_70 is initialized to 0 at 0x00401257.

into the much more readable version in (the changes are in bold in this listing).

, it’s much easier to see that the SizeOfRawData, PointerToRawData, and VirtualAddress values of each section header are being used to perform the copy operations, confirming our earlier suspicion that the program copies each section into the suspended process’s memory space. The program has taken the necessary steps to load an executable into another process’s address space.

In , we see that the program uses SetThreadContext, which sets the EAX register at to the entry point of the executable that was just loaded into the suspended process’s memory space. Once the program performs the ResumeThread at , it will have successfully achieved process replacement on the process created using CreateProcessA at the beginning of this function.

being provided to the CreateProcessA API call.

Pressing CTRL-X with the cursor at the start of the sub_4010EA function shows all cross-references, including the callers sub_40144B and main. Following main brings us to 0x00401544, where the variable Dst is loaded into a register to be passed to sub_4010EA as the process name for CreateProcessA. Placing the cursor over Dst highlights the variable throughout the function, thereby allowing us to follow the variable in order to determine its origin.

The variable is first seen as shown in at , as the second parameter to sub_40149D.

. By examining earlier instructions, we find a function call at . Remembering that EAX is the return value for a function, we know the buffer is coming from the function sub_40132C, which appears to take the variable hModule, a memory pointer to the program itself, Lab12-02.exe.

shows Lab12-02.exe inside Resource Hacker with an encoded binary in the resource section. We can use Resource Hacker to export this binary.

At this point, we need to continue examining the disassembly to determine how the executable is decoded. At 0x00401425, we see that the buffer is passed to function sub_401000, which looks like an XOR routine. Looking back at the third parameter passed to the function at location 0x0040141B, we see 0x41. Using WinHex, we can quickly XOR the entire file exported earlier from Resource Hacker by selecting Edit ▸ Modify Data ▸ XOR and entering 0x41. After performing this conversion, we have a valid PE executable that is later used to replace an instance of svchost.exe.

and the free trial version is useful for malware analysis. We use it here for illustrative purposes, but most hex editors can perform a single-byte XOR operation.

We can conclude that this malware decodes a binary from its resource section and performs process replacement on svchost.exe with the decoded binary.

Назад: Lab 12-1 Solutions
Дальше: Lab 12-3 Solutions

sss
sss

© RuTLib.com 2015-2018