Slicing up DoNex with Binary Ninja

Published: 2024-04-04. Last Updated: 2024-04-04 17:53:02 UTC
by John Moutos (Version: 1)
0 comment(s)

[This is a guest diary by John Moutos]

Intro

Ever since the LockBit source code leak back in mid-June 2022 [1], it is not surprising that newer ransomware groups have chosen to adopt a large amount of the LockBit code base into their own, given the success and efficiency that LockBit is notorious for. One of the more clear-cut spinoffs from LockBit, is Darkrace, a ransomware group that popped up mid-June 2023 [2], with samples that closely resembled binaries from the leaked LockBit builder, and followed a similar deployment routine. Unfortunately, Darkrace dropped off the radar after the administrators behind the LockBit clone decided to shut down their leak site.

It is unsurprising that, 8 months after the appearance and subsequent disappearance of the Darkrace group, a new group who call themselves DoNex [3], have appeared in their place, utilizing samples that closely resemble those previously used by the Darkrace group, and LockBit by proxy.

Analysis

Dropping the DoNex sample [4] in "Detect It Easy" (DIE) [5], we can see the binary does not appear to be packed, is 32-bit, and compiled with Microsoft's Visual C/C++ compiler.

Figure 1: Binary Opened in DIE

Opening the sample in Binary Ninja [6], and switching to the "Triage Summary" view, we can standard libraries being imported, and sections with nothing special going on.

Figure 2:  Binary Ninja Triage Summary

Switching back to the disassembly view, and going to the entry point, we can follow execution to the actual main function.

 

Figure 3: Entry Point

 

 

Figure 4: Call to Main Function

 

Once the application is launched, the main function starts by getting a handle to the attached console window with "FindWindowA", and setting the visibility to hidden by calling "ShowWindow" and passing "SW_HIDE" as a parameter.

Figure 5: Main Function

Following execution into the next function called (renamed to "doInit"), we can see a mutex check to ensure only one instance of the application will run and encrypt files.

Figure 6: Mutex Check

The next notable function called (renamed to "checkPrivs"), is an attempt to fetch the access token from the current thread by using "GetCurrentThread" with "OpenThreadToken", and in cases where this operation fails, "GetCurrentProcess" is used with "OpenProcessToken" to obtain the access token from the application process, instead of the current thread.

Figure 7: Get Access Token

Using the access token handle, "GetTokenInformation" is called to identify the user account information tied to the token, most notably the SID.

Figure 8: Get Token Info

The user account info will be used to check for administrative rights, so a SID for the administrators group is allocated and initialized.

Figure 9: Admin SID Create

Now with the SID for the administrators group, "EqualSid" is called to compare the SID from derived from the token information against the newly initialized SID for the administrators group

Figure 10: Admin Context Check

Returning back to the main function, next "GetModuleHandleA" is used to open a handle to "kernel32.dll" module, and "GetProcAddress" is called using that handle to resolve the address of the "IsWow64Process" function.

Figure 11: Dynamic Address Resolution

Using the now resolved "IsWow64Process" function, the handle of the current process is passed and used to determine if "Windows on Windows 64" (WOW64 is essentially an x86 emulator) is being used to run the application. WOW64 file system redirection is then disabled if the application is either running under 32-bit Windows, or if it is running under WOW64 on 64-bit Windows. Disabling redirection allows 32-bit applications running under WOW to access 64-bit versions of system files in the System32 directory, instead of being redirected to the 32-bit directory counterpart, SysWOW64.

Figure 12: WOW FS Redirection Check

From the main function we follow another call to the function (renamed to "doCryptoSetup") responsible for acquiring the cryptographic context needed for the application to actually encrypt device files by calling, as the name implies "CryptAcquireContextA".

Figure 13: Acquire Crypot Context

With the cryptographic context setup, the following function (renamed to "setIcon") called, is used to drop an icon file named "icon.ico" to "C:\ProgramData\", and create keys in the device registry through use of "RegCreateKeyExA", and "RegSetValueExA", to set it as the default file icon for newly encrypted files.

 

Figure 14: Drop Icon File

 

 

Figure 15: Associate Icon with Extension

 

 

Figure 16: Set Default Icon in Registry

 

