This blog post will walk you through on how to unpack VBScript malware. This sample is packed to make analysis difficult. The sample used in this writeup can be obtained from the open source repository malshare[.]com or app.any[.]run.
Tools used:
pestudio (static analysis)
PEBear (static analysis)
HXD (static analysis)
x32/x64dbg (dissasembler)
Disclaimer
You are dealing with a real malware sample. Run and Analyze it in a controlled environment (sandbox) with no connections to the internal network or internet. I am not responsible for any consequences or damages caused by your action(s).
Hash:
MD5 - 15fdc5c025e9d1645df07110c455aad9.
Analysis:
This Remcos malware sample uses a VB6 packer and is classified as a RAT. VB compiled malware are not compiled directly into machine instructions, rather a DLL present in the root drive of Windows systems known as MSVBVM60.dll/MSVBVM50.dll interprets the VB program into machine instructions (just like what a JVM does for a Java program). This DLL is always there in the imports of a PE when we have a VB written malware. VB malware basically are compiled in two ways: P-Code and Native. P-Code executables are compiled into bytecode which is interpreted by the Visual Basic virtual machine at runtime, while Native ones are compiled into native machine language. So, Native VB executables are easier to debug. On the other side, P-Code VB executables are easier to decompile.
At the entry point, there is always a non-returning call to the "ThunRTMain" function. This function has only one parameter, which is a pointer to a bulky structure holding everything the executable needs calling MSVBVM60.ThunRTMain.
The malware does process injection/process hallowing ( Malware Creates a process and Injects to it). Basically we will put a break on API Call: CreateProcessInternalW, which will find a PE file/executable in memory, unpacked in memory and ready to be written into the newly created process. Upon checking the executable in PE bear, we find that it only has one import "MSVBVM60.dll" ie a Microsft VM dll/VB6.
Load the binary in a debugger (x32/64), put a breakpoint on on API Call "CreateProcessInternalW", and run (f9) the binary.
Run (f9) the malware again upon hitting the entry point and you will hit an exception (first chance execption) which might be an issue with VB6 or anti-debbuging techinique. To skip the exception with the debugger, click on debug > advanced > run(pass exceptions) shft +f9. This will make the executable run like it would normally and you should be able to hit the CreateProcessInternalW breakpoint.
Next,go to memory map find some pattern for unpacked PE starting with string “This Program” which is commonly found in executables with MZ header.
We find a bunch of these strings and take a look at the first one by right click it and chose follow in dump.
In the dump window, we confirm that it's a PE with a MZ header. WE right click it and follow in memory map to make sure it's a PE that we can dump as a file and extract the bin with the protection ERW (Read Write Exec). Next right click > chose follow in Map memory.
In the memory map region, we find out that it is the original PE we were dealing with and we repeat the process again by going to the references tab and chosing the second "This program" string and follow it in dump.
On the second try, we find a DLL.mul (a loaded file from disk with a file path) and not a PE on the memory map regoin but at the third try, the dump windows shows the string "This program..." without the MZ header and we know we might be lucky. Upon following it to the memory map, we find that it has Execute Read Write Section (ERW).
Next we chose dump memory to file and open it in HXD to verify that it's indeed a PE. In HXD, search for the string "This program".
We find that the bytes "MZ" is missing which might be wiped as an Anti analysis feature but the FF, 04, 09 Bytes are available and seem to be the first row of bytes on the PE header and alligns with the offset of the hex dump 5FF0 and it's the first line without zero's.
Delete all the data before the aforementioned line (last line with zeros) and instert the MZ byte which denotes the begining of our PE and save the file with a .exe extension.
To confirm that we indeed have unpacked a executable from memory, load it in PEBear and confirm that the section headers allign with data and that we now have inports/API calls on the import section.
Shout out to @cybercdh, MalwareAnalysisForHedgehogs and OA labs
Comments
Post a Comment