{
	"id": "8e70dc7c-7edd-49a8-9684-8d57763bc2cf",
	"created_at": "2026-04-06T00:16:32.152902Z",
	"updated_at": "2026-04-10T03:21:04.073465Z",
	"deleted_at": null,
	"sha1_hash": "ba4d65aacecd37e6d7952cdc6ea58e830c6cd3f7",
	"title": "Sodin ransomware exploits Windows vulnerability and processor architecture",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1053227,
	"plain_text": "Sodin ransomware exploits Windows vulnerability and processor\r\narchitecture\r\nBy Orkhan Mamedov\r\nPublished: 2019-07-03 · Archived: 2026-04-05 18:30:45 UTC\r\nWhen Sodin (also known as Sodinokibi and REvil) appeared in the first half of 2019, it immediately caught our\r\nattention for distributing itself through an Oracle Weblogic vulnerability and carrying out attacks on MSP\r\nproviders. In a detailed analysis, we discovered that it also exploits the CVE-2018-8453 vulnerability to elevate\r\nprivileges in Windows (rare among ransomware), and uses legitimate processor functions to circumvent security\r\nsolutions.\r\nAccording to our statistics, most victims were located in the Asia-Pacific region: Taiwan, Hong Kong, and South\r\nKorea.\r\nGeographic spread of Sodin ransomware, April – June 2019\r\nTechnical description\r\nVulnerability exploitation\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 1 of 12\n\nTo escalate privileges, Trojan-Ransom.Win32.Sodin uses a vulnerability in win32k.sys; attempts to exploit it were\r\nfirst detected by our proactive technologies (Automatic Exploit Prevention, AEP) in August last year. The\r\nvulnerability was assigned the number CVE-2018-8453. After the exploit is executed, the Trojan acquires the\r\nhighest level of privileges.\r\nInformation about the process token after exploit execution\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 2 of 12\n\nExploit snippet for checking the window class\r\nDepending on the processor architecture, one of two shellcode options contained in the Trojan body is run:\r\nProcedure for selecting the appropriate shellcode option\r\nSince the binary being analyzed is a 32-bit executable file, we are interested in how it manages to execute 64-bit\r\ncode in its address space. The screenshot shows a shellcode snippet for executing 64-bit processor instructions:\r\nShellcode consisting of 32-bit and 64-bit instructions\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 3 of 12\n\nIn a 64-bit OS, the segment selector for 32-bit user mode code is 0x23, while the 64-bit segment selector is 0x33.\r\nThis is confirmed by looking at the Global Descriptor Table (GDT) in the kernel debugger:\r\nPart of the GDT in OS Windows 10 x64\r\nThe selector 0x23 points to the fourth segment descriptor (0x23 \u003e\u003e 3), and the selector 0x33 to the sixth (the null\r\ndescriptor is not used). The Nl flag indicates that the segment uses 32-bit addressing, while the Lo flag specifies\r\n64-bit. It is important that the base addresses of these segments are equal. At the time of shellcode execution, the\r\nselector 0x23 is located in the segment register cs, since the code is executed in a 32-bit address space. With this\r\nin mind, let’s take a look at the listing of the very start of the shellcode:\r\nSaving the full address 0x23:0xC\r\nAfter executing the command for RVA addresses 6 and 7, the long return address is stored at the top of the stack in\r\nthe format selector:offset, and takes the form 0x23:0x0C. In the stack at offset 0x11, a DWORD is placed whose\r\nlow-order word contains the selector 0x33 and whose high-order word encodes the instruction retf, the opcode of\r\nwhich is equal to 0xCB.\r\nSaving the full address 0x33:0x1B to 64-bit code\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 4 of 12\n\nSwitching to 64-bit mode\r\nThe next instruction call (at the address RVA 0x16) performs a near intrasegment jump to this retf instruction\r\n(RVA 0x14), having sent the short return address (offset 0x1b) to the stack. As such, at the time of execution of the\r\nretf instruction, the top of the stack contains the address in the format selector:offset, where the selector equals\r\n0x33 and the offset is 0x1b. After executing the retf command, the processor proceeds to execute the code at this\r\naddress, but now in 64-bit mode.\r\n64-bit shellcode\r\nThe return to 32-bit mode is performed at the very end of the shellcode.\r\nReturning to 32-bit mode\r\nThe retf command makes a far intrasegment jump to the address 0x23:0x0C (it was placed in the instruction stack\r\nat the very start of the shellcode, at the RVA address 6-7). This technique of executing 64-bit code in a 32-bit\r\nprocess address space is called Heaven’s Gate, and was first described around ten years ago.\r\nTrojan configuration\r\nStored in encrypted form in the body of each Sodin sample is a configuration block containing the settings and\r\ndata required for the Trojan to work.\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 5 of 12\n\nDecrypted Trojan configuration block\r\nThe Sodin configuration has the following fields:\r\nField Purpose\r\npk distributor public key\r\npid probably distributor id\r\nsub probably campaign id\r\ndbg debug build\r\nfast fast encryption mode (maximum 0x100000 bytes)\r\nwipe deletion of certain files and overwriting of their content with random bytes\r\nwfld names of directories in which the Trojan deletes files\r\nwht names of directories and files, and list of extensions not to be encrypted\r\nprc names of processes to be terminated\r\ndmn server addresses for sending statistics\r\nnet sending infection statistics\r\nnbody ransom note template\r\nnname ransom note file name template\r\nexp use of exploit for privilege escalation\r\nimg text for desktop wallpaper\r\nCryptographic scheme\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 6 of 12\n\nSodin uses a hybrid scheme to encrypt victim files. The file contents are encrypted with the Salsa20 symmetric\r\nstream algorithm, and the keys for it with an elliptic curve asymmetric algorithm. Let’s take a closer look at the\r\nscheme.\r\nSince some data is stored in the registry, this article uses the names given by the ransomware itself. For entities not\r\nin the registry, we use invented names.\r\nData saved by the Trojan in the registry\r\nKey generation\r\nThe Sodin configuration block contains the pk field, which is saved in the registry under the name sub_key – this\r\nis the 32-byte public key of the Trojan distributor. The key is a point on the Curve25519 elliptic curve.\r\nWhen launched, the Trojan generates a new pair of elliptic curve session keys; the public key of this pair is saved\r\nin the registry under the name pk_key, while the private key is encrypted using the ECIES algorithm with the\r\nsub_key key and stored in the registry under the name sk_key. The ECIES implementation in this case includes\r\nthe Curve25519 elliptic curve, the SHA3-256 cryptographic hash, and the AES-256 block cipher in CFB mode.\r\nOther ECIES implementations have been encountered in Trojans before, for example, in SynAck targeted\r\nransomware.\r\nCuriously, the same private session key is also encrypted with another public key hardcoded into the body of the\r\nTrojan, regardless of the configuration. We will call it the public skeleton key. The encryption result is stored in\r\nthe registry under the name 0_key. It turns out that someone who knows the private key corresponding to the\r\npublic skeleton key is able to decrypt the victim’s files, even without the private key for sub_key. It seems like\r\nthe Trojan developers built a loophole into the algorithm allowing them to decrypt files behind the distributors’\r\nback.\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 7 of 12\n\nSnippet of the procedure that generates key data and stores some of it in the registry\r\nFile encryption\r\nDuring encryption of each file, a new pair of elliptic curve asymmetric keys is generated, which we will call\r\nfile_pub and file_priv. Next, SHA3-256(ECDH(file_priv, pk_key)) is calculated, and the result is used as the\r\nsymmetric key for encrypting file contents with the Salsa20 algorithm. The following information is also saved in\r\nthe encrypted file:\r\nData stored in each encrypted file\r\nIn addition to the fields discussed above, there is also a nonce (random initialization 8 bytes for the Salsa20\r\ncipher), file_pub_crc32 (checksum for file_pub), flag_fast (if set, only part of the data in the file is encrypted),\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 8 of 12\n\nzero_encr_by_salsa (null dword encrypted by the same Salsa20 key as the file contents – seemingly to check the\r\ncorrectness of the decryption).\r\nThe encrypted files receive a new arbitrary extension (the same for each infection case), the ransom note is saved\r\nnext to them, and the malware-generated wallpaper is set on the desktop.\r\nCybercriminals demands\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 9 of 12\n\nFragment of the desktop wallpaper created by the ransomware\r\nNetwork communication\r\nIf the corresponding flag is set in the configuration block, the Trojan sends information about the infected machine\r\nto its servers. The transmitted data is also encrypted with the ECIES algorithm using yet another hardcoded public\r\nkey.\r\nPart of the Sodin configuration responsible for network communication\r\nField Purpose\r\nver Trojan version\r\npid probably distributor id\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 10 of 12\n\nsub probably campaign id\r\npk distributor public key\r\nuid infection id\r\nsk sk_key value (see description above)\r\nunm infected system username\r\nnet machine name\r\ngrp machine domain/workgroup\r\nlng system language\r\nbro whether language or layout is from the list (below)\r\nos OS version\r\nbit architecture\r\ndsk information about system drives\r\next extension of encrypted files\r\nDuring the execution process, the Trojan checks the system language and available keyboard layouts:\r\nIf matches are detected in the list, the malware process terminates short of sending statistics.\r\nMITRE ATT\u0026CK techniques\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 11 of 12\n\nMore information about Kaspersky cybersecurity services can be found here:\r\nhttps://www.kaspersky.com/enterprise-security/cybersecurity-services\r\nIOC\r\n1ce1ca85bff4517a1ef7e8f9a7c22b16\r\nSource: https://securelist.com/sodin-ransomware/91473/\r\nhttps://securelist.com/sodin-ransomware/91473/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"MITRE"
	],
	"references": [
		"https://securelist.com/sodin-ransomware/91473/"
	],
	"report_names": [
		"91473"
	],
	"threat_actors": [],
	"ts_created_at": 1775434592,
	"ts_updated_at": 1775791264,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ba4d65aacecd37e6d7952cdc6ea58e830c6cd3f7.pdf",
		"text": "https://archive.orkl.eu/ba4d65aacecd37e6d7952cdc6ea58e830c6cd3f7.txt",
		"img": "https://archive.orkl.eu/ba4d65aacecd37e6d7952cdc6ea58e830c6cd3f7.jpg"
	}
}