[EN] Hermes Ransomware Technical Analysis
At the end of January 2018, the KrCERT published CVE-2018–4878 of an Adobe flash player 0-Day. According to the published vulnerability, this vulnerability exists in Adobe Flash Player 28.0.0.137 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 our technical analysis.
Behavioral analysis
When we first run malware, the ransomware copies itself 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 running ransomware, ransomware wants to run some files with administrator permission. Frankly speaking, when the user wants to cancel, it is revealed again. We can say that they tried to push users in 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 it, 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, the public key was created under the RSA1 name.
When we open another file, it is an encrypted block of data named UNIQUE_ID_DO_NOT_REMOVE. As you can see, it is all encrypted with an 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 gives 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 the HTML file. As you can see, there is a two mail addresses. One of them is the primary email and is a Gmail account. Another one is the reserve email and it is a keemail account. When I check the analysis of other analysts, I saw different emails which are like ProtonMail, Bitmessage, and india.com.
Unpacking Malware
After behavioral analysis, we can begin unpacking progress.
Let’s open a ransomware sample with x64Dbg. So let’s set a 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.dlland 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 APIs 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 above, we have to remember that it is 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 enter to run our process and start watching these breakpoints to see where the memory is allocated. So after the run process, of course, the breakpoint is the entry point. After the second run process, we are going to the second Breakpoint, RET 10. If we check EAX values, EAX has the address of the new 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 continuing 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.