In my previous post I presented how anyone can track malware and c2 servers from open source intelligence. It’s worth to mention that many of the samples were still in development or in test phase, this approach can give you a lot of information about TTPs (Tactics, Techniques and Procedures) of threats actors. By using Daily dose of malware and some manual research, I stumbled upon couple interesting samples and I want to share one of them.
Word document as initial vector
As it often happens, a document (PDF, Word, Excel) is entry point for the attackers, in this case CVE-2017–11882 was used to deliver next stage payloads. Due to this exploit, attacker can embeed OLE object into specially crafted RTF file, which allows him to execute commands on the victim system. Below you can find objects which were embedded into malicious word document.
All of the objects try to disguise as a legitimate software (Intel) to arouse user’s trust.
Inteldriverupd1.sct allows attacker to take advantage of the Windows Script Component and create new object, which next run task.bat script
Task.bat checks for presents of “block.txt” file in temp directory and if file does not exist, script creates it. At the end it starts “2nd.bat” and deletes itself.
Last stage is to execute 2nd.bat script. At the beginning it starts main exe file and kills word process (winword.exe). After that, it deletes Resiliency directory from registry (for every version) to hide it’s own tracks and prevent recovery of the document. Next lines are interesting because of MRU (Most Recently Used) functionality. These keys keep paths to last opened documents. In this way attacker knows where file was executed and can easily copy decoy.doc to temp folder. Last two commands delete other tracks of presence.
“Decoy.doc” as name suggest it used as a decoy, which means this file will be displayed to end user after infection.
The whole file weights 1,4 MB.
It’s also worth to mention that at the time of execution, it connects to hxxp://goog[.]com/newbuild/t.php?stats=send&thread=0 but more about this later. Which is shown on below screenshot
Dropped file (exe.exe) was written in c#and it was obfuscated with DeepSea algorithm, but De4dot did a great job and deobfuscate file immediately.
After that operation, we can clearly see classes and functions names, which can give us insight how it operates. It turned out that it was only first layer of deobfuscation. We have to identify location of the next payload, possible obfuscation algorithm and then dump it as binary.
I found function responsible for decoding, it’s simple xor and modulo operations. Now, we can easily dump next file.
One way is to set a breakpoint after “while” operation and save it variable directly to disk. It’s possible also to import whole project into Visual Studio and then call the function, but I decided to rewrite this function into python and decode it on my own.
“Byte3” and “Byte2” are names of the byte arrays.
int0 = len(byte3) - 1 int1 = len(byte3) array_size =  * int1 byte2 = bytearray(array_size) while int0 >= 0: byte2[int0] = (byte3[int0 % len(byte3)] ^ byte3[int0]) int0 = int0 - 1 file = open("decoded.bin","w") file.write(byte2)
That was one way how next file can be retrieved, another one can be debug code and check for loaded modules. New file is loaded to memory before execution so it’s possible to dump it in DnSpy from “modules” tab.
What is also interesting, there are many embedded images in resources of the file. All images contain noisy pixels, besides one of them, which looks like legitimate poster of movie night in Bucharest, with name “Key0”. Noisy pictures will be used in next stage but purpose of the poster is still unknown.
Next file was also written in .Net with some tricks, which make it harder to read. For example, strings are encrypted with hard-coded keys but it’s trivial task to decrypt it since we have a source code, you can call this function on every founded string in code.
Couple interesting strings:
It turns out that most of the classes and function names are still not readable enough for easy analysis. I didn’t find any automatic way to deobfuscate this layer, but after some time I was able tot draw couple conclusions.
First thing what file does is to decrypt another file and store it in dictionary with other information related to malware configuration. The way how it creates another file is very creative and works as follows:
- Gets images from resources (noisy ones from previous layer) and store it in array as “image” type
- Changes every image into memory stream
- Decrypt it
- Add it to dictionary
During execution it checks for configuration from dictionary (in this sample any additional feature wasn’t turned on) and calls accordingly function. For example, if value Options.CheckVM is set to false, malware won’t call function responsible for checking if it’s running in virtual environment.
One of the function checks for processes (vmacthlp, vmtools, vboxservice) and if one of them is running, it terminates itself.
And below we can see how it copy itself to C:\users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs and starts afterwards.
Fourth layer — Betabot
After dumping file from previously mentioned array, we have infamous another variant of Betabot. One of the possibility why there are many Betabots in the wild may be because of usage cracked version, more about it here. Sample contains some anti-debugging and anti-vm tricks.
First of them is checking for PEB for the BeingDebugged flag. To bypass it, we have to set value EBX this same as in EAX. More info about this technique here.
It checks for present of following keys: VboxGuest, VmTools and Vmware.inc, in SYSTEM\CurrentControlSet\services.
Rest of the execution is the same as sample analyzed here. However, I have some troubles while unpacking malware from memory. Before whole file is totally unpacked, I came across stack overflow error, maybe it’s next anti-debug mechanism that I cannot bypass. If you saw similar behavior, please ping me. For the record, the unpacked malware would be the last layer.
In this case, I decided to use automatic tool like SysAnalyzer, which can detect and dump proper parts of memory for further analysis. It actually did his job but still header is broken or encrypted and file can’t be analyzed because of that, however from the strings I can deduce some of the functionality.
By providing tutorials and sharing knowledge I hope to partially cover my medical bills. If you like my work and use my tools, please donate.
As previously stated, first connection is made to the hxxp://goog[.]com/newbuild/t.php?stats=send&thread=0, after couple redirections, it assigns random values in response.
Redirection leads to affiliate service hxxp://sharesale[.]com, with some tracking values.
At the end we land at hxxp://shirtbattle[.]com.
My guess is that bot first registry itself for tracking purposes and then go to shirtbattle to earn some additional money from affiliate program.
I also observed that main C2 server is located on hxxp://onedriveservice[.]com, it’s not genuine Microsoft domain and it’s tied to other malicious campaigns.
Probably this campaigns is over already and CnC closed.We can change our DNS settings and pretend to be C&C server. Below is standard request for Betabot, random parameters names and RC4 encoded. More about extracting RC4 key and how to get config here.
Network traffic was prepared very cautious, domain like goog[.]com and onedriveservice[.]com may look innocent because of similarity to worldwide used services.
Sometimes even known samples can make some troubles because of various ways of packing, encrypting or encoding. It takes more time to understand exactly how it operates and what kind of cause it can make.
If you have found any inaccuracy in this article, or something that you disagree or just want to ask something, ping me on twitter. Don’t forget to follow @securityimpacts as well.
Originally published on June 15th, 2018