Dearcry Ransomware Microsoft Exchange Exploited

Executive Summary

Following high profile headlines of critical vulnerabilities affecting Microsoft Exchange servers, as detailed in our previous blog [1], proof-of-concept exploits have become publicly available and appear to have been utilized by a financially-motivated threat actor in the seemingly manual deployment of a new ransomware threat dubbed ‘Dearcry’.

First identified by Michael Gillespie (@demonslay225) in an 11 March 2021 tweet[2] (Figure 1), submissions to the researcher’s online service ‘ID Ransomware’ [3] were observed as originating from Microsoft Exchange server IP addresses and featured identifiers including a .CRYPT file extension and an encrypted file header of DEARCRY!.

Figure 1 – Initial observation by Michael Gillespie (Twitter: @demonslay335)

Current observations suggest that those behind these attacks are attempting to infect as many vulnerable Microsoft Exchange servers as possible which, given readily available exploits, could be considered ‘low hanging fruits’ with the potential for a lucrative return should victims pay the ransom demands.

Unlike big game hunter ransomware attacks, ‘steal, encrypt and leak’ or double extortion tactics do not appear to have be used and ransom demands are reportedly in the region of sixteen thousand US dollars ($16,000).

Based on our analysis, this ransomware threat appears to have been written hastily, likely in an attempt to capitalize on the immediate Microsoft Exchange vulnerability situation, and is therefore lacking in functionality or incomplete.

Specifically, there is no attempt to terminate any running processes prior to commencing the encryption phase and therefore security and backup solutions will continue to run, potentially allowing the threat to be detected and thwarted. Furthermore, the failure to terminate processes prevents the ransomware from encrypting ‘open’ files whilst the method of reading the original file into memory for encryption, writing this data to a new file and then deleting the original file could allow data recovery in some cases.

Whilst these ‘deficiencies’ may offer a modicum of relief to victims, the wide selection of file types that are encrypted will no doubt cause considerable damage to any affected host.

Utilizing the Open SSL library rather than the Windows CryptoAPI as favoured by many threat actors, the ransomware appears to encrypt data using AES-256 with the key being encrypted by an embedded RSA public key. Subsequently, this public key appears to be cryptographically hashed and this resulting value is embedded within the ransom note to allow a ‘decryptor’ to be provided by threat actor to a paying victim.

Of the samples we analysed, the RSA public key appears to be unique to each ransomware binary and it is therefore possible that threats are generated on a ‘per-victim’ basis.

Theoretically, if this is not the case and the same RSA public key is used for multiple victims, one paying victim would be able to share the decryption method with others targeted by the same threat.

Initial Compromise

Based on what is known so far, Microsoft Exchange servers targeted with this ransomware threat have been compromised via the following vulnerabilities as seen in the high-profile HAFNIUM attacks:

• CVE-2021-26855 – Server-side request forgery (SSRF) vulnerability, also known as ‘ProxyLogon’, allowing threat actors to send arbitrary HTTP requests and authenticate as the Exchange server .
• CVE-2021-26857 – Insecure deserialization vulnerability, allowing untrusted data to be processed, in the Exchange Unified Messaging Service leading to code execution with SYSTEM privileges.
• CVE-2021-26858 – Post-authentication arbitrary file write vulnerability allowing files to be written to any path on the Exchange Server.
• CVE-2021-27065 – Another post-authentication authenticated arbitrary file write vulnerability.

Notably, CVE-2021-26857 provides code execution which, in this instance, is likely exploited by the threat actor to execute the Dearcry payload with elevated privileges.

Upon execution the ransomware appears to have basic anti-analysis capabilities that attempt to determine if the process is being ‘debugged’ and, if not, proceeds to utilize the Windows Service Control Manager (SCM) via the OpenSCManagerA function to create and start a service named msupdate (Figure 2).

Figure 2 – Create of a Windows service named ‘msupdate’

