[Malware Studies] Cerber
I’m been focusing my studies in Reverse Engineering and Malware Analysis. The approach that I’m following is downloading the theZoo’s Ransomware samples and analyse them. The first one that I chose was Cerber.
SHA1 sample: c69a0f6c6f809c01db92ca658fcf1b643391a2b7
I started the analysis running the sample in x32gdb to watch the instructions while it’s executing to know the impact that the binary does so it can give some direction in the analysis.
Knowning what happens in the system after the execution. As Ransomwares have many variations, it’s important to know which version we are dealing with. The information about the Cerber version was got in this Myspybot blog post.
With the information that we got after the execution of the binary, now we know that we are dealing with the July 2017 version. Now let’s take a look in the subroutines and in the instructions inside them.
The first two subroutines can be found if we perform a static analysis, the third one is loaded in memory and the last one can be found in the binary but during the execution its instructions are modified in the third subroutine. Let’s see more about that.
Starting with the third subroutine, If there are contents being written in memory, we have to search for VirtualAlloc() function. It’s located inside the function 44f810.
After the execution of the function 44f870, we can see the value of the address in EDX, which is a value that changes in each execution but always ends in 0b20. Even with the address being selected, the values are still messed up, so we still need to search where the instruction values are defined.
If we toogle a hardware breakpoint in this address and execute the code, we will find that the instructions are defined in the address 44fb12, which is part of the function 44fad0 and can be reached from the function 44f870.
So, when we reach the function during the execution, we can see that the instructions are well defined.
Like I said before, the content of the fourth soubroutine is loaded during the execution of the third subroutine. If we use objdump in the binary, the content beginning in the address 40948E is the following:
This is different from the instrcution that we saw in the previous image, with the four subroutines and their instructions, so we need to find where the instructions are modified.
Toogling a hardware breakpoint in 40948E, we can found that in XX096E the function UnmapViewOfFile is called, zeroing 40948E, as we can see below.
Now that the addresses are zeroed, we need to find where the content is being loaded, so we have to use the hardware breakpoint again. With this breakpoint we can find that this occur in address XX0A0C, where a call to the function XX04B0 is made.
Starting to analyze this subroutine, the Process Monitor tool was used to monitor the calls in each function and understand better which one does. After the monitoring, the result was:
40d98b -> Load DLLs
402fef -> Reg query ComputerName
401270 -> Load Cryptography
4099e7 -> Load cerber.exe ; C:\test\cerber_debug.txt (Not Found)
402777 -> Load Cryptography
408dcb (does nothing)
40186e (not called, a jump is taken before it)
40936b -> Load DLLs ; WinSocket, Network ; Create files in AppData\Local\Temp
40b001 -> Ransomware Execution
After the execution of function 40b001 we can see the events of the file creation of the ransom note and some files being encrypt and renamed using the extension of this Cerber version.
Since this is my first post, I decided not to write something long enought, so I’m publishing just these informations but this post can be updated.
TODO:
- Network Analysis
- Write Yara Rules
