Practical Malware Analysis - Lab 9

OllyDBG

Lab 9

I choose x64DBG instead of OllyDBG because I found the HMI better, and I feel more familiar with the tool.

Lab 9-1

How can you get this malware to install itself ?

Firstly, let’s put the malware in the debugger. The program is immediately pauses once it hits the entrypoint.

At 0x402AFD, the number of argument is compared to 1. I didn’t set any parameters when starting the debug.

We’ll take the JNE path

Inside the function at 0x401000, we try to open the registry key: HKLM:\SOFTWARE\Microsoft\XPS.

The program couldn’t open the registry Key, because it doesn’t exist on my computer.

Then the program delete himself, and terminate..

We could see in the debugger that the parameter “-in” is hardcoded.

In order to set this parameter, we have to change the command line executed by the debugger.

Now, we restart the program, and we can see that the comparaison with the number of argument (1) is done.

Let’s dig deeper in the program..
Further, we see that the malware compare the length of the data after the parameter we enter with 4. We assume the length of the password is 4.
Then we can see 4 cmp instruction:

• “a” (0x61)
• “b” (0x62 - 0x61 = 0x1) -> cmp ecx, 1
• “c” (0x61 + 0x02)
• “d” (0x61 + 0x03)

Again, change the command line executed, and restart the program.

The comparaison of the parameter length and the first parameter work great.

Let’s continue the execution. All the comparaison went well, EAX is set to 1, we can continue the execution of the malware. The password to install the malware is abcd.

In the function at 0x4025B0, the program obtain the path where he is executed (this is store in EDX).

Then from 0x402B90, the Service Control Manager create a service with the name Lab09-01.

Afterwards, it copy the executed to %SYSTEMROOT%\system32\Lab09-01.exe

Otherwise, it open the service and change his configuration.

Once the program is copied to %SYSTEMROOT%\system32, we assume that the program is installed on the target.

What are the command-line options for this program ? What is the password requirements ?

As we saw previously, the password is: *abcd

There are 4 possible command-line options:

• -in
• -re
• -c
• -cc

How can you use OllyDbg to permanently patch this malware, so that it doesn’t require the special command-line password ?

The password is check from 0x402510. In the end of this function, there is a mov EAX, 1 when all the comparaison went well. Indeed, we’ll set EAX to 1 before ret. Press CTRL+E to modify the mnemonic. First we’ll mov eax, 1 (B8: mov; 01: 1), then we return from the function (C3: ret).

To dump the new patch file, press CTRL + P, select all, then file patch.

Finally, open the new dump file, jump to 0x402510 with CTRL + G. You should see your modification successfully saved.

What are the host-based indicators of this malware ?

• Registry keyy: HKLM\SOFTWARE\Microsoft \XPS
• Presence of a binary at: %SYSTEMROOT%\Windows\System32
• The service created with the name: Lab09-01

What are the different actions this malware can be instructed to take via the network ?

If there aren’t any arguments provided, the function starting at 0x402020 show us that the malware can receive information like:

• sleep (wait)
• upload (upload a file from the disk to the C2)
• download (download a file from the C2 to the disk)
• start cmd.exe (execute a command, and send the stdout to the C2)
• do nothing (continue)

Also the socket is setup with WSAStartup

Are there any useful network-based signatures for this malware ?

• We assume that the C2 is: http://www.practicalmalwareanalysis[.]com

There aren’t any user-agent specify. I didn’t found any additional network information like a file that could be download.

Lab 9-2

What strings do you see statically in the binary ?

Strings View on IDA show us that there aren’t any clues regarding the behavior of the malware.

What happens when you run this binary ?

The malware stop instantly without showing anything on the screen.

How can you get this sample to run its malicious payload ?

At 0x401206, we can see a comparaison between two strings. Let’s put a breakpoint on x64dbg to figure out what are the content of these two strings.
The first one, is the name of our binary (Lab09-02.exe) and the other one is ocl.exe.

We assume that our binary must be rename ocl.exe to continue the execution flow.

Restarting the program, we succesfully pass through the check of the binary name.

What is happening at 0x401133 ?

At 0x401133, there are obfuscated strings. Indeed, character are passed one by one through the stack. As a result, we couldn’t see those strings with the Strings View.

We identify two strings:

• 1qaz2wsx3edc
• ocl.exe

