- IDA Pro
- Proc Mon
- Process Explorer
- Lab03-01.exe SHA256: eb84360ca4e33b8bb60df47ab5ce962501ef3420bc7aab90655fd507d2ffcedd
- Detection Rate: 49/53
- Analyzed on 27 Jan 2016
Compilation Date: 2008:01:06 15:51:31+01:00
- View report here
Analyze the malware found in the file Lab03-01.exe using basic dynamic analysis tools.
1. What are this malware’s imports and strings?
The only import that this malware uses is ExitProcess from kernel32 Library.
We can gather more intel from the malware’s strings. Fortunately for us, these strings are not obfuscated. We need to monitor http://www.practicalmalwareanalysis.com in the network traffic. We can also monitor/check the registry SOFTWARE\Classes\http\shell\open\commandV (IExplorer.exe) and Software\Microsoft\Active Setup\Installed Components\. We should also check systems for vmx32to64.exe, most likely infected machines would have this executable hidden somewhere.
The possibility of this Malware being packed is low since the Malware’s Strings seems to be legit. But just to be sure let’s run the malware on PEID.
It seems like this malware is not packed. However Anti Reversing Techniques is used in this binary. Below is a screenshot taken from ollydbg. We can see that at address 0x401259 a call was made to 0x401265. This opcode caused the return address of 0x40125e to be pushed in the stack. At address 0x401265, a call was made to kernel32.LoadLibraryA. But as we know, LoadLibrary needs a LPCSTR argument passed in… If we look at the stack what is pushed in earlier is actually a pointer to a char array! The return address pushed in earlier by the CALL opcode actually pushed in “user32”. Instead of using push, this author used call to push in arguments.
- Proc Monitor
- Process Explorer
Using Regshot we found out that the malware is trying to execute c:\windows\system32\vmx32to64.exe on startup. We should be able to see from proc mon on howvmx32to64 gets into the system32 folder.
we can see that a call was made to http://www.practicalmalwareanalysis.com (DNS resolve) and a SSL connection was made. Following the TCP stream we can see some random looking 256 bytes being sent.
Using ProcExplorer, we are able to see more strings (decrypted in memory) and the mutex handle.
Proc Mon allows us to see the Registry edit and the file creation in the target’s machine.
By breaking at LoadLibraryA we know that the malware actually loads these library
- 0012EFC4 0040123C /CALL to LoadLibraryA from Lab03-01.00401236
0012EFC8 0040122D \FileName = “advapi32”
- 0012EFC4 00401253 /CALL to LoadLibraryA from Lab03-01.0040124D
0012EFC8 00401247 \FileName = “ntdll”
- 0012EFC4 0040126B /CALL to LoadLibraryA from Lab03-01.00401265
0012EFC8 0040125E \FileName = “user32”
- 0012EFC4 00401505 /CALL to LoadLibraryA from Lab03-01.004014FF
0012EFC8 004014F7 \FileName = “advpack”
2. What are the malware’s host-based indicators?
check if vmx32to64.exe exists in c:\windows\system32.
Check if WINVMX32 mutex is opened. If it does your machine is most likely infected.
3. Are there any useful network-based signatures for this malware? If so, what are they?
256 random looking bytes sent via port 443.
Other Stuff to note
So how did the malware retrieves its own kernel32 base address? It uses the fs:30h to locate its PEB then offset of 0Ch to get its Ldr and finally offset of 1ch to get to the InInitializationOrderModuleList. The kernel32 is located in the 2nd entry of the linked list away thus explaining why the malware uses an offset of 8 @ line 0x401207. However newer operating system does not have its kernel32 set in the 2nd entry thus the malware would crash in other newer OS. Looking at the time of compilation (2008), this malware is probably written for winxp.