Malware analysis

DearCry ransomware: How it works and how to prevent it

Microsoft released a patch to mitigate four critical vulnerabilities on Microsoft Exchange servers in early March 2021. From this moment, criminals exploited these flaws in the wild using many threats, including DearCry, a piece of ransomware variant designed to take advantage of vulnerable Microsoft Exchange servers.

The new ransomware for Microsoft Exchange servers globally takes advantage of the ProxyLogon vulnerabilities and the exploits are then published on several resources on the internet.

According to Michael Gillespie, owner of the ID-Ransomware platform, a new ransomware note and encrypted files were submitted on March 9 into the online platform, and after an analysis of the files, he discovered that users submitted almost all of the files from Microsoft Exchange servers.

Some days after, Philip Misner, a researcher from Microsoft, confirmed on Twitter that the DearCry was installed in human-operated attacks using the recent Microsoft Exchange exploits.

Figure 1: DearCry ransomware related to the Microsoft Exchange vulnerabilities on 12th March 2021.

DearCry and what it does

Looking at the samples of the DearCry ransomware, it’s interesting to highlight the timestamp of the compiler and debugger “Mar 09,” the day the binary was compiled and the same date mentioned by Michael Gillespie on Twitter, confirming our suspicions.

Figure 2: DearCry compilation date from March 9, 2021.

By analyzing the import address table (IAT) of the binary file, we can observe that many cryptographic calls from advapi32.dll and crypt32.dll DLLs are present on the ransomware file, a clear sign we are facing a ransomware threat.

Figure 3: Cryptographic calls used by DearCry during the file encryption process.

Another interesting artifact found is the path of the PDB file present inside the binary, which shows the string “svc,” a common acronym often used for designating the term service. And also “john,” probably the computer name where the binary was compiled by the malware author.

Figure 4: Path of the PDB file of the DearCry ransomware.

Digging into the details

The first time DearCry is started, a new Windows service is created with the name “msupdate.” This service is then responsible for the encryption process and removed later when the encryption process is terminated. Figure 5 below shows some details about this service, namely (i) OpenServiceA, and (ii) DeleteService Windows calls.

Figure 5: Service named “msupdate” created when the ransomware binary is started.

The encryption process starts with a copy of the original file. After that, the content of the original file is loaded, encrypted, and written into the new file. Once created, DearCry adds a new file extension called “.CRYPT.”

Figure 6: CRYPT extension added to a new file with the original content encrypted.

From the analyzed binaries, we assume that each DearCry sample file is created especially to be delivered to the target victim as we found different keys in different binary files. In detail, DearCry uses a standalone encryption method with the RSA public key hardcoded inside the ransomware file. During the infection process, the ransomware doesn’t contact any command and control server to get additional encryption keys or even to inform about the status of the encryption process.

According to the Sophos report, "There are two different encryption methods used by DearCry ransomware. Files are encrypted using the AES-256 symmetric encryption algorithm, using an OpenSSL library embedded in the ransomware." Nonetheless, the AES key itself is encrypted by the malware author using an RSA public key also hardcoded inside the binary. On the other side, the private key is maintained by the malware author, an approach that allows deploying the ransomware without needing a C2 server to obtain the encryption key. In this way, the malware author can create a ransomware binary easily for each victim with the unique public key.

Figure 7: AES-256 encryption algorithm and RSA public key both hardcoded inside the DearCry binary file.

In addition, the DearCry will start to encrypt files on the target machine if it matches the following extensions:

Figure 8: DearCry target file’s extensions hardcoded inside the binary.

It’s interesting to highlight the ransomware is also encrypting ASPX file extensions, a clear sign the malware author can also encrypt and damage the Exchange web shell that allows getting a remote shell with the target machine. This leads us to believe that the ransomware may not be deployed via a web shell, or that the attacker has no interest in keeping web shell access.

Regarding the encryption process, at first glance, it seems quite weak as original files could be recovered after the encryption process. The next figure shows that DearCry creates a new file during the encryption process, and deletes the original one. As the Sophos report notes, "this causes the encrypted files to be stored on different logical sectors, normally allowing victims to recover maybe some data depending on whether Windows reuses the freed logical sectors."

Figure 9: DearCry creates a new file and deletes the original one after the encryption process.

However, DearCry developer added a trick that makes almost all of the files impossible to recover as before deleting the original document and after closing the encrypted copy, it also overwrites the original document, in this case, with a lot of “A” chars.

Figure 10: Origin file: DearCry ransomware file encryption block.

Figure 11: Origin file overwritten during the encryption process to prevent file recovery after delete.

The ransomware will also add the 'DEARCRY!' string to the beginning of each encrypted file.

Figure 12: DEARCRY! magic bytes added to the beginning of the encrypted file.

Finally, when the encryption process terminates, the ransomware will create the ransom note named 'readme.txt' on the Windows desktop and inside any folder available on the disk. This ransom note contains two email addresses for the threat actors and a unique hash, which is an MD4 hash of the RSA public key hardcoded inside the binary file.

Figure 13: Ransom note dropped during the ransomware encryption process.

Similarities between DearCry and WannaCry

According to a publication from Sophos Team, “the encryption header that DearCry adds to the attacked files looks similar to the header used by the notorious WannaCry — a  ransomware worm that shook the cyber-realm in May 2017.”

Figure 14: The same image encrypted with DearCry and WannaCry ransomware and their similarities.

 There are no artifacts that can prove these similarities, but the name of the magic bytes added during the encryption process, the size of the header, and even the file types are very interesting and should be part of this equation.

Preparing for DearCry ransomware

Criminals compromise victims’ networks and exfiltrate confidential documents while moving laterally in the infrastructure. Once the Microsoft Exchange servers or even valuable assets such as domain controller (DC) are compromised, crooks spread the ransomware throughout the infrastructure damaging all devices upon the active directory and other valuable assets available on the internal network.

In this sense, monitoring the use of endpoint security solutions, the use of updated antivirus and the increasing use of canary files are some mechanisms that could prevent the dissemination of these kinds of threats through an entirely corporative network.

Additionally, organizations are strongly advised to apply the patches as soon as possible to prevent attacks using ProxyLogin as the initial infection vector and also to create offline backups of their Exchange servers.

 

Sources

DearCry, Sophos

ProxyLogon, Segurança Informática

Ransomware deletion methods, Infosec. Institute