The final part of the initial setup process involves a call to "SHEmptyRecycleBinA", which as the name implies, empties the recycle bin, and since no drive was specified, it will affect all the device drives.

 

Figure 17: Wiping Recycle Bins

 

With the main pre-encryption setup complete, the encryption setup function (renamed to "mainEncryptSetup") which handles thread management, process termination, service control, drive & network share enumeration, file discovery & iteration, and encryption is called.

 

Figure 18: Encryption Setup Start

 

As part of the process termination and service control component, a connection to the service control manager on the local device is established through a call to "getServiceControl".

 

Figure 19: Service Control Connection

 

The first thread created during the encryption setup, is used to drop the process terminating batch file ("1.bat") [7] to the "\ProgramData\" directory. The second thread that is created, handles service manipulation, and executes if a valid handle to the service control manager is present.

 

Figure 20: Thread Creation

 

Called by the creation of the first thread, this function (renamed to "batRun") drops a looping batch file ("1.bat"), and executes it with "WinExec", which pings the localhost address, and uses "taskkill" to kill processes of common AV & EDR products and backup software.

 

Figure 21: Process Kill Batch

 

Called by the creation of the second thread, this function (renamed to "stopServices"), creates a connection to the service control manager through a call to "OpenSCManagerA", and has the capability to open handles to a service based on a service name, using "OpenServiceA", identify the service status with "QueryServiceStatusEx", identify any dependent services with "EnumDependentServicesA", and make modifications to the service, such as stopping it, with "ControlService".

 

 

Figure 22: Service Control Connection

 

 

Figure 23: Dependent Service Check

 

 

Figure 24: Control Service

After the previous two threads have finished, a list of valid storage drives connected to the device is enumerated with "GetLogicalDriveStringsW" and the drive type for each is queried using "GetDriveTypeW".

 

Figure 25: Storage Enumeration

 

The third and fourth threads will call functions "iterFiles" and "iterFilesCon", which handle discovering and iterating through the files on the previously queried drives. The fifth thread starts the actual file encryption process with a call to "startEncrypt".

 

Figure 26: Start Iterating Files

 

To start the process of iterating through files, the root path of the current targeted drive is identified using “getDriveRootPath”.

 

Figure 27: Get Drive Root

 

Files are then iterated through using “FindFirstFileW” and “FindNextFileW”, and checked against a file blacklist (“checkFileBlacklist”) to avoid encrypting critical system files, before being stored in a list to be used in the encryption process.

 

Figure 28: Start File Iteration

 

 

Figure 29: Compare Files to Blacklist

 

 

Figure 30: Release Handle and Finish Iteration

 

The encryption process starts with the execution of the “encryptJob” function, by the creation of the fifth thread

 

Figure 31: Start File Encryption Job

 

To ensure the encrypted data can be written to the target files, a Restart Manager session is created with “RmStartSession” and populated with the target files (resources) using “RmRegisterResources”, which are then collected by “RmGetList” and used to check if the target files are locked by any other processes, and if a lock exists, a handle is opened to the process, and the process is terminated, using “OpenProcess” and “TerminateProcess”. The target files are then finally encrypted.

 

Figure 32: Check File Locks

 

With the main encryption job finished, the ransom note “ReadMe” is dropped.

 

Figure 33: Dropping Ransom Note

 

 

Figure 34: Note Name with ID Placeholder

 

 

Figure 35: Note Written to Disk

 

With the main on-disk encryption job complete, available network shares are targeted next.

 

Figure 36: Target Network Shares

 

Network shares are enumerated through use of the Windows Networking API (“WNetOpenEnumW”), and connections are made to shares that are accessible by the current acting user account (“WNetEnumResourceW” and “WNetAddConnection2W”)

 

Figure 37: Start Network Share Enum Job

 

 

Figure 38: Continue Enum Job

 

 

Figure 39: Network Share Connection Attempt

 

Similar to the previous process, files on the network share(s) are then discovered and iterated through (“FindFirstFileW” and “FindNextFileW”), to be stored and used by the network share file encrypt job.

 

Figure 40: Network Share File Iteration

 

With the network share files discovered and stored, the encryption job (“encryptJobNS”) for them is started.

 

Figure 41: Encrypt Network Share Files

 

