Overview

Recently, I came across a fresh ransomware group known as “Donex” which emerged in February of this year. After the recent takedown of LockBit and the exitscam of ALPHV/BlackCat, the ransomware landscape is ripe for a new dominant player. Today I obtained a sample of this ransomware from MalwareBazaar and decided to analyze it further. In this blog post, we will explore the inner workings of Donex ransomware.

Sample information

SHA256: 0adde4246aaa9fb3964d1d6cf3c29b1b13074015b250eb8e5591339f92e1e3ca

Timestamp: 2024-02-18

Compiler: Microsoft Visual C++

Filetype: Executable

Imported DLLs: Kernel32.dll, User32.dll, Shell32.dll, Advapi32.dll, Mpr.dll, Ws2_32.dll, RstrtMgr.dll

Entrypoint

Entrypoint Figure 1: Entrypoint

This ransomware starts by hiding it’s window. After making it’s console window invisible by calling the FindWindowA and ShowWindow API, it proceeds to execute three different subroutines: sub_4030D0, sub_403340, sub_402F40, which I have denoted as mw_setup, mw_core_func, and mw_cleanup, respectively. These are the primary subroutines that the malware is divided into.

Mutex creation Figure 2: Mutex creation

In summary, mw_setup creates a Mutex named “CheckMutex” to check if the encryptor is already running on the system; if it is, the second instance is terminated to avoid interference with the first instance of the encryptor. Additionally, it removes the Volume shadow copies to prevent recovery of encrypted files. This is achieved by utilizing the WinExec API with the commands “cmd c wmic shadowcopy delete nointeractive” and “cmd c vssadmin Delete Shadows All Quiet”. It’s important to note that WinExec is called twice, deleting shadow copies using wmic initially and VSSAdmin subsequently.

Shadow Volume Copies

Shadow volume copy deletion using wmic Figure 3: Shadow volume copy deletion using wmic

Inside x64dbg, we can notice that after hitting a breakpoint on WinExec the second argument on the stack is the string “cmd c wmic shadowcopy delete nointeractive”, which will initiate a removal of the volume shadow copies using wmic.

Shadow volume copy deletion using VSSAdmin Figure 4: Shadow volume copy deletion using wmic

Deletion of the volume shadow copies using VSSAdmin via WinExec again.

Salsa20 key generation and encryption using RSA Figure 5: Salsa20 key generation and encryption using RSA

Upon removal of the Volume shadow copies, the encryptor generates a Salsa20 key for encrypting the system files. Subsequently, the generated Salsa20 key is passed to a function, denoted as mw_encrypt_salsakey, which encrypts the Salsa20 key using RSA.

Allocation of 10 bytes for the campaign id Figure 6: Memory allocation of 10 bytes for storing the campaign ID

Within the mw_encrypt_salsakey function, a call to malloc is performed for the campaign ID. Specifically, 10 bytes are allocated, with 9 bytes reserved for the campaign ID itself and 1 byte for the null terminator. For this particular sample, the campaign ID is defined as “f58A66B51”, note that this value is a constant which is not randomly generated.

Dropping logo on to the disk and create registry key that points to the path Figure 7: Creation of registry key that points to the icon.ico

After generating and encrypting the Salsa20 key using RSA and setting up the campaign ID, the encryptor drops a file named “icon.ico” into the C:\ProgramData\ directory. This file acts as the logo or icon for the encrypted files. Then, it creates two registry keys. The first one is HKEY_CLASSES_ROOT.f58A66B51, and the second one is HKEY_CLASSES_ROOT\f58A66B51file\DefaultIcon. The first key holds the name of the second key, while the second key holds the path to the icon used for the encrypted files.

First registry key Figure 8: First registry key

This is the first registry key, note that it is filled with the name of the second registry key.

Second registry key Figure 9: Second registry key

This second registry key holds the path to the recently created .ico file on disk.

Dropping 1.bat script, which is used to kill processes that might interfere with encryption Figure 10: Dropping process killer bat script

Afterwards, the encryptor places a .bat file to the C:\ProgramData path named “1.bat” and fills the recently created file with the commands passed to the fwrite function. It turns out this file is used for killing processes that might interfere with the encryption process.

Contents of the bat script, following processes are killed:

“sql.exe”, “oracle.exe”, “mysq.exe”, “chrome.exe”, “veeam.exe”, “firefox.exe”, “excel.exe”, “msaccess.exe”, “onenote.exe”, “outlook.exe”, “powerpnt.exe”, “winword.exe”, “wuauclt.exe” Contents of the bat script Figure 11: Contents of the bat script

Encryption

Prior to the encryption, the encryption routine will set the file attributes to FILE_ATTRIBUTE_NORMAL. Afterwards, it will append the campaign ID (.f58A66B51) to the end of the file.

Open Handle to File Figure 12: Opening File handle

The file gets encrypted using a 128-bit Salsa20 key, note that the Salsa key and Nonce are the same for every single file (this will be important for an upcoming post).

Encrypt File Figure 13: File encryption

Once the encryption has finished, the encryptor will create a Read-Me text file that serves as a ransomnote.

Format readme path Figure 14: Formating readme path

Read-Me creation.

Create ReadMe File Figure 15: Creation of the readme file

Cleanup

Once all files on the system are encrypted, the encryptor executes the mw_cleanup function, aimed at cleaning up. Initially, it deletes the event logs, then terminates cmd.exe and conhost.exe processes. Finally, it removes the 1.bat script and its own image from the disk. Lastly it will initiate a system restart using the WinExec API and “shutdown -r -f -t” as it’s parameter.

Cleanup Figure 16: Cleanup

Conclusion

Program Flow

  1. Hide console window
  2. Create Mutex to prevent double execution
  3. Delete volume shadow copies
  4. Terminate interfering processes
  5. Stop interfering services
  6. Generate Salsa20 key and encrypt it with RSA public key
  7. Enumerate files and directories
  8. Check whitelist for directories and file extensions
  9. Append campaign ID to each file that is eligible to be encrypted and encrypt their contents using the Salsa20 stream-cipher
  10. Create readme for each directory
  11. Perform cleanup after system encryption
  12. Restart the system

Yara Rule

rule DonexRansomware {
    meta:
        author = "dissect.ing"
        malware = "Donex Ransomware"
        created = "03/27/2024"
        description = "rule to detect Donex ransomware"
    strings:
        $mz = "MZ"
        $s1 = "IsWow64Process"
        $s2 = "cmd /c C:\\ProgramData\\1.bat"
        $s3 = "ping 127.0.0.1 -n 2 >nul"
        $s4 = "cmd /c \"ping 127.0.0.1 & del C:\\ProgramData\\1.bat & del %s\""
        $s5 = "cmd /c \"taskkill /f /im cmd.exe & taskkill /f /im conhost.exe\""
        $s6 = "security"
        $s7 = "system"
        $s8 = "application"
    condition:
        all of them
}

References

https[:]//bazaar.abuse.ch/sample/0adde4246aaa9fb3964d1d6cf3c29b1b13074015b250eb8e5591339f92e1e3ca/

https[:]//sinkhole.dev/writing-a-string-decryptor-for-cargobay/

https[:]//n1ght-w0lf.github.io/malware%20analysis/smokeloader/

https[:]//invokere.com/posts/2024/02/automating-qakbot-malware-analysis-with-binary-ninja/

https[:]//chat.openai.com/