In addition to providing an element of persistence, the creation of a service may be an attempt to ‘hide’ the ransomware process from casual inspection.

Encryption Process

Having created the ‘msupdate’ process, the ransomware makes use of the opensource ‘OpenSSL’ library to perform a cryptographic hash process on the embedded RSA public key which is then embedded into a ransom note template along with the threat actor email addresses (Figure 3).

Figure 3 – Ransom note creation (email addresses and victim hash replace the %s placeholders)

Highlighting the lack of complexity in this threat, the strings used within this process, and others, are clearly visible (Figure 4) within the ransomware executable demonstrating that the threat has not been ‘packed’ or ‘crypted’, tactics commonly used to evade detection by antivirus solutions.

Figure 4 – Strings clearly visible within the ransomware executable

Subsequently, the Windows directory is identified using the C++ _getenv() function to query the %WINDIR% environment variable prior to enumerating the logical drives available on the compromised host (Figure 5) using the GetLogicalDrives() and GetLogicalDriveStringsA() functions.

Figure 5 – Drive enumeration

Having determined which drives are available, the file enumeration process traverses each folder looking for potential files to encrypt, comparing file extensions against a fixed list of target file extensions. Notably, it appears that the threat actor responsible for this threat has updated the list of target file extensions on or around 8 March 2021, possibly to target a specific victim or to increase the effectiveness of their threat:

• Original file extension list (63 types; binary compiled 8 March 2021):
  .7Z .APK .APP .ASPX .BAK .BAT .BIN .C .CAD .CER .CFM .CGI .CONFIG .CPP .CSS .CSV .DAT .DB .DBF .DOC .DOCX .EDB .EML .GO .HTM .HTML .INI .ISO .JS .JSP .KEYCHAIN .LOG .LOG .MDB .MDF .MSG .ORA .PDB .PDF .PEM .PGD .PHP .PPS .PPT .PPTX .PS .PST .RAR .RTF .SQL .STM .TAR .TEX .TIF .TIFF .TXT .WPS .XHTML .XLS .XLSX .XLTM .ZIP .ZIPX
• Updated file extension list (80 types; binary compiled 9 March 2021):
  .7Z .APK .APP .ASPX .AVI .BAK .BAT .BIN .BMP .C .CAD .CAD .CER .CFM .CGI .CONFIG .CPP .CSS .CSV .DAT .DB .DBF .DLL .DOC .DOCX .DWG .EDB .EDB .EML .EXE .GO .GPG .H .HTM .HTML .INI .ISO .JPG .JS .JSP .KEYCHAIN .LOG .LOG .MDB .MDF .MFS .MSG .ORA .PDB .PDF .PEM .PGD .PHP .PL .PNG .PPS .PPT .PPTX .PS .PST .PY .RAR .RTF .SQL .STM .TAR .TEX .TIF .TIFF .TXT .WPS .XHTML .XLS .XLSX .XLTM .XML .ZIP .ZIPX

Once a file match has been found, the file appears to be opened, presumably in an attempt to determine if the file is ‘locked’ by some other process, and the first eight characters are read to determine if the file has already been encrypted as indicated by a DEARCRY! file header, 44 45 41 52 43 52 59 21 in hexadecimal (Figure 6/7).

Figure 6 – Determine if the file is already encrypted with a DEARCRY! header

Figure 7 – Encrypted file header

Whilst more advanced ransomware threats utilize methods such as the Windows Restart Manager to handle open files, such as seen in Babuk Locker [4], open files appear to be ignored by Dearcry and will not be encrypted.

Again demonstrating an apparent lack of sophistication, the original filename is copied into a new string and .CRYPT appended in preparation for the creation of a new ‘encrypted’ file (Figure 8).

Figure 8 – New ‘encrypted’ file creation process

This method appears to read the original file into memory and encrypted before being written to a ‘new’ encrypted file, rather than modifying the original file ‘in-place’, and the original being deleted (Figure 9).

Figure 9 – Encrypted file closed and original file deletion