Lastly, to cleanup, the application, system, and security event logs are erased (“OpenEventLogA” and “ClearEventLogA”), and a command which pings the localhost address, before deleting the dropped “1.bat” file, and performing a hard restart on the device, is invoked with “WinExec”, before exiting.

 

Figure 42: Clear Event Logs

 

 

Figure 43: Cleanup Commands

 

 

Figure 44: Execute Cleanup Commands

 

Additional data extracted during runtime, and similar LockBit/Darkrace files for comparison.

 

Figure 45: DoNex Ransom Note

 

 

Figure 46: "1.bat" [50] Contents

 

 

Figure 47: Commands User to Delete Shadow Copies

 

 

Figure 48: Darkrace Rasnom Note
Figure 49: LockBit 3.0 Ransom Note

 

Flow Summary

  • User or threat actor executes DoNex ransomware binary
  • Binary starts and hides attached console window
  • Performs a mutex check to ensure only one instance of the binary is running
  • Obtains the access token from the current thread, or process
  • Queries user account info associated with the token
  • Checks if user account belongs to local administrators group
  • Disables WOW file system redirection if running under 32-bit Windows, or WOW64 on 64-bit Windows
  • Drops an icon file in "\ProgramData"
  • Sets dropped icon as default file icon for encrypted files
  • Wipes recycle bins on all drives
  • Drops "1.bat" batch file to "\ProgramData" and executes it
  • Enumerates connected drives
  • Identifies root path on each drive
  • Iterates through files on drives
  • Checks files against blacklist
  • Checks if target files are locked and if true, kill locking process(es)
  • Encrypts files on disk
  • Drops ransom note "ReadMe.txt"
  • Enumerates accessible network shares
  • Attempts to connect to any open shares
  • Iterates through files on shares
  • Encrypts files on network shares
  • Clears application, security, and system event logs
  • Deletes "1.bat" file
  • Forces a hard restart on the device

Takeaway

Unsurprisingly, the threat actors behind the DoNex group are far from innovators in the ransomware landscape, with nothing new brought to the table, outside of renaming some strings within the LockBit builder. DoNex, and the Darkrace ransomware gang are merely trying to shortcut their way to successful compromises, using the scraps left behind by LockBit and the leaked builder. The appearance of these smaller and newer groups will only become more common, as the skill ceiling for successful compromise is pushed down lower, partially due to the affiliate programs larger ransomware families have in place, and the beginner friendly builders, that are directly provided, or in the case of LockBit, leaked.

References, Appendix, & Tools Used

[1] https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a
[2] https://cyble.com/blog/unmasking-the-darkrace-ransomware-gang
[3] https://www.watchguard.com/wgrd-security-hub/ransomware-tracker/donex
[4] https://www.virustotal.com/gui/file/6d6134adfdf16c8ed9513aba40845b15bd314e085ef1d6bd20040afd42e36e40
[5] https://github.com/horsicq/DIE-engine/releases
[6] https://binary.ninja
[7] https://www.virustotal.com/gui/file/2b15e09b98bc2835a4430c4560d3f5b25011141c9efa4331f66e9a707e2a23c0

Indicators of Compromise

SHA-256 Hashes:
6d6134adfdf16c8ed9513aba40845b15bd314e085ef1d6bd20040afd42e36e40 (doneX.exe)
2b15e09b98bc2835a4430c4560d3f5b25011141c9efa4331f66e9a707e2a23c0 (1.bat)
d3997576cb911671279f9723b1c9505a572e1c931d39fe6e579b47ed58582731 (icon.ico)

Notable File Activity:
C:\Users\user\Desktop\ReadMe.f58A66B51.txt
C:\Users\user\Downloads\ReadMe.f58A66B51.txt
C:\Users\user\Documents\ReadMe.f58A66B51.txt
C:\ReadMe.f58A66B51.txt
C:\Temp\ReadMe.f58A66B51.txt

Notable Registry Activity:
HKEY_CLASSES_ROOT\.f58A66B51
HKEY_CLASSES_ROOT\f58A66B51file\DefaultIcon
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\f58A66B51file\DefaultIcon
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.f58A66B51

John Moutos

Keywords:
0 comment(s)
ISC Stormcast For Thursday, April 4th, 2024 https://isc.sans.edu/podcastdetail/8924

Comments


Diary Archives