A recently-patched set of vulnerabilities in on-premises versions of Microsoft Exchange Server has been actively exploited for over two months. The exploit, initially attributed to a Chinese state-sponsored actor, has now been adopted for a range of cybercrime activities—the latest being a ransomware called DearCry. Sophos recently detected and stopped a DearCry attack using the exploit, and obtained samples for analysis.
The DearCry ransomware appears to be created by a beginner—it is unsophisticated, and does little to hide itself from detection. Its most notable feature is that the encryption header that DearCry adds to the attacked files looks similar to the header used by the notorious WannaCry ransomware, which seems more than a coincidence.
The exploit
The bugs leveraged in the exploit—CVE-2021-26855 and CVE-2021-27065—were uncovered and reported to Microsoft in December by researchers at DEVCORE. On New Year’s Day, the DEVCORE researchers chained the bugs together and created a workable pre-authentication remote code execution exploit they dubbed “ProxyLogon,” as it exploits bugs in Exchange’s proxy architecture and logon mechanism .
DEVCORE contacted the Microsoft Security Response Center through its MSRC portal on January 5, 2021, with a 120-day public disclosure deadline. On February 18, MSRC confirmed the bug would be fixed in the March 9 “Patch Tuesday” release. But Microsoft was prompted to make an out-of-band patch release on March 3 after the memory analysis and incident response company Volexity reported in-the-wild exploitation.
According to Volexity, in-the-wild exploitation appears to have started as early as January 6, 2021—the day after the proof-of-concept was submitted to Microsoft. Volexity observed the attacker writing webshells (ASPX files) to disk and conducting further operations to dump credentials, add user accounts, steal copies of the Active Directory database, and move laterally to other systems and environments. Microsoft Threat Intelligence Center (MSTIC) attributed this campaign with high confidence to HAFNIUM, a group assessed to be state-sponsored and operating out of China, based on observed victimology, tactics and procedures.
After investigation, DEVCORE confirmed that the in-the-wild exploit observed by Volexity was the same one DEVCORE submitted to Microsoft. The exploited path in the exploit attacks is similar (/ecp/<single char>.js) and the webshell password is “orange” (hardcoded by DEVCORE exploit developer Orange Tsai @orange_8361).
Sophos first detected and blocked a DearCry attack on a customer’s network in Austria on March 13. A few days earlier, on March 11, the same Exchange server was hit with a webshell, which was also blocked.
DearCry
The anti-ransomware team within SophosLabs evaluated two samples of DearCry for this analysis. In both cases, the binaries were unsigned, and showed no evidence of version control or other professional development practices. The binaries had no defense against anti-virus signatures—they were not packed or obfuscated, so all ransomware text strings are in plain sight for detection by analysts and signature-based malware protection. The absence of these characteristics leads us to believe that the ransomware author is a beginner, or that this is an early prototype.
Both samples contained an identical PDB reference to the machine and source file used to compile the malware binary:
C:\Users\john\Documents\Visual Studio 2008\Projects\EncryptFile -svcV2\Release\EncryptFile.exe.pdb
Each binary appeared to be created specially to be delivered to the victim. DearCry uses a fully standalone encryption method, with the public key embedded within the ransomware binary, so it does not have to contact a C2 server in order to begin encrypting files. The two samples we studied were sent to different victims, and had different unique identifiers in their ransom notes, and used different keys.
Crypto combo
Before encrypting a file, DearCry first creates a new file with a filename based on the name of the document it attacks, but adds a .CRYPT file extension. Once created, DearCry starts reading contents of the original file and writes it back, encrypted, into the .CRYPT file.
There are two different encryption methods used by DearCry. Files are encrypted using the AES-256 symmetric encryption algorithm, using an OpenSSL library embedded in the ransomware.
But the AES key itself is encrypted by the attacker with an RSA public-key algorithm. A public key for decrypting the AES key is embedded in the code, but the private key is retained by the attacker. Using the RSA encryption of the AES key allows the actor to deploy the ransomware without needing a command and control server to deploy the key. And the DearCry actor can create a ransomware binary for each victim, with a unique, victim-specific public encryption key. However, based on our findings, the actor has attempted to deliver the same binary to multiple victims.
Interestingly, the list of file-types the ransomware targets can differ per victim. For example, popular image files (like JPG), CAD drawings, programs (EXE) and dynamic link libraries (DLL) were not targeted in sample 1, which seems earlier distributed according to the compiler timestamp. Most other ransomware families exclude programs and DLLs from their list of encryption targets, because encrypting the wrong files can result in the computer becoming unbootable, which makes it much harder for the victim to read the ransom note.
Looking at these file types, DearCry also targets ASPX files. This would mean the attacker could encrypt an Exchange webshell that allowed hands-on-keyboard from remote. This leads us to believe that the ransomware may not be deployed via a webshell, or that the attacker has no interest in keeping webshell-access. The later variant (sample 2) also targets installed software, i.e., EXE and DLL files, effectively making the machine useless:
DearCry and WannaCry
Intriguingly, 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.
The above two images compare an encrypted file Desert.jpg, a sample picture from a default Windows 7 machine. Both DearCry and WannaCry add their name at the beginning of the file. Furthermore, in WannaCry the highlighted parts represent file type and the size of the original unencrypted file. File type at offset 0x010C and file size at offset 0x0110.
The hybrid approach
From an anti-ransomware perspective, looking at DearCry’s file system behaviors reveals more interesting details. The following table illustrates its behavior for each file DearCry attacks (these can be observed using Process Monitor):
From this behavior, DearCry is what we’d normally call a Copy ransomware. It creates encrypted copies of the attacked files and deletes the originals. 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.
Compared to DearCry, more notorious human-operated ransomware like Ryuk, REvil, BitPaymer, Maze and Clop, are In-Place ransomware, where the attack immediately causes the encrypted file to be stored on logically the same sectors as the original document, making recovery via undelete tools impossible.
But DearCry has an added trick to make recovery impossible. Before deleting the original document and after closing the encrypted copy, it also overwrites the original document. This means DearCry has a hybrid encryption approach: it performs both a Copy and In-Place encryption attack.
This approach is not common. It is so uncommon, the only ransomware that comes to mind that also employed a hybrid approach was WannaCry. It also first created an encrypted copy and then overwrote the original file to prevent recovery:
Details about file system behaviors of notorious ransomware, including WannaCry, are documented in our How Ransomware Attacks whitepaper.
These attributes don’t directly link DearCry to WannaCry’s creator. DearCry’s code, approach and abilities differ significantly from WannaCry: it does not use a command-and-control (C2) server, has an embedded RSA encryption key, shows no user interface with a timer and – most importantly – does not spread itself to other machines on the network. And the DearCry ransomware binary itself does not delete volume shadow copies.
Ransom notes
To inform victims about what happened and who they must contact, a file ‘readme.txt’ is dropped in every folder containing the word ‘desktop’ and in the root folder of the system disk. This ransom note contains two e-mail addresses and a hash. This hash is an identifier, so the attacker knows what decryption key is associated with the specific attack.
Detections
Sophos customers may see DearCry detected as Troj/Ransom-GFE. In some circumstances, the endpoint protection tools on affected Exchange servers also detected a web shell dropped a couple of days before the ransomware; Those components will be reported as Troj/WShell-A.
Specific indicators for the samples described herein have been published to the SophosLabs Github.
Acknowledgments
SophosLabs would like to acknowledge the contributions of Alex Vermaning and Fraser Howard to this report.
