At the end of January 2018, the KrCERT published CVE-2018-4878 of a Adobe flash player 0-Day. According to the published vulnerability, this vulnerability exist in Adobe Flash Player 188.8.131.52 and below. The vulnerability was distributed via malicious Office documents containing the embedded Flash exploit. Only a couple of weeks before the public announcement, it was already started to target users. As of February 1 2018 , Adobe has announced patching for this.
After a brief description of the Hermes ransomware, we can start to our technical analysis.
When we first run malware, the ransomware copies itself into under the AppData–>Local–>Temp. We also notice that an exe file called Svchost has been created.
From my past experiences, when some ransomware works in this style, it was created that kind of documents. But after a while, it was deleted. But I haven’t seen this kind of behavior throughout my analysis process.
Additionally, after run ransomware, ransomware want to run some file with administrator permission. Frankly speaking, when the user wants to cancel, it is reveals again. We can say that they tried to push users with this way to accept.
When we check the above picture, we can see that the contents of the file to be run. The batch script is responsible for removing the shadow copies and all other backups.
We can see that the batch script dropped inside C:\Users\Public with some other files from the above picture.
In addition, we can see that two 1 KB files have been created. When we open, the file “PUBLIC” contains a blob with RSA public key. If I understand right, the RSA public key pair is generated per victim. If you check the above picture, public key created under RSA1 name.
When we open the another file, it is an encrypted block of data named UNIQUE_ID_DO_NOT_REMOVE. As you can see, it is all encrypted with RSA key.
Let’s check our last file, DECRYPT_INFORMATION.html. As with other ransomware, when we open the file, the information screen comes up. The first thing that catches my attention is that it is in 5 different languages. The malware writer also giving one decrypter code to open one file.Specifically, he/she wanted to give trust to users and companies that it would open the files after payment. Trust is an important matter 🙂
Let’s continue to check html file. As you can see, there is a two mail address. One of them is primary email and it is gmail account. Another one is reserve email and it is keemail account. When I check the analysis of other analysts, I saw different mails which is like ProtonMail, Bitmessage and india.com.
After behavioral analysis, we can begun unpacking progress.
Let’s open ransomware sample with x64Dbg. So let’s set breakpoint on VirtualAlloc. So we are going to use Ctrl+G and we will type in the label, VirtualAlloc.
After this first step, here’s our first interesting thing that we are in Kernel32.dll and we have gone to VirtualAlloc function.
But I would like to point out that we did not reach any real code where we are now. There is a just jump and the jump goes up to another jump which jumps into another Dll file.
When we do Following in Disassemble–>Value and follow, we will see that we are now in KernelBase.dll. Then we will reach Virtual Alloc function in Kernel Base. Microsoft has moved some Core Api’s into something called Kernel based DLL and VirtualAlloc is one of them. So even though you import Kernel32.dll and use the VirtualAlloc function there it is just a redirect to Kernel base. But as far as I’m looking, they are trying to make a minimum set of Apis that exist for Windows to run.
If we want to set breakpoints on VirtualAlloc like a above, we have to remember that it is actually not in Kernel32. It is in KernelBase.
After a brief information stage, we continue where we left off. So we are going to set a breakpoint on the Return from VirtualAlloc. Because when it return, it will take the basic address of the memory allocated or allocated to it.
As in many analyzes, we always put a breakpoint on RET 10. In this part of the analysis, we will check EAX values. This section will give us the base address of the new memory segment that’s been allocated right now.
We will do enter to run our process and start watching these breakpoints to see where the memory allocated. So after the run process, of course the breakpoint is the entry point. After second run process, we are going to second Breakpoint, RET 10. If we check EAX values, EAX has the address of the newly virtual memory section.
When we dump this section, that’s going to show us the memory section. Checking the all dump and we realize that there are NULL bytes. Because this section has only been charged. That’s why we are continue our run process.
After this process, when we scroll down the dump section, we see the section tables of the PE file which is like text, rdata, data and rsrc. We will save this file and then we will finish part of unpacking process. Then, we will open the file with UPX unpacker. Then we will check with IDA Pro.
I will just share some screen from the IDA Pro.
Thanks for your patience.