Given this approach, and likely dependant on the disk configuration of the compromised host, it may be possible to recover some encrypted data directly from disk.

Finally, once the encryption process is complete the ransom note, as prepared earlier, is written to the desktop in a file named readme.txt (Figure 10).

Figure 10 – Ransom note

Recommendations

• Organizations with vulnerable Microsoft Exchange on-premise servers should assume breach and take immediate steps to implement Incident Response, our previous bulletin and the regularly updated Microsoft article (https://github.com/microsoft/CSS-Exchange/tree/main/Security) provide further details of security updates and Microsoft recommended mitigations.
• Business continuity and disaster recovery planning can help an organization be prepared for a ransomware ‘worst-case scenario’ by providing the ability to successfully restore data and recover from an attack.
• Continuous monitoring of host security events and unusual behaviours, such as excessive file operations, high CPU usage due to SYSTEM privileged process can provide an early indication of compromise or nefarious activity.
• Application permit and deny lists can be used detect and prevent the execution of an unauthorized or unknown executable, effectively hardening a host against attack.
• Wherever possible, organizations should seek to remediate ransomware attacks rather than making ransom payments as these serve only to perpetuate the problem and fund further threat developments.

Indicators of Compromise

File Hashes (SHA256)

The following file hashes have been observed as recent Dearcry samples and are provided for reference.

• 10BCE0FF6597F347C3CCA8363B7C81A8BFF52D2FF81245CD1E66A6E11AEB25DA
• 17c5161451b5edd31d903fb020afc7f9f2f130fea8fbd9248e069dde7f80efa3
• 2B9838DA7EDB0DECD32B086E47A31E8F5733B5981AD8247A2F9508E232589BFF
• E044D9F2D0F1260C3F4A543A1E67F33FCAC265BE114A1B135FD575B860D2B8C6
• FDEC933CA1DD1387D970EEEA32CE5D1F87940DFB6A403AB5FC149813726CBD65
• FEB3E6D30BA573BA23F3BD1291CA173B7879706D1FE039C34D53A4FDCDF33EDE
• 6834d9f4a9e1888d82c70b72f30ced8aa68c009b55d03efffc94c466fbb3d047
• 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27

Example YARA Rule

Based on strings observed within the initial Dearcry samples, the following basic YARA rule will match similar samples.

rule dearcry_ransomware
{
  strings:
    $str1 = "msupdate"                           // Service name
    $str2 = "DEARCRY!"                           // Encrypted file header
		$str3 = "EncryptFile.exe.pdb"                // PDB artefact    
		$str4 = "/readme.txt"                        // Ransom note filename
    $str5 = "Your file has been encrypted!"      // Ransom note content
		$str6 = "please send me the following hash!" // Ransom note content
  condition:
      all of them
} 

Files

• Ransom note: readme.txt
• Encrypted file extension: .CRYPT

Email Addresses

• konedieyp@airmail[.]cc
• uenwonken@memail[.]com

Notably, airmal[.]cc redirects to ovo[.]sc, a domain hosted on a suspected malicious Romanian ASN (Figure 11).

Figure 11 – OVO Systems

Analysis of the DNS associated with this service indicates that it resolves to cock[.]li (Figure 12), a ‘privacy’ email service with the SPF records pointing to mail[.]cock[.]li, hosted on a suspected malicious Serbian ASN, M247 Ltd Belgrade (Figure 13) .

Figure 12 – DNS resolution

Figure 13 – Mail.Cock[.]li

Encrypted File Extensions

• Original file extension list (63 types; binary compiled 8 March 2021):
  .7Z .APK .APP .ASPX .BAK .BAT .BIN .C .CAD .CER .CFM .CGI .CONFIG .CPP .CSS .CSV .DAT .DB .DBF .DOC .DOCX .EDB .EML .GO .HTM .HTML .INI .ISO .JS .JSP .KEYCHAIN .LOG .LOG .MDB .MDF .MSG .ORA .PDB .PDF .PEM .PGD .PHP .PPS .PPT .PPTX .PS .PST .RAR .RTF .SQL .STM .TAR .TEX .TIF .TIFF .TXT .WPS .XHTML .XLS .XLSX .XLTM .ZIP .ZIPX

• Updated file extension list (80 types; binary compiled 9 March 2021):
  .7Z .APK .APP .ASPX .AVI .BAK .BAT .BIN .BMP .C .CAD .CAD .CER .CFM .CGI .CONFIG .CPP .CSS .CSV .DAT .DB .DBF .DLL .DOC .DOCX .DWG .EDB .EDB .EML .EXE .GO .GPG .H .HTM .HTML .INI .ISO .JPG .JS .JSP .KEYCHAIN .LOG .LOG .MDB .MDF .MFS .MSG .ORA .PDB .PDF .PEM .PGD .PHP .PL .PNG .PPS .PPT .PPTX .PS .PST .PY .RAR .RTF .SQL .STM .TAR .TEX .TIF .TIFF .TXT .WPS .XHTML .XLS .XLSX .XLTM .XML .ZIP .ZIPX

IP Addresses Involved

The following list of IP’s was observed to be exploiting vulnerable Exchange servers in the wild, infecting them with Dearcry. However, since the publication of the exploits, it is safe to assume that this list may not be complete and likely include proxy, Tor exit nodes and/or VPN endpoints.

• 103.137.63.195
• 103.212.223.210
• 103.213.247.41
• 104.248.49.97
• 118.189.41.34
• 130.255.189.21
• 137.116.145.209
• 139.162.98.150
• 139.59.56.239
• 157.230.221.198
• 161.35.1.207
• 161.35.1.225
• 161.35.51.41
• 165.232.154.116
• 167.99.239.29
• 168.63.134.28
• 178.20.181.209
• 182.153.128.230
• 182.239.123.241
• 182.239.124.180
• 185.250.151.192

Ransom Note Template

The ransom note is represented within the threat binary as a string containing \n newlines, \t tabs and two %s string variables, the first of which being the threat actor contact email addresses and the second being a victim identifier:

"Your file has been encrypted!\n\t\t\t\t\t\t If you want to decrypt, please contactus.\n\t\t\t\t\t\t %s\n\t\t\t\t\t\t And please send me the following hash!\n\t\t\t\t\t\t%s\n"

Observed RSA Public Keys

• 027119161d11ba87acc908a1d284b93a6bcafccc012e52ce390ecb9cd745bf27
• fdec933ca1dd1387d970eeea32ce5d1f87940dfb6a403ab5fc149813726cbd65
• E044D9F2D0F1260C3F4A543A1E67F33FCAC265BE114A1B135FD575B860D2B8C6

• 10bce0ff6597f347c3cca8363b7c81a8bff52d2ff81245cd1e66a6e11aeb25da
• feb3e6d30ba573ba23f3bd1291ca173b7879706d1fe039c34d53a4fdcdf33ede

• 17c5161451b5edd31d903fb020afc7f9f2f130fea8fbd9248e069dde7f80efa3
• 2b9838da7edb0decd32b086e47a31e8f5733b5981ad8247a2f9508e232589bff
• 6834d9f4a9e1888d82c70b72f30ced8aa68c009b55d03efffc94c466fbb3d047

• C:\Users\john\Documents\Visual Studio 2008\Projects\EncryptFile -svcV2\Release\EncryptFile.exe.pdb

References

[1] https://blog.cyberint.com/hafnium-microsoft-exchange-server-vulnerability-bulletin

[2] https://twitter.com/demonslay335/status/1370125343571509250

[3] https://id-ransomware.malwarehunterteam.com/

[4] https://blog.cyberint.com/babuk-locker

[5] https://techcommunity.microsoft.com/t5/exchange-team-blog/released-march-2021-exchange-server-security-updates/ba-p/2175901