Lab 9-1

Analyze the malware found in the file Lab09-01.exe using OllyDbg and IDA Pro to answer the following questions. This malware was initially analyzed in the Chapter 3 labs using basic static and dynamic analysis techniques.

Questions and Short Answers

How can you get this malware to install itself?

A: You can get the program to install itself by providing it with the -in option, along with the password. Alternatively, you can patch the binary to skip the password verification check.
What are the command-line options for this program? What is the password requirement?

A: The command-line options for the program are one of four values and the password. The password is the string abcd and is required for all actions except the default behavior. The -in option instructs the malware to install itself. The -re option instructs the malware to remove itself. The -c option instructs the malware to update its configuration, including its beacon IP address. The -cc option instructs the malware to print its current configuration to the console. By default, this malware functions as a backdoor if installed.
How can you use OllyDbg to permanently patch this malware, so that it doesn’t require the special command-line password?

A: You can patch the binary by changing the first bytes of the function at address 0x402510 to always return true. The assembly instruction for this behavior is MOV EAX, 0x1; RETN;, which corresponds to the byte sequence B8 01 00 00 00 C3.
What are the host-based indicators of this malware?

A: The malware creates the registry key HKLM\Software\Microsoft \XPS\ Configuration (note the trailing space after Microsoft). The malware also creates the service XYZ Manager Service, where XYZ can be a parameter provided at install time or the name of the malware executable. Finally, when the malware copies itself into the Windows System directory, it may change the filename to match the service name.
What are the different actions this malware can be instructed to take via the network?

A: The malware can be instructed to execute one of five commands via the network: SLEEP, UPLOAD, DOWNLOAD, CMD, or NOTHING. The SLEEP command instructs the malware to perform no action for a given period of time. The UPLOAD command reads a file from the network and writes it to the local system at a specified path. The DOWNLOAD command instructs the malware to send the contents of a local file over the network to the remote host. The CMD command causes the malware to execute a shell command on the local system. The NOTHING command is a no-op command that causes the malware to do nothing.
Are there any useful network-based signatures for this malware?

A: By default, the malware beacons http://www.practicalmalwareanalysis.com/; however, this is configurable. The beacons are HTTP/1.0 GET requests for resources in the form xxxx/xxxx.xxx, where x is a random alphanumeric ASCII character. The malware does not provide any HTTP headers with its requests.

Detailed Analysis

We start by debugging the malware with OllyDbg. We use the F8 key to step-over until we arrive at the address 0x403945, which is the call to the main function. (The easiest way to figure out that the main function starts at 0x402AF0 is by using IDA Pro.) Next, we use the F7 key to step-into the call to the main function. We continue to step forward using F7 and F8 while noting the behavior of the sample. (If you accidentally go too far, you can reset execution to the beginning by pressing CTRL-F2.)

First, the malware checks to see if the number of command-line arguments equals 1 at address 0x402AFD. We have not specified any parameters, so the check succeeds, and execution resumes at address 0x401000. Next, it attempts to open the registry key HKLM\SOFTWARE\Microsoft \XPS; however, since the registry key does not exist, the function returns zero, so execution calls into the function at 0x402410.

F7 step-into call Lab09-01.00401000:

The function at 0x402410 uses GetModuleFilenameA to get the path of the current executable and builds the ASCII string /c del path-to-executable >> NUL. Figure 9-1L shows an instance of the string in the registers window of OllyDbg. Note that the contents of EDX are 0x12E648, but OllyDbg correctly interprets this as a pointer to an ASCII string. The malware attempts to delete itself from the disk by combining the constructed string with program cmd.exe in a call to ShellExecuteA. Fortunately, we have the file open in OllyDbg, so Windows does not allow the file to be deleted. This behavior is consistent with what we saw during basic dynamic analysis of the sample in the Chapter 3 labs.

Figure 9-1L: The malware prepares to delete itself, as seen in the string pointer to EDX

Our next task is to coerce the malware to run properly. We have at least two options: we can provide more command-line arguments to satisfy the check at address 0x402AFD, or we can modify the code path that checks for the registry keys. Modifying the code path may have unintended effects. Later instructions can depend on information stored in these keys, and if that information is changed, the malware could fail to execute. Let’s try providing more command-line arguments first, to avoid potential issues.

Choose any entry from the strings listing, such as -in, and use it as a command-line argument to test whether the malware does something interesting. To do this, choose Debug -> Arguments, as shown in Figure 9-2L. Then add the -in argument in the OllyDbg arguments dialog, as shown in Figure 9-3L.

Figure 9-2L: Choosing to debug arguments

Figure 9-3L: Adding the -in argument

When the malware is executed with the argument -in, it still tries to delete itself, which tells us that the command-line arguments are not yet valid. Let’s use OllyDbg to step through the code flow when we give the malware a parameter to see what’s happening.

Listing 9-1L: Function setup and argc comparison

We see that after checking a command-line parameter, execution takes the jump at 0x402B01. argc, the number of string arguments passed to the program, is found 8 bytes above the frame pointer \({\color{red}1}\), since it is the first argument to the main function.

At 0x402B2E, the last command-line argument is passed into the function that starts at address 0x402510. We know it is the last argument because the main function of a standard C program takes two parameters: argc, the number of command-line parameters, and argv, an array of pointers to the command-line parameters. EAX contains argc, and ECX contains argv, as shown in Listing 9-2L at \({\color{red}1}\) and \({\color{red}2}\). The instruction at \({\color{red}3}\) performs pointer arithmetic to select the last element in the array of command-line parameters. This pointer ends up in EAX, and is pushed onto the top of the stack prior to the function call.

The basic disassembly view provided by OllyDbg gives a rough overview of the function that starts at address 0x402510. There are no function calls, but by scanning the instructions, we see the use of the arithmetic operations ADD, SUB, MUL, and XOR on byte-sized operands, such as at addresses 0x402532 through 0x402539. It looks like this routine does a sanity check of the input using a convoluted, hard-coded algorithm. Most likely the input is some type of password or code.

NOTE

If you perform a full analysis of 0x4025120, you can determine that the password is abcd. You will be equally successful using the password or the patch method we explain next.

Rather than reversing the algorithm, we patch the binary so that the password check function at 0x402510 will always return the value associated with a successful check. This will allow us to continue analyzing the meat of the malware. We note that there is an inline function call to strlen at addresses 0x40251B through 0x402521. If the argument fails this check, EAX is zeroed out, and execution resumes at the function cleanup at 0x4025A0. Further reversing reveals that only the correct argument will cause the function to return the value 1, but we’ll patch it so that it returns 1 in all cases, regardless of the argument. To do this, we insert the instructions shown in Listing 9-3L.

B8 01 00 00         MOV EAX, 0x1
C3                  RET

Listing 9-3L: Patch code for the password check

We assemble these instructions using the Assemble option in OllyDbg and get the 6-byte sequence: B8 01 00 00 00 C3. Because the CALL instruction prepares the stack, and the RET instruction cleans it up, we can overwrite the instructions at the very beginning of the password check function, at address 0x402510. Edit the instructions by right-clicking the start address you wish to edit and selecting Binary

巴特西

Lab 9-1

Questions and Short Answers

Detailed Analysis

最新文章

热门文章