The background
MalwareMustDie (MMD) today is having the third anniversary. due to this occasion, I wrote this post as the anniversary celebration :) The point is to introduce some methodology in dissecting obfuscated script malware using the real life sample of VBE encoded case with multiple obfuscation. Why I pick this VBE is because the recent raise of the visual basic scripted malware, as in its stand alone VBE, in attached macro of Microsoft Office documents too, so hopefully this writing can share some idea to those who want to know more in how we used to dissect them in MMD. Another reason is to introduce many tools for practical malware analysis that can be performed by everyone who want to start to learn. It's not that difficult, so let's learn it together!
A friend was sending us a VB encoded script (with thank's), he sent me a lot of good samples and I really appreciated. The file named "ContratoAssinar.vbe (4bb9a041ab9cdd8398f95c0dd8a364b0)" and I find it very interesting, so I think I'd better to make some notes here about the way I dissolve it for others who may handle same threat.
The origin of the threat is from South America (to be precise, Brazil), The file looks like coming from an attachment of malvertisement email campaign of the malware. The file name itself is quite popular, with a bit of net surfing will give you good information about the campaign of this malware.
VBE malware script
The malware is encoded using the Microsoft's Scripting.Encoder program, it looks like this:
I tend to use the script provided by the vendor for these purpose so I used this script-->[link] to decode it (the instruction is in that page, it is really really self explanatory) and it was resulted into another partial-obfuscated script as you can see the whole data in the below image:
You will see some area in the above code that I separated them into colors:
The yellow area is the part where this script is to be assured to execute in the right system command & path/file name, it was started in the first line a SUB name that execution the latest part in the overall script.
The red part is the data area where the actual malware script command for the next level is obfuscated, following the red arrow will lead you to the blue area of logic where the data to be final-deobfuscated in the below series of deobfuscation commands.
Orange color part is the part where deobfuscated commands to be executed, and following the blue arrow can lead you to the actual malicious mysterious strings to be executed by the obfuscated malware script.
To understand the flow of obfuscation in several language of programming that I faced so far in MalwareMustDie and facing to obfuscation I tend to discipline myself to follow my own committed rules as per shared below:
1. Make the code to be simplified, beautified, make it easy to you to stare at (I mean..to read)
2. Break the codes into pieces, and comment them, make sure you know how each component works, do not be shy to make many comments, and I make tons of them too, it is for your own good.
3. To securely simulate the code to debug is strongly suggested. Use any compiler/interpreter that helps, if not..use our brain for it by making some notes, in this level in most of the time in heavy obfuscated challenges we must go back to point 1. again, but so be it,do it happily!
4. Do not get frustrated, enjoy the cracking like you are eating ice cream, it will end before you even know it..it's all be solved in time, believe it! When you are in a rush or in some pressure your brain cells can not focus to the decoding effort fully, only when we relax we can fully use those cells, and if you push it hard, your work will not be effective and mistakes will occur. A one little mistake of a single byte will drag you to a time-consuming trouble-shooting debugging later on which will lead you back to square one..and that is mostly how a failure starts, so noted this point number 4 well, PS: this point also goes to the boss/management of the reverse engineers, understand this point well if you want your team to do good work!
5. Write it, don't expect your brain to memorize every work result you do, make it searchable for yourself (or for your team..or others) to be used for later reference, be smart in documenting stuff and manageable, we are educated people not like those crooks who made these craps we decode, we're better than them.
What we learned from the first level decoded VBE script is: The malware coder is trying to hide the path confirmation instruction to trigger execution by SUB-ing the call for executional path in the last part of the script. He also obfuscate another malware script in the stub of variable value to be decoded again by the instruction following that stub, and after that pass the decoded value into execution.
To understand this I just simply replace all of the random-look strings into a dull-like var-x or anything that can differ it to the real code token, you can choose any variable name you like which that is so "you" so you will recognize it instantly. That will help you to recognize the actual malicious logic the malware coder tried to hide it from you. This method is used in most programming language based malicious obfuscation I am working with, I think I've tried and tested it enough, it works in Java(with or without Script)), VB, PHP, Perl or AutoIt malicious obfuscation code that I face for these good three years..and it still works! Even some crooks tried hard to mitigate this method with some silly tricks but that just simply doesn't work, since this is just a simple coding matter. So please remember: "To simplify the code!"
In this case the memo of the above rule and process applied to this sample is as per seen in this pastebin--> [link]
Noted: I tweaked some code so you won't run it in harmful way if you just copy paste and run it, it will burp the garbled code as per below picture :-)
Below is the explanation of the paste and the next steps:
There are two environment that the gods of Windows provide us to deal with visual basic scripting in any machine with wscript.exe and cscript.exe, I use wscript.exe only for checking the break point using Wscript.Echo command to check the variable result. In the paste you will see some of simple breakpoints to check the vital values of the script. As per seen in the below screenshots:
After the breakpoint's debugging lead you to the correct result you would want to copy paste them to a text, in this point you can run the script with the cscript.exe to get the text result in the console as per snapshot below:
The full code is beautified as per below:
Please noted words "nome correto do exe" which means something like "correcting the exe's filename" in Portuguese, that was shown in the new malware code script result after the decoding.
Again we still have to deal with the visual basic script, but all of the code are readable. It's obviously it downloads the zip file from the internet and save it to a certain folder and extracted into %appdata%+random folder name into random filename +.exe extension. The script is neat, it has the originally coded randomize functions and original coded SUBs for downloading the remote file from hard coded IP address of 5.175.145.181 using microsoft.xmlhttp and adodb.stream objects.
To be noted, our payload is a zip file contains the text file that can be viewed in Virus Total in here-->[link] or can be viewed by the picture below:
Noted: If you analyze a malware please drop the idea of WYSIWYG (what you see is what you get), because every appearance that you see was meant to fool you.
Example: this Text File.
Isn't it amazing to see that in this era there is still a crook who want victims to download 6Mb of malware unrecognized? Well, here is one of them..
The IP that serves this malware is located in Germany:
"ip": "5.175.145.181", "hostname": "b9.globalplex.us", "city": null, "country": "DE", "loc": "51.0000,9.0000", "org": "AS12586 GHOSTnet GmbH"
The AutoIt PE "Banco" banking trojan
A quick check will confirm the badness of this "text" file which is actually is a PE:
I love to use pyew since the day we start MalwareMustDie and thank's to Mr.Joxean Koret to develop it, I just want him to know that I use it all along for three years non stop :-) along with many shell tools I use. It is VERY useful for the UNIX shell that can not be used to compile full binary to run other binary analysis tools since it runs on python. And it has many useful disassembler functions too. Here's the snip of the payload in this story:
In order to find the best way to do it, static analysis is a must. The pescanner is assuring many details for the further reversing purpose:
Just to make sure it's not an false detection I tend to re-check it with the other beloved tool I use, you all know what it is:
For friends with the Wndows OS environment, don't worry! PEStudio can statically analyze this malware very good, take a look of how many indicator was raised an dthe detection of the AutoIt overlay below:
OK, to reverse it, since this is the AutoIt malware, I just prefer to decompile it for the analysis. I use this good tool for it -->[link]
The result is as below, it is bringing us to "another level" of obfuscation :-)
Don't worry. We can go back to our rules above to analyze it properly, with some patience, a good 1 hour and good macro editor you can have a much better view in no time :-)
You can see there some DLL struct scripted for the usage malicious calls of and some PE binaries blobs ( which those are there to be used for the x64 or x32 OS process injection). Please try to decode the AutoIt script by yourself and trail its variable one by one. It's good to see a readable code is it?
I beautified & cleaned the 186+ of obfuscated variables and functions used in this obfuscated decoded source code, so if you want to snip into the result first without taking effort to decode or cleaning nor beautifying code, you can see it in MMD pastebin to see how the malicious operation calls and self PE injection technique and tricks (like there is a thread injection to modify other thread's contents) that were all done by this AutoIt's codes, the link is here-->[link].
How AutoIt can inject memory?
It's a simple way to inject actually, it forms object of DllStruct by the AutoIt programming code, to feed the object with the parameter and hard coded binary data (which are obfuscated) to form several malicious performance, and write it into specific address in the memory. This is the main concept of this AutoIt/PE malware works to infect the victim. Some of the tricks for allowing that action was formed with the preliminary tricks to bypass security. The variable name is telling you which part of process it is being used actually so it is a bit traceable. Frankly speaking I never thought will face this exploitation-like action when seeing this sample in the beginning. But I will make simple explanation below but not too detail yet, since many parts are still being investigated now.
In the pastebin data, for the early injection operation, please watch the value of $var30 and $var120 which are loaded with binary data to be used to perform the injection for running process. I spot the memory writing operation by script is about as per snipped below;
The above snippet code can show you how the memory injection can be perform by this script. The deeper ROP analysis is actually needed to understand the details of this. When fully run, I can see the PE was written in the memory from the source address 0x410DAD and by the VirtualAllocEx symbol calls of system32.dll on base memory 0xE80000 and with the big size (length) PE file:
Also, if you have a tool so trace steps of a process in Windows environment, you will see in steps how the sample is forming injection to the foreign address by injecting itself:
Just for fun, I compiled the first bin loaded to inject to understand what it is, the compilation is the PE with value of binary $var30 string (just for curiosity..I know this will end up to nowhere) that was called by DLLStruct snipped above, so the entry point for reverse engineering of that binary can be "factorized", you can get the sample in here [link] for you to analyze it using any disassembler software. You'll see something like this:
Well, the 0x4001e5 doesn't make any sense to me, and this loopbacks to the main entry. lol :-)So we know this maybe not a shellcode.
Anyway.. please enjoy the further analysis of the calls made from the decoded PE(AutoIt) :-)
Summary of the PE's malicious behavior detected:
Instead the memory inject & thread modification, the other activity of the PE is: The sleep time taken after executed (see the beautified source code), some of the detection of the VM (access to \VBoxMiniRdrDN / VBoxHook.dllU / VMware), it seeks for FWPUCLNT.DLL (windows firewall). Creates registry autostart with changes file view setting of explorer (I don't know what this is for..but there's no good in it) and..
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced EnableBalloonTips
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{XXX}\InProcServer32
Etc activities for instance:
Self rename file extension of itself into .exe Binding to local INET socket to open & listening port 2038 Mutex: "\BaseNamedObjects\2015.0.11"And some strings to mitigate these security products:
Avira\Antivirus\avcenter.exe Avira\Antivirus\avgnt.exe \procexp.exe
The callback
The malware is contacting the remote host as CNC in Brazil with IP 187.17.111.103 and sending CNC poke data via a HTTP/1.0 POST, that IP is having a very bad reputation IP-->[link]:below is the evidence:
It is our team's drill to search the fresh CNC information as much as possible to support the work of law process who would like to follow a crime investigation for the case. So in this case too, I extracted some information, so if I may advice..in minimum please do the same for the cases that you spotted.
Lookup result for the domain called:
;; ANSWER SECTION: hostbemore.com. 1800 IN A 187.17.111.103 ;; AUTHORITY SECTION: hostbemore.com. 3600 IN NS ns1.dominios.uol.com.br. hostbemore.com. 3600 IN NS ns2.dominios.uol.com.br. hostbemore.com. 3600 IN NS ns3.dominios.uol.com.br. ;; ADDITIONAL SECTION: ns1.dominios.uol.com.br. 3275 IN A 200.98.199.199 ns2.dominios.uol.com.br. 3275 IN A 200.221.65.6 ns3.dominios.uol.com.br. 3275 IN A 200.98.199.204Ip address origin (GeoIP & ASN):
"ip": "187.17.111.103", "hostname": "No Hostname", "city": null, "country": "BR", "loc": "-23.5477,-46.6358", "org": "AS7162 Universo Online S.A."The domain is registered with an email contact of [email protected] to ENOM.COM:
Domain Name: HOSTBEMORE.COM Registry Domain ID: 1895096489_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.enom.com Registrar URL: www.enom.com Updated Date: 2015-07-07T05:57:31.00Z Creation Date: 2015-01-10T15:12:00.00Z Registrar Registration Expiration Date: 2016-01-10T15:12:00.00Z Registrar: ENOM, INC. Registrar IANA ID: 48 Registry Registrant ID: Registrant Name: "ARNALDO BALTAZAR NETO NETO" Registrant Organization: "SOUZACRUZFERRAGISTA" Registrant Street: "AV BELA VISTA2 Registrant City: "GOIANIA" Registrant State/Province: Registrant Postal Code: "74938110" Registrant Country: "BR" Registrant Phone: "+55.6198515323" Registrant Email: "[email protected]"
Sample for analysis learning purpose
It's downloadable in a 7zip format from here -->[link]The payload in 7zip format is here -->[link]
The next challenge...encryption VBE:
This will bring VBE #malware infecting script into next level: the encryption
http://t.co/4OYjZsI8Bg
#MalwareMustDie pic.twitter.com/oAGqod50vQ
— ☩MalwareMustDie (@MalwareMustDie) August 29, 2015Kudos the cool coders of great tools & OS we use:
Thanks: @matalaz @virustotal @radareorg @ochsenmeier @WiresharkNews @freebsd @ThePSF for 3years helping #MalwareMustDie w/your development!
— ☩MalwareMustDie (@MalwareMustDie) 2015, 8月 28Happy anniversary to MMD friends! Stay safe! #MalwareMustDie!
