{
	"id": "d6e135bb-bc64-467d-85a2-5ff5a14fecbd",
	"created_at": "2026-04-06T00:21:50.977195Z",
	"updated_at": "2026-04-10T03:21:24.294874Z",
	"deleted_at": null,
	"sha1_hash": "8b61694cd7bbad58ac89de5c680ec8663c3fce74",
	"title": "Taking a deep dive into Sodinokibi ransomware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 89582,
	"plain_text": "Taking a deep dive into Sodinokibi ransomware\r\nBy Acronis\r\nArchived: 2026-04-05 18:58:32 UTC\r\nWhile Sodinokibi ransomware has been in the news recently, technical details for that particular strain have been\r\nfar less visible. In this article, we’ll dissect Sodinokibi, shine a light on how it works, and review how you can\r\nprotect your system from this threat.\r\nResearched and written by Ravikant Tiwari and Alexander Koshelev\r\nExecutive Summary\r\nSodinokibi is likely being distributed by attackers affiliated with those that distributed the infamous\r\nGandCrab ransomware family, which is supposed to be retired soon according to the underground forum\r\nwhere GandCrab first appeared.\r\nSodinokibi ransomware exploits an Oracle WebLogic vulnerability (CVE-2019-2725) to gain access to the\r\nvictim’s machine. Once it’s in, the malware tries to execute itself with elevated user rights in order to\r\naccess all files and resources on the system without any restriction.\r\nSodinokibi tries to avoid infecting computers from Iran, Russia, and other countries that were formerly part\r\nof the USSR.\r\nThis ransomware strain uses AES and Salsa20 algorithms to encrypt user’s files, AES is used to encrypt\r\nsession keys and data that is sent to the control server, user files are encrypted using Salsa20 encryption.\r\nSodinokibi uses an Elliptic-curve Diffie-Hellman key exchange algorithm to generate and propagate\r\nencryption keys.\r\nOnce it infiltrates a machine, it wipes out all of the files in the backup folder.\r\nCurrently, the ransomware demands 0.32806964 BTC (≈ $2,500) to regain access to the encrypted files.\r\nThey claim that this amount should be paid within four days or the ransom demand will be doubled.\r\nSodinokibi ransomware\r\nHow it works\r\nThe Sodinokibi ransomware sample we analyzed was packed using a custom packer. Even after successful\r\nunpacking, the main Sodinokibi code does not seem to have much of a readable string. Neither does it have any\r\nimports for system libraries and APIs, which means a static AV scanner that depends on a readable string and\r\nimported API table will have a hard time detecting it.\r\nAPI names and other required strings are decrypted during its runtime using the RC4 algorithm. To make the\r\nsituation even more challenging for anti-virus software, most of the operations on strings are performed using a\r\nDJB hash of the string rather than the string itself.\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 1 of 10\n\nInitialization\r\nSodinokibi starts by building a dynamic import table and ensuring that this is the only instance running currently\r\non the system with the help of mutexes. Once the mutex check is passed, it decrypts the JSON config stored\r\nwithin the binary using RC4 and checks for the Boolean key value “exp”. If it is set to “true” Sodinokibi tries to\r\nrun an exploit. In our case, the value of “exp” key is set to true so it proceeds to run the exploitation function.\r\nSodinokibi - Decrypted JSON Configuration\r\nDecrypted JSON Configuration\r\nFigure 1: Decrypted JSON Configuration\r\nThe code responsible for running the exploit first checks if the September 11, 2018 patch (KB4457138) is applied\r\non the machine. This patch addresses multiple vulnerabilities mentioned below. If the patch is not detected, the\r\nransomware proceeds to execute a 32- or 64-bit version of the shellcode depending on the platform architecture.\r\nWe believe it tries to elevate its privilege by exploiting CVE-2018-8440.\r\nFigure 2: Snippet 1\r\nVulnerabilities addressed by patch KB4457138 are listed in the table below:\r\nIf the system is not vulnerable and the process is still running as a limited user, it will use a RUNAS command to\r\nlaunch another instance with administrative rights and terminate the current instance if it is running with limited\r\nprivileges. The complete flow can be seen in the code below.\r\nSodinokibi ransomware\r\nFigure 3\r\nAfter Sodinokibi successfully starts in Admin mode, it does an extra pre-check based on “bro” key in the JSON\r\nconfiguration and country. It will try not to infect computers from the following countries based on the locale\r\nsetting of the computer.\r\nFigure 4: Matching language IDs\r\nFigure 4: Matching language IDs\r\nExempted Countries list\r\nRomania\r\nRussia\r\nUkraine\r\nBelarus\r\nEstonia\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 2 of 10\n\nLatvia\r\nLithuanian\r\nTajikistan\r\nIran\r\nArmenia\r\nAzerbaijan\r\nGeorgia\r\nKazakhstan\r\nKyrgyzstan\r\nTurkmenistan\r\nUzbekistan\r\nTatarstan\r\nAfter passing the pre-check it terminates the mysql.exe process (if it’s running) so that it can gain access to\r\nMySQL files for encryption, then deletes all Windows SHADOW COPIES (Windows built-in backup mechanism)\r\nusing vssadmin, and disables Windows recovery using bcdedit (boot policy editor) as shown below:\r\nvssadmin.exe Delete Shadows /All /Quiet \u0026 bcedit /set {default} recoveryenabled No \u0026 bcedit /set {default}\r\nbootstatuspolice ignorealfailures\r\nFigure 5\r\nBefore encrypting user files, Sodinokibi searches the entire file system and network shares for all directories\r\nnamed “backup” and wipes it out. Interestingly, before wiping all the files inside this directory it overwrites the\r\ncontent with random bytes to make file recovery impossible. Fortunately, Acronis Backup files can’t be deleted\r\neasily, as they are protected using kernel mode drivers to thwart such illicit deletion by ransomware.\r\nKey Generation\r\nSodinokibi uses an Elliptic-curve Diffie–Hellman (ECDH) key generation and exchange algorithm to generate a\r\nprivate-public key pair. It uses this to generate a shared secret, which will be used as the key for symmetric\r\nencryption algorithms AES and Salsa20 which are used to encrypt different kinds of data.\r\nAES encryption is used to encrypt the private keys of the private-public key pair, which is generated\r\nlocally on the user’s machine as well as the data sent over the network.\r\nSalsa20, on the other hand, is used for encrypting user files.\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 3 of 10\n\nSodinokibi is shipped with two different public keys, one as part of JSON configuration and another embedded in\r\nthe binary itself. These public keys will be used to encrypt the locally-generated private key. Below we detail the\r\nsteps included in the key generation and encryption process.\r\nStep 1.Generate a session private (secret, random number) and public key pair on the local machine.\r\nGenerating local public and private keys\r\nFigure 6: Generating local public and private keys\r\nEncrypting the private key from Step 1 using the public key present in JSON configuration\r\nStep 2. Generate another private and public key pair.\r\nStep 3. Use the private key from Step 2 and the public key (pk key value) from JSON to generate a shared key and\r\nhash it to generate a symmetric key.\r\nGenerating a symmetric key using a shared key\r\nFigure 7: Generating a symmetric key using a shared key\r\nStep 4. Generate a 16-byte IV (initialization vector).\r\nStep 5. Encrypt the private key generated in Step 1 using AES encryption with the Key and IV generated in Steps\r\n3 and 4.\r\nStep 6. Calculate CRC32 of the encrypted private key generated in Step 5.\r\nStep 7. Append IV and CRC32 at the end of the buffer containing the encrypted private key from Step 5.\r\nStep 8. Save this buffer to a mapped file offset marked as “sk_key” in memory.\r\nFigure 8: Encrypting the private key from step one using the attacker's public keys\r\nFigure 8: Encrypting the private key from step one using the attacker's public keys\r\nEncrypting the private key from Step 1, using public key present embedded in the binary\r\nStep 9. Repeat Steps 2 through 7 by using a different public key that comes embedded in the binary for Step 3.\r\nStep 10. Save this buffer to a mapped file offset marked as “0_key” in the memory\r\nThe sk_key, 0_key, and pk_key are written to the following registry key respectively depending on access rights.\r\nHKLM\\SOFTWARE\\recfg\\sk_key   OR    HKCU\\SOFTWARE\\recfg\\sk_key\r\nHKLM\\SOFTWARE\\recfg\\0_key   OR   HKCU\\SOFTWARE\\recfg\\0_key\r\nHKLM\\SOFTWARE\\recfg\\pk_key   OR   HKCU\\SOFTWARE\\recfg\\pk_key\r\nEncrypted secret key in registry\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 4 of 10\n\nFigure 9: Encrypted secret key in registry\r\nGenerating per file keys for Salsa20\r\nStep 11. Generate a new private and public key pair.\r\nStep 12. Generate a shared key using the session public key generated in Step 2 and hash it to get another\r\nsymmetric key for using in Salsa20 key generation.\r\nStep 13. Set up a 256-bit (32 bytes) Salsa20 key state\r\nStep 14. Generate an 8-bit IV for Salsa20 key\r\nStep 15. Generate a Salsa20 key\r\nStep 16. Use this Salsa20 key_state for encrypting user files using Salsa20 encryption.\r\nGeneration of per file Salsa20 key\r\nFigure 10: Generation of per file Salsa20 key\r\nRepeat Steps 11 to 16 for each file that is to be encrypted.\r\nEncryption and decryption illustration\r\nTo understand how the keys are generated and transferred between attacker and the victim’s machine we need to\r\ntake a look at how Diffie Hellman works with the help of the image below.\r\nFigure 11: Elliptic-Curve Diffie-Hellman (ECDH) Key Exchange\r\nSodinokibi encryption process in detail\r\nFigure 12: Encryption Process\r\nSodinokibi decryption process in detail\r\nThe process of decryption will require the knowledge of Attacker’s private key which is not publicly disclosed and\r\nthus it’s not possible to restore the files back.\r\nFigure 13: Decryption Process (Attacker’s seceret is Attacker’s Private key)\r\nThe simplified version of how the decryption process of the user files will look like the graph below.\r\nFigure 14\r\nFile Encryption on Local Hard Drives and Network Share\r\nTo encrypt user files Sodinokibi uses I/O Completion Ports and creates multiple encryption threads to a maximum\r\nof twice the number of processor cores present on the machine and associate these threads to the created I/O\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 5 of 10\n\ncompletion port. These threads use GetQueuedCompletionStatus Win API function to wait for a completion\r\npacket to be queued to the I/O completion port before they proceed to the file encryption.\r\nOnce the threads are created and waiting for I/O packets to arrive, Sodinokibi starts enumerating user files on all\r\nthe local drives and network shares except CDROM and RAMDISK drives and begins associating files which are\r\nnot in the exempted folder, file or file extension list to this I/O completion port by calling\r\nAddFileToIoCompletionPort user function and calls PostQueuedCompletionStatus Win API to post an I/O packet\r\non the I/O completion ports which will trigger the thread waiting on this I/O completion port to resume and\r\nproceed to encrypt files. AddFileToIoCompletionPort also generates a unique Salsa20 key for each file that is to\r\nbe encrypted and pass this Salsa20 key to the encrypting thread as part of structure containing other metadata that\r\nhas to be written to file as well after encryption using lpOverlapped parameter of PostQueuedCompletionStatus\r\nWin API. During enumeration it also create a ransom note file in all folders that are not in the exempted folder list.\r\nOnce there are no more files to enumerate the main thread waits in a loop until total number of files encrypted and\r\nrenamed equals to the total number of files added to the I/O completion port for encryption.\r\nFinally, it sets a flag which indicates there are no more files to enumerate and posts multiple I/O completion\r\npackets, by doing this it makes sure that extra threads waiting for files should resume and break the execution\r\nflow to finish immediately.\r\nFigure 15\r\nExempted Folders\r\n\"$windows.~bt\"\r\n\"intel\"\r\n\"program files (x86)\"\r\n\"program files\"\r\n\"msocache\"\r\n\"$recycle.bin\"\r\n\"$windows.~ws\"\r\n\"tor browser\"\r\n\"boot\"\r\n\"system volume information\"\r\n\"perflogs\"\r\n\"google\"\r\n\"application data\"\r\n\"windows\"\r\n\"programdata\"\r\n\"windows.old\"\r\n\"appdata\"\r\n\"mozilla\"\r\nExempted Files\r\n\"bootfont.bin\"\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 6 of 10\n\n\"boot.ini\"\r\n\"ntuser.dat\"\r\n\"desktop.ini\"\r\n\"iconcache.db\"\r\n\"ntldr\"\r\n\"ntuser.dat.log\"\r\n\"thumbs.db\"\r\n\"bootsect.bak\"\r\n\"ntuser.ini\"\r\n\"autorun.inf\"\r\nExempted File extensions\r\n\"themepack\"\r\n\"ldf\"\r\n\"scr\"\r\n\"icl\"\r\n\"386\"\r\n\"cmd\"\r\n\"ani\"\r\n\"adv\"\r\n\"theme\"\r\n\"msi\"\r\n\"rtp\"\r\n\"diagcfg\"\r\n\"msstyles\"\r\n\"bin\"\r\n\"hlp\"\r\n\"shs\"\r\n\"drv\"\r\n\"wpx\"\r\n\"deskthemepack\"\r\n\"bat\"\r\n\"rom\"\r\n\"msc\"\r\n\"lnk\"\r\n\"cab\"\r\n\"spl\"\r\n\"ps1\"\r\n\"msu\"\r\n\"ics\"\r\n\"key\"\r\n\"msp\"\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 7 of 10\n\n\"com\"\r\n\"sys\"\r\n\"diagpkg\"\r\n\"nls\"\r\n\"diagcab\"\r\n\"ico\"\r\n\"lock\"\r\n\"ocx\"\r\n\"mpa\"\r\n\"cur\"\r\n\"cpl\"\r\n\"mod\"\r\n\"hta\"\r\n\"exe\"\r\n\"icns\"\r\n\"prf\"\r\n\"dll\"\r\n\"nomedia\"\r\n\"idx\"\r\nThe encrypting thread takes care of reading the file contents, encrypting it, writing it back to the same file, writing\r\nmetadata that contains encrypted session Private key the per file ECDH Public key and per file Salsa20 IV used\r\nfor encrypting the files and then renaming it by appending with a randomly generated extension name. File are\r\nencrypted using Salsa20 (Chacha variant) encryption algorithm inside EncryptAndWrite user function.\r\nThe snippet below shows the code for EncryptingThreadRoutine user function.\r\nFigure 16\r\nFile Structure after Encryption\r\nFigure 17: Structure of encrypted file\r\nNetwork Activity\r\nAfter the encryption process is complete, the ransomware prepares the data to send to the control server. This data\r\ncontains different fields from the JSON configuration, system information, and encryption keys. Prepared data is\r\nalso saved to the registry key “[HKLM|HKCU]\\SOFTWARE\\recfg\\stat” before encrypting it with AES and\r\nsending it to the attacker’s server.\r\nFigure 18: Data sent over network\r\nFigure 18: Data sent over network\r\npid\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 8 of 10\n\nValue of ‘pid’ key from JSON configuration file.\r\nsub\r\nValue of ‘sub’ key in JSON configuration file.\r\nuid\r\ncrc32(Volume serial number) + crc32(Processor Model)\r\ngrp\r\nNetwork domain name of the system\r\nlng\r\nLanguage of the system\r\nbro\r\nTrue or false based on exempted country\r\nbit\r\nPlatform architecture (32|64 bit)\r\nThe information is sent to randomly generated URL which is in the form\r\nwhere:\r\nDomain name\r\nsochi-okna23[.]ru\r\nPath part 1\r\n\"wp-content\" \"static\" \"content\" \"include\" \"uploads\" \"news\" \"data\" \"admin\"\r\nPath part 2\r\n\"images\" \"pictures\" \"image\" \"temp\" \"tmp\" \"graphic\" \"assets\" \"pics\" \"game\"\r\nGenerating URL\r\nFigure 19: Generating URL\r\nRansom Note\r\nSodinokibi contains a template of its ransom note with placeholders for user-specific details. These placeholders\r\nare dynamically substituted with user-specific extension name, user id (uid – see the table above for description),\r\nand key. The ransom note is placed in each directory excluding the whitelisted one.\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 9 of 10\n\nFigure 20\r\nDecryption\r\nThere is no free decrypter available for this ransomware and the only choice is to use the decryption service\r\nprovided by the attackers, which can be accessed by following the instructions in the ransom note.\r\nThe decryption is below\r\nFigure 21\r\nConclusion\r\nTo protect against ransomware we recommend using an advanced anti-ransomware solution and maintain an\r\nupdated anti-virus solution. All Acronis product are equipped with advanced anti-ransomware technology and can\r\nprotect you against any such attack and minimize the risk of data loss.\r\nCyber protecton products like the personal solution Acronis True Image 2020 or business solution Acronis Backup\r\ncome with the AI-based anti-malware defense Acronis Active Protection built in, and are therefore able to protect\r\nusers against Sodinokibi ransomware.\r\nFigure 22: Acronis Active Protection detects Sodinokibi\r\nSource: https://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nhttps://www.acronis.com/en-sg/articles/sodinokibi-ransomware/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.acronis.com/en-sg/articles/sodinokibi-ransomware/"
	],
	"report_names": [
		"sodinokibi-ransomware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434910,
	"ts_updated_at": 1775791284,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8b61694cd7bbad58ac89de5c680ec8663c3fce74.pdf",
		"text": "https://archive.orkl.eu/8b61694cd7bbad58ac89de5c680ec8663c3fce74.txt",
		"img": "https://archive.orkl.eu/8b61694cd7bbad58ac89de5c680ec8663c3fce74.jpg"
	}
}