Ransomware used to target Microsoft Exchange Servers.
Recently attackers of APT groups started-off targeting Microsoft Exchange Servers after the flaw( 0day ) in the Microsoft exchange servers was published on github. As the 0day exploit is being published on github attackers of APT groups started hacking on MS-Exchange servers by scanning the servers for the 0day vulnerability and ransom’ing servers with the DearCry ransomware. In this blog i will be walking you through the reverse engineering of DearCry ransom where you will be seeing me reversing DearCry ransom for Static and Dynamic Analysis.
Static and Dynamic Analysis
Static Analysis (Basic)
Static Analysis (Advanced)
Starting off from exports in DearCry Ransomware which is only one.
There are two function in the start function, one is “calc_stack_canary_cookie_and_bof_mitigation function” and another one is “main _app” function.
This function is being used for calculating stack cookies and buffer overflow mitigation.
It’s the main function, where firstly the heap is being created using “heap_create” , throughout this main module there is the functions like “anti_dbging_laoding_dlls_checks” & “anti_dbg_load_dlls_thread_ops” are being used as anti-debugging and for loading dlls and handling threads operations.
This module makes calls to “callr_anti_debigging_checks_and_loading_dlls” & what this module does is that same kinda behaviour analysis on system environment on which the ransom is being debugged and the same function load dlls. & another function which is being called in this module is that “load_dlls_callr” which is the deployed for the loading dlls that loads dynamic linked library in the infected system.
what this module does is that it scramble up the data present in the infected system.
In this module, mainly what happens in this is, it has three functions “callr_anti_debigging_checks_and_loading_dlls” , “anti_debigging_checks_and_loading_dlls” & “thread_ops”. Where first function in it is a function which calls a function “anti_debigging_checks_and_loading_dlls” in which the anti debugging checks & loading of dlls happens. Lastly, the function “thread_ops” is being deployed in this function where the thread operations happens.
In this function, using “anti_debugging_checks” the anti debugging happens whereas using the function “main_app_of_loading_dlls” dlls are being loaded.
To get the thread value functions like TlsGetValue is being used whereas using the GetModuleHandleW function handle is being retrieved using this function & using “load_module_after_sleep” module is being loaded after execution of sleep.
In the main function, fake “msupdate” service is being started whereas their are two functions in this module which are “RSA_encryption_ops” and “encryption_service_ops” are being used.
In this function, “encryption_service_ops” is used for starting the service.
This the function which is being used for starting the services for encrypting data on infected system.
Some of the other interesting functions related to encryption/decryption keys operations , encryption/decryption operations.
This function is used for exporting key for encryption key using CryptExportKey().
In this function, the encryption and decryption of data of victim infected system is being handled.
This function is being used for carrying out key operation.
This function is being deployed for generating private key.
Algorithms used for DearCry Ransomware are RSA and CALG_SHA1 .
Dynamic Analysis (Advanced)
For the DearCry Ransom i had set the following breakpoints:-
……:- fill_up_cache and other following breakpoints are shown below
First off the debugger hits at the function in the start module which is “Anti_Analysis_and_Anti_VM_checks”.
As we debug the DearCry Ransom further we will see it falling in the “Anti_Analysis_and_Anti_VM_checks” function.
In further debugging we will see that the debugger hits at the function “main_app” present in the start function.
As debugging further DearCry Ransom, we see that debugger jumps inside the main_app function.
on further debugging an exception is raised as shown.
On the further debugging, debugger hits inside the following database as shown below.
Then after that, debugger hits at the function “fill_up_cache”.
Then soon after that the debugger hits at the function “callr_of_heavy_val_loader” who function is to load heavy bits in the cache of infected victim system.
Then after that the debugger hits at the function “RSA_Key_Ops” in which the encryption/decryption key operations happens on the system using RSA algorithm.
As debugging continues, the debugger hits at the “private_key_generation” function in which the private key is being generated.
As the move in further debugging , we encounter with debugger hitting at the “file_ops” function.
Indicators of Compromise (IOCs) & Detection
Samples from Report
MD5: cdda3913408c4c46a6c575421485fa5b .