What arguments are being passed to subroutine 0x401089 ?

Setting a breakpoint at 0x401089, we can see that two registers are pushed.
ECX = 0x12FD58
EDX = “1qaz2wsx3edc”

What domain name does this malware use ?

The domain name is www.practicalmalwareanalysis.com, it is created in the subroutine at 0x401089.

What encoding routine is being used to obfuscate the domain name ?

Here is the routine that is used to create the domain name.

We put a breakpoint at xor ecx, edx to see what are the characters being xored.

The first character of the string “1qaz2wsx3edc” (“1”) is being xored with the letter “F” which result in the “w” letter.

After several loops, we finally constructed the entire domain string: www.practicalmalwareanalysis.com. The length of the string is 32 bytes long like the cmp it makes at 0x4010E3.

What is the significance of the CreateProcessA call at 0x40106E ?

The CreateProcessA, create a new cmd.exe process. With the parameter Show Window to 0, we know that the window will not be shown to the user. It will run in background.

Lab 9-3

What DLLs are imported by Lab09-03.exe ?

The DLLs imported statically are:

• DLL1
• DLL2
• KERNEL32.dll
• NETAPI32.dll

Futhermore, 2 DLLs are imported dynamically with the API call LoadLibraryA:

• USER32.dll
  
• DLL3
  

What is the base address requested by DLL1.dll, DLL2.dll, DLL3.dll ?

Let’s use the IDA python API to return the result. Open the first DLL and write in the python area:

base_address = idaapi.get_imagebase()
print(hex(base_address))

Do it for all the DLLs..
They are all loaded at 0x10000000

When you use OllyDbg to debug Lab09-03.exe, what is the assigned based address for DLL1.dll, DLL2.dll and DLL3.dll ?

• DLL1: 0x10000000
  
• DLL2: 0x490000
  
• DLL3: **** Set a breakpoint at 0x401041, then step over. The DLL is now loaded into memory. Then check in memory section the address assigned. Otherwise, you could check the content of EAX which contain the base address where the DLL was loaded in memory.
  

When Lab09-03.exe calls an import function from DLL1.dll, what does this import function do ?

Once the program import the function print from DLL1.dll it print on output a number.

Let’s analyse DLL1.dll to find what this number is. DLL1.dll retrieve the process ID in which he has been loaded.

When Lab09-03.exe calls WriteFile, what is the filename it writes to?

If we set a breakpoint on CreateFile, we can’t see any filename. Indeed, the function take the handler of the file that will be created.
We have to analyse DLL2.dll to find the name of the file. Opening the dll in IDA, we can see the name temp.txt.

When Lab09-03.exe creates a job using NetScheduleJobAdd, where does it get the data for the second parameter ?

• 1st parameter: 0 (servername)
• 2nd parameter: “Buffer” in edx
• 3rd parameter: “JobID” in eax

The buffer is gather from the DLL3.dll. Indeed after the call of the dll (call ebp + var_10), we can see two variable assignement (JobID to eax and Buffer to ecx).
Let’s check what is the content of the buffer in DLL3.dll.

In the MSDN of NetScheduleJobAdd, the buffer is a pointer to a structure call AT_INFO. We can add this structure in IDA to make the code more readable. Press SHIFT + F2 to open the structure view, then right click, add a struct, add strandard structure.

To apply to dword_1000B0A0, press ALT + Q and choose AT_INFO. The code is now readable (btw, it didn’t work on the graph view, I had to switch to hex view).

Based on this, we assume that it will ping www.malwareanalysisbook[.]com every day at 1am (3600000 ms (60 min) past midnight).

While running or debugging the program, you will see that it prints out three pieces of mystery data. What are the following: DLL1 mystery data, DLL2 mystery data and DLL3 mystera data ?

• DLL1 mystery data: Process ID from where the dll is executed
• DLL2 mystery data: Handle ID of temp.txt file
• DLL3 mystery data: Memory location where is store the Buffer for “ping wwww.malwareanalysisbook[.]com”

How can you load DLL2.dll into IDA Pro so that it matches the load address used by OllyDbg ??

In IDA Pro you can redefine the base adress of your program. Firstly, check what is the address when loaded into x64Dbg (Go to Memory Section and check the raw with the program name inside).

Switch to IDA Pro, click on Edit, Segments, Rebase Program. Change the value to 0x10000000