PMA Lab 15-3: Anti-Disassembly
Analyze the Malware found in the file Lab15-03.exe. At first glance, this binary appears to be a legitimate tool, but it actually contains more functionality than advertised.
Lab 15-3
Analyze the Malware found in the file Lab15-03.exe. At first glance, this binary appears to be a legitimate tool, but it actually contains more functionality than advertised.
Analysis:
After starting removing all Anti-Disassembly techniques, there were a couple of functions that stood out and look suspicious, for instance UrlDownloadToFileA, and WinExec. These functions don’t have any Cross-References, and this can be confirmed using the IDA Pro Graph view, which make them even more suspicious:

Looking at the rest of the code, it doesn’t seem important or at first glance, malicious. As the exercise states “this binary appears to be a legitimate tool, but it actually contains more functionality than advertised”, so, let’s focus on this part of the code.
In line 0040149C, it is possible to see the instruction “push large dword ptr fs:0”, followed by “mov large fs:0, esp”:

fs:0 in Windows always points to the start of the Thread Information Block (TIB). Writing esp to fs:0 means the program is modifying the Structured Exception Handling (SEH) chain stored in the TIB, which means the malware is exploiting SEH to redirect execution flow.
This can be confirmed with x32dbg:

Before manipulating SEH, the Malware pushes a malicious handler onto the stack and overwrites fs:[0] to register it. Then, in line 004014AA and 004014AC, it is possible to see the Malwrae forcing a divide-by-zero exception, which will result in code execution to jump to the malicious handler, executing this part of the code.
All of this is done in sub_4013D1, which is a function called several times during the code flow:

Using x32dbg it is possible to confirm that code execution reaches the malicious handler.
From here it is possible to see that eventually a URLDownloadToFileA is going to be executed:

Looking at the parameters of this function, we can see that szURL, and szFileName are stored in two offsets:
HRESULT URLDownloadToFile(
LPUNKNOWN pCaller,
LPCTSTR szURL,
LPCTSTR szFileName,
_Reserved_ DWORD dwReserved,
LPBINDSTATUSCALLBACK lpfnCB
);
However, by inspecting either of these statically, they are found to be non readable (encoded). Also, both of these offsets are passed as a parameter to function sub_401534, as it is possible to see in the previous image by highlighting one of them.
This function is clearly a decode routine. It is possible to see that it iterates over arg_0, and checks for a 0 (a Null Byte), and if found it will jump to loc_40155C, and eventually returns. Otherwise, it will XOR each byte with the 0xFF key. Then, the “string pointer” is moved by incrementing edx, and it keeps on going using the jump at 0040155A.

Once done, the strings will be decoded, and reused in URLDownloadToFileA.
With a simple IDA Python script it is possible to decode these buffers, and see what the Malware is looking for:

The IDA Script looks like this:
import idc
import idaapi
buf_offset = 0x403010 #Buffer offset
xor_key = 0xFF
def xor_decode(buf_offset, xor_key):
decoded_str = ""
addr = buf_offset
while True:
byte_value = idc.Byte(addr)
if byte_value == 0x00:
break
decoded_char = chr(byte_value ^ xor_key)
decoded_str += decoded_char
addr += 1 # Move pointer
print("Decoded string: {}".format(decoded_string))
xor_decode(buf_offset, xor_key)
With this, we know the Malware will attempt to download a file from:
http://www.practicalmalwareanalysis.com/tt.html
And will store it with the name spoolsrv.exe. After that, the Malware will use the filename buffer and push it to the stack, using it as a parameter to WinExec:

This way, the Malware is able to execute the second stage Malware, and then exits, by calling ExitProcess. All of this is happens while running this apparently legitimate program that lists all the Processes and the loaded Modules:

This is done by iterating over all the processes running on the system, using CreateToolhelp32Snapshot, Process32First, and Process32Next. For each process OpenProcess, andGetPriorityClass are called to gather process information, which is then printed to the screen using printf.
Questions:
-
How is the malicious code initially called?
The code is called by Exploiting SEH, and triggering an exception.
-
What does the malicious code do?
The Malicious code can download a malicious file from the C2 server and execute it.
-
What URL does the malware use?
The URL the Malware uses is: http://www.practicalmalwareanalysis.com/tt.html
-
What filename does the malware use?
The Filename the Malware uses is: spoolsrv.exe