{
	"id": "16ee2e3a-9fa4-46f5-baf6-536f88ff2c5a",
	"created_at": "2026-04-06T00:18:07.201965Z",
	"updated_at": "2026-04-10T13:12:30.429707Z",
	"deleted_at": null,
	"sha1_hash": "c1fd998ec740d1ec5e0b20a44305afe4fd715062",
	"title": "Slicing up DoNex with Binary Ninja - SANS Internet Storm Center",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 882592,
	"plain_text": "Slicing up DoNex with Binary Ninja - SANS Internet Storm Center\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 15:26:34 UTC\r\n[This is a guest diary by John Moutos]\r\nIntro\r\nEver since the LockBit source code leak back in mid-June 2022 [1], it is not surprising that newer ransomware\r\ngroups have chosen to adopt a large amount of the LockBit code base into their own, given the success and\r\nefficiency that LockBit is notorious for. One of the more clear-cut spinoffs from LockBit, is Darkrace, a\r\nransomware group that popped up mid-June 2023 [2], with samples that closely resembled binaries from the\r\nleaked LockBit builder, and followed a similar deployment routine. Unfortunately, Darkrace dropped off the radar\r\nafter the administrators behind the LockBit clone decided to shut down their leak site.\r\nIt is unsurprising that, 8 months after the appearance and subsequent disappearance of the Darkrace group, a new\r\ngroup who call themselves DoNex [3], have appeared in their place, utilizing samples that closely resemble those\r\npreviously used by the Darkrace group, and LockBit by proxy.\r\nAnalysis\r\nDropping the DoNex sample [4] in \"Detect It Easy\" (DIE) [5], we can see the binary does not appear to be packed,\r\nis 32-bit, and compiled with Microsoft's Visual C/C++ compiler.\r\nFigure 1: Binary Opened in DIE\r\nOpening the sample in Binary Ninja [6], and switching to the \"Triage Summary\" view, we can standard libraries\r\nbeing imported, and sections with nothing special going on.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 1 of 18\n\nFigure 2:  Binary Ninja Triage Summary\r\nSwitching back to the disassembly view, and going to the entry point, we can follow execution to the actual main\r\nfunction.\r\nFigure 3: Entry Point\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 2 of 18\n\nFigure 4: Call to Main Function\r\nOnce the application is launched, the main function starts by getting a handle to the attached console window with\r\n\"FindWindowA\", and setting the visibility to hidden by calling \"ShowWindow\" and passing \"SW_HIDE\" as a\r\nparameter.\r\nFigure 5: Main Function\r\nFollowing execution into the next function called (renamed to \"doInit\"), we can see a mutex check to ensure only\r\none instance of the application will run and encrypt files.\r\nFigure 6: Mutex Check\r\nThe next notable function called (renamed to \"checkPrivs\"), is an attempt to fetch the access token from the\r\ncurrent thread by using \"GetCurrentThread\" with \"OpenThreadToken\", and in cases where this operation fails,\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 3 of 18\n\n\"GetCurrentProcess\" is used with \"OpenProcessToken\" to obtain the access token from the application process,\r\ninstead of the current thread.\r\nFigure 7: Get Access Token\r\nUsing the access token handle, \"GetTokenInformation\" is called to identify the user account information tied to\r\nthe token, most notably the SID.\r\nFigure 8: Get Token Info\r\nThe user account info will be used to check for administrative rights, so a SID for the administrators group is\r\nallocated and initialized.\r\nFigure 9: Admin SID Create\r\nNow with the SID for the administrators group, \"EqualSid\" is called to compare the SID from derived from the\r\ntoken information against the newly initialized SID for the administrators group\r\nFigure 10: Admin Context Check\r\nReturning back to the main function, next \"GetModuleHandleA\" is used to open a handle to \"kernel32.dll\"\r\nmodule, and \"GetProcAddress\" is called using that handle to resolve the address of the \"IsWow64Process\"\r\nfunction.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 4 of 18\n\nFigure 11: Dynamic Address Resolution\r\nUsing the now resolved \"IsWow64Process\" function, the handle of the current process is passed and used to\r\ndetermine if \"Windows on Windows 64\" (WOW64 is essentially an x86 emulator) is being used to run the\r\napplication. WOW64 file system redirection is then disabled if the application is either running under 32-bit\r\nWindows, or if it is running under WOW64 on 64-bit Windows. Disabling redirection allows 32-bit applications\r\nrunning under WOW to access 64-bit versions of system files in the System32 directory, instead of being\r\nredirected to the 32-bit directory counterpart, SysWOW64.\r\nFigure 12: WOW FS Redirection Check\r\nFrom the main function we follow another call to the function (renamed to \"doCryptoSetup\") responsible for\r\nacquiring the cryptographic context needed for the application to actually encrypt device files by calling, as the\r\nname implies \"CryptAcquireContextA\".\r\nFigure 13: Acquire Crypot Context\r\nWith the cryptographic context setup, the following function (renamed to \"setIcon\") called, is used to drop an icon\r\nfile named \"icon.ico\" to \"C:\\ProgramData\\\", and create keys in the device registry through use of\r\n\"RegCreateKeyExA\", and \"RegSetValueExA\", to set it as the default file icon for newly encrypted files.\r\nFigure 14: Drop Icon File\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 5 of 18\n\nFigure 15: Associate Icon with Extension\r\nFigure 16: Set Default Icon in Registry\r\nThe final part of the initial setup process involves a call to \"SHEmptyRecycleBinA\", which as the name implies,\r\nempties the recycle bin, and since no drive was specified, it will affect all the device drives.\r\nFigure 17: Wiping Recycle Bins\r\nWith the main pre-encryption setup complete, the encryption setup function (renamed to \"mainEncryptSetup\")\r\nwhich handles thread management, process termination, service control, drive \u0026 network share enumeration, file\r\ndiscovery \u0026 iteration, and encryption is called.\r\nFigure 18: Encryption Setup Start\r\nAs part of the process termination and service control component, a connection to the service control manager on\r\nthe local device is established through a call to \"getServiceControl\".\r\nFigure 19: Service Control Connection\r\nThe first thread created during the encryption setup, is used to drop the process terminating batch file (\"1.bat\") [7]\r\nto the \"\\ProgramData\\\" directory. The second thread that is created, handles service manipulation, and executes if\r\na valid handle to the service control manager is present.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 6 of 18\n\nFigure 20: Thread Creation\r\nCalled by the creation of the first thread, this function (renamed to \"batRun\") drops a looping batch file (\"1.bat\"),\r\nand executes it with \"WinExec\", which pings the localhost address, and uses \"taskkill\" to kill processes of\r\ncommon AV \u0026 EDR products and backup software.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 7 of 18\n\nFigure 21: Process Kill Batch\r\nCalled by the creation of the second thread, this function (renamed to \"stopServices\"), creates a connection to the\r\nservice control manager through a call to \"OpenSCManagerA\", and has the capability to open handles to a service\r\nbased on a service name, using \"OpenServiceA\", identify the service status with \"QueryServiceStatusEx\", identify\r\nany dependent services with \"EnumDependentServicesA\", and make modifications to the service, such as\r\nstopping it, with \"ControlService\".\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 8 of 18\n\nFigure 22: Service Control Connection\r\nFigure 23: Dependent Service Check\r\nFigure 24: Control Service\r\nAfter the previous two threads have finished, a list of valid storage drives connected to the device is enumerated\r\nwith \"GetLogicalDriveStringsW\" and the drive type for each is queried using \"GetDriveTypeW\".\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 9 of 18\n\nFigure 25: Storage Enumeration\r\nThe third and fourth threads will call functions \"iterFiles\" and \"iterFilesCon\", which handle discovering and\r\niterating through the files on the previously queried drives. The fifth thread starts the actual file encryption process\r\nwith a call to \"startEncrypt\".\r\nFigure 26: Start Iterating Files\r\nTo start the process of iterating through files, the root path of the current targeted drive is identified using\r\n“getDriveRootPath”.\r\nFigure 27: Get Drive Root\r\nFiles are then iterated through using “FindFirstFileW” and “FindNextFileW”, and checked against a file blacklist\r\n(“checkFileBlacklist”) to avoid encrypting critical system files, before being stored in a list to be used in the\r\nencryption process.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 10 of 18\n\nFigure 28: Start File Iteration\r\nFigure 29: Compare Files to Blacklist\r\nFigure 30: Release Handle and Finish Iteration\r\nThe encryption process starts with the execution of the “encryptJob” function, by the creation of the fifth thread\r\nFigure 31: Start File Encryption Job\r\nTo ensure the encrypted data can be written to the target files, a Restart Manager session is created with\r\n“RmStartSession” and populated with the target files (resources) using “RmRegisterResources”, which are then\r\ncollected by “RmGetList” and used to check if the target files are locked by any other processes, and if a lock\r\nexists, a handle is opened to the process, and the process is terminated, using “OpenProcess” and\r\n“TerminateProcess”. The target files are then finally encrypted.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 11 of 18\n\nFigure 32: Check File Locks\r\nWith the main encryption job finished, the ransom note “ReadMe” is dropped.\r\nFigure 33: Dropping Ransom Note\r\nFigure 34: Note Name with ID Placeholder\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 12 of 18\n\nFigure 35: Note Written to Disk\r\nWith the main on-disk encryption job complete, available network shares are targeted next.\r\nFigure 36: Target Network Shares\r\nNetwork shares are enumerated through use of the Windows Networking API (“WNetOpenEnumW”), and\r\nconnections are made to shares that are accessible by the current acting user account (“WNetEnumResourceW”\r\nand “WNetAddConnection2W”)\r\nFigure 37: Start Network Share Enum Job\r\nFigure 38: Continue Enum Job\r\nFigure 39: Network Share Connection Attempt\r\nSimilar to the previous process, files on the network share(s) are then discovered and iterated through\r\n(“FindFirstFileW” and “FindNextFileW”), to be stored and used by the network share file encrypt job.\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 13 of 18\n\nFigure 40: Network Share File Iteration\r\nWith the network share files discovered and stored, the encryption job (“encryptJobNS”) for them is started.\r\nFigure 41: Encrypt Network Share Files\r\nLastly, to cleanup, the application, system, and security event logs are erased (“OpenEventLogA” and\r\n“ClearEventLogA”), and a command which pings the localhost address, before deleting the dropped “1.bat” file,\r\nand performing a hard restart on the device, is invoked with “WinExec”, before exiting.\r\nFigure 42: Clear Event Logs\r\nFigure 43: Cleanup Commands\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 14 of 18\n\nFigure 44: Execute Cleanup Commands\r\nAdditional data extracted during runtime, and similar LockBit/Darkrace files for comparison.\r\nFigure 45: DoNex Ransom Note\r\nFigure 46: \"1.bat\" [50] Contents\r\nFigure 47: Commands User to Delete Shadow Copies\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 15 of 18\n\nFigure 48: Darkrace Rasnom Note\r\nFigure 49: LockBit 3.0 Ransom Note\r\nFlow Summary\r\nUser or threat actor executes DoNex ransomware binary\r\nBinary starts and hides attached console window\r\nPerforms a mutex check to ensure only one instance of the binary is running\r\nObtains the access token from the current thread, or process\r\nQueries user account info associated with the token\r\nChecks if user account belongs to local administrators group\r\nDisables WOW file system redirection if running under 32-bit Windows, or WOW64 on 64-bit Windows\r\nDrops an icon file in \"\\ProgramData\"\r\nSets dropped icon as default file icon for encrypted files\r\nWipes recycle bins on all drives\r\nDrops \"1.bat\" batch file to \"\\ProgramData\" and executes it\r\nEnumerates connected drives\r\nIdentifies root path on each drive\r\nIterates through files on drives\r\nChecks files against blacklist\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 16 of 18\n\nChecks if target files are locked and if true, kill locking process(es)\r\nEncrypts files on disk\r\nDrops ransom note \"ReadMe.txt\"\r\nEnumerates accessible network shares\r\nAttempts to connect to any open shares\r\nIterates through files on shares\r\nEncrypts files on network shares\r\nClears application, security, and system event logs\r\nDeletes \"1.bat\" file\r\nForces a hard restart on the device\r\nTakeaway\r\nUnsurprisingly, the threat actors behind the DoNex group are far from innovators in the ransomware landscape,\r\nwith nothing new brought to the table, outside of renaming some strings within the LockBit builder. DoNex, and\r\nthe Darkrace ransomware gang are merely trying to shortcut their way to successful compromises, using the\r\nscraps left behind by LockBit and the leaked builder. The appearance of these smaller and newer groups will only\r\nbecome more common, as the skill ceiling for successful compromise is pushed down lower, partially due to the\r\naffiliate programs larger ransomware families have in place, and the beginner friendly builders, that are directly\r\nprovided, or in the case of LockBit, leaked.\r\nReferences, Appendix, \u0026 Tools Used\r\n[1] https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a\r\n[2] https://cyble.com/blog/unmasking-the-darkrace-ransomware-gang\r\n[3] https://www.watchguard.com/wgrd-security-hub/ransomware-tracker/donex\r\n[4]\r\nhttps://www.virustotal.com/gui/file/6d6134adfdf16c8ed9513aba40845b15bd314e085ef1d6bd20040afd42e36e40\r\n[5] https://github.com/horsicq/DIE-engine/releases\r\n[6] https://binary.ninja\r\n[7]\r\nhttps://www.virustotal.com/gui/file/2b15e09b98bc2835a4430c4560d3f5b25011141c9efa4331f66e9a707e2a23c0\r\nIndicators of Compromise\r\nSHA-256 Hashes:\r\n6d6134adfdf16c8ed9513aba40845b15bd314e085ef1d6bd20040afd42e36e40 (doneX.exe)\r\n2b15e09b98bc2835a4430c4560d3f5b25011141c9efa4331f66e9a707e2a23c0 (1.bat)\r\nd3997576cb911671279f9723b1c9505a572e1c931d39fe6e579b47ed58582731 (icon.ico)\r\nNotable File Activity:\r\nC:\\Users\\user\\Desktop\\ReadMe.f58A66B51.txt\r\nC:\\Users\\user\\Downloads\\ReadMe.f58A66B51.txt\r\nC:\\Users\\user\\Documents\\ReadMe.f58A66B51.txt\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 17 of 18\n\nC:\\ReadMe.f58A66B51.txt\r\nC:\\Temp\\ReadMe.f58A66B51.txt\r\nNotable Registry Activity:\r\nHKEY_CLASSES_ROOT\\.f58A66B51\r\nHKEY_CLASSES_ROOT\\f58A66B51file\\DefaultIcon\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\f58A66B51file\\DefaultIcon\r\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Classes\\.f58A66B51\r\nJohn Moutos\r\nSource: https://isc.sans.edu/diary/rss/30812\r\nhttps://isc.sans.edu/diary/rss/30812\r\nPage 18 of 18",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://isc.sans.edu/diary/rss/30812"
	],
	"report_names": [
		"30812"
	],
	"threat_actors": [],
	"ts_created_at": 1775434687,
	"ts_updated_at": 1775826750,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c1fd998ec740d1ec5e0b20a44305afe4fd715062.pdf",
		"text": "https://archive.orkl.eu/c1fd998ec740d1ec5e0b20a44305afe4fd715062.txt",
		"img": "https://archive.orkl.eu/c1fd998ec740d1ec5e0b20a44305afe4fd715062.jpg"
	}
}