Donex a new ransomware gang

Threat Landscape

A new ransomware gang on the scene with a capable Windows based encryptor. Not much is known about the gang, but it has listed a number of victims on their site in the past few weeks across various business sectors. Encryptors have been showing up on Virus Total as well as Any.run in recent days.

The gangs contact information is located on their main leak site under the 'About' tab, which includes both an email and a TOX ID for contact.

Key points

Encryption of local and network files
Utilizes common Windows service APIs and system commands
Clears event logs

Although the encryptor is new, the gang has developed capable and stable features to rival other ransomware encryptors. These features range from cleaning up files used for the attack, restarting the machine, cleaning event logs, local and network file discovery and shutting down processes that may interfere with the encryption of high valued files. Most of these features are using common Windows API's to perform their work.

Build information

SHA256 Hash: 0adde4246aaa9fb3964d1d6cf3c29b1b13074015b250eb8e5591339f92e1e3ca

Program Flow

The 'main’ function starts off by hiding the encryptors window by getting a handle to the 'ConsoleWindowClass' using the 'ShowWindow' function. Once the window is hidden, it will run through three major functions that make up the bulk of the encryptor.

Pre-Encryption setup

The setup starts by creating a mutex to ensure that one copy of the encryptor is running, this is under the mutex name 'CheckMutex'. The encryptor will then get a pointer to the 'IsWows64Process' function by using the 'GetProcAddress' function to find the function address in 'kernel32.dll'.

Once obtained, it will then call the 'IsWoW64Process' function pointer. If the return value of the call was true, the sample will then disable the WoW64 file system redirection via the 'Wow64DisableWow64FsRedirection' call. This will be used to ensure the commands executed are done so without the file system redirection indicator turned on.

The encryptor will also read the machine name and the supported languages.

Before the encryptor can manipulate files it must acquiring a cryptographic context. This is done by calling the Windows 'CryptAcquireContextA', 'CryptAcquireContextA', and 'CryptGenRandom' functions. These functions are deprecated. Most applications have moved on to the supported cryptographic next generation APIs which are supported and are tested to be secure. There is no clear reason why the malware author used older deprecated APIs.

One of the last steps in the setup process is to change the default icon. This is done by updating the registry key 'DefaultIcon'. with the value of 'C:\\ProgramData\\icon.ico'.

Before finishing the setup the encryptor will delete all files in all recycle bins across each drive without a confirmation dialog box.

File and directory discovery

During the file system discovery the encryptor will create new threads using the common 'CreateThread' method and passing in a pointer to a function that will perform either the file and directory walking, service shutdown or encryption.

A signaling object is used to indicate between threads when the thread needs to perform work, such as encrypting a found file; this is done via the 'WaitForSingleObject' function call, passing a handle to a semaphore backed object. This inter thread communication mechanism is very common in malware that requires high frequency synchronization.

The first thread - TaskKiller

Attempts to setup a new bat file, and execute it via the 'WinExec' function. This will invoke the 'cmd' shell to run the bat file. The command for utilizing the local ping utility with an echo request size of 2 on the local loop back address (127.0.0.1) and the taskkill command to end a process.

The second thread - Service manager

Will attempt to get a handle to the service manager via the 'OpenSCManager' function and open the service manager database. The sample does not specify a machine name, as such it passes in a NULL parameter and obtains a handle to the local machines service manager. The sample will go on to manage a service from within its configuration block, by first calling the 'OpenService' and 'QueryServiceStatusEx' functions to check the status of the service and store that status information into a buffer. The buffer contains information such as the current state of the service. If the service is not in the 'SERVICE_STOP' or 'SERVICE_STOP_PENDING' state, the encryptor continues on to stop the service via the 'ControlService' function passing in a new state of 'SERVICE_CONTROL_STOP'.

The encryptor will sleep the thread up until the 'dwWaitHint' value which is part of the service status and is responsible for the estimated time required for a pending start, stop, pause, or continue operation, in milliseconds. If successful the thread will close the service handle, or keep trying up until 30 seconds.

A number of processes are targeted for shutdown, such as 'SQL servers, excel, powerpoint, outlook, one note, chrome, firefox, etc.

Once the first two threads are created the file and directory discovery thread will get a list of logical drive strings via the 'GetLogicalDriveStrings' and the 'GetDriveType' functions. This allows for the root path names which will be passed to the file walking function running in another thread.

The third thread - File Walker

The file walking thread is relatively straight forward. The encryptor will use the 'FindFirstFile' and 'FindNextFile' function call to obtain a handle to a file and iterate from the top of the logical disk to all files. The file handle contains file data such as the 'cFileName' and 'dwFileAttributes'. These are used to check for a potential file name of '.' and if the file is a directory or a regular file. For all files found to encrypt, they are added to a list which will be handled during the encryption process.

The encryptor will further make use of the 'WNetOpenEnum' and 'WNetEnumResource' to enumerate network shares, which can be used to discover files. This is a common API that other ransomware uses.

A blacklist, whitelist of files or folders, and extensions exists in the encryptors configuration. This will most likely be extended and customized for targets when big game hunting.

The fourth thread - Encryption

Just before encryption the Windows restart manager API is called to ensure the file to be encrypted is not locked by another process. This is done via the 'RmStartSession' and 'RmGetList' functions. Once obtained, the 'OpenProcess' and 'TerminateProcess' APIs are called. Data is encrypted with salsa20/chacha20.

Cleaning up

Just before the encryptor shuts down, it will first clear the event logs by first getting a handle via the 'OpenEventLog' and clearing the logs via the 'ClearEventLog' functions and target the ‘application’, ‘system’ and ‘security‘ logs. Lastly, cleaning up the local bat file 'C:\\ProgramData\\1.bat' and calling for an immediate restart of the system using the shutdown command and the '-r -f -t' switch.

Readme

The readme file is listed as ReadMe.<VictimID>.txt

YARA

rule DoNex_Ransomware {
    meta:
        description = "Rule to detect DoNex ransomware"
        author = "ShadowStackRe.com"
        date = "2024-03-12"
        Rule_Version = "v1"
        malware_type = "ransomware"
        malware_family = "DoNex"
        License = "MIT License, https://opensource.org/license/mit/"
        Hash = "0adde4246aaa9fb3964d1d6cf3c29b1b13074015b250eb8e5591339f92e1e3ca"
    strings:
        $strBat = "C:\\ProgramData\\1.bat"
        $strCheckMutex = "CheckMutex"
        $strEncThread = "encryption_thread"
        $strReadMe = "Readme.%ls.txt"
        $strWalkThread = "walk_thread"
        $strWhiteExt = "white_extens"
        $strWhiteFolders = "white_folders"
        $strLocalDisks = "local_disks"
        $strIcon = "C:\\ProgramData\\icon.ico"
        $strTaskKill = "cmd /c \"taskkill /f /im cmd.exe & taskkill /f /im conhost.exe\""
    condition:
        uint16(0) == 0x5A4D and
        all of them
}

Donex ransomware