Sodinokibi Ransomware: A Detailed Study

The Sodinokibi ransomware was recently spoken about in the news, but few dived into the details of this malware. Today we will try to get to know Sodinokibi closer, consider the principles of the ransomware to identify priority vectors for protecting information systems from a new threat.







Text writers: Ravikant Tiwari and Alexander Koshelev



What do we know about Sodinokibi?



Sodinokibi is most likely being spread by the same attackers who were known for attacks by ransomware from the GandCrab family, which, judging by reports on underground forums, will no longer develop.



Sodinokibi uses the Oracle WebLogic vulnerability (CVE-2019-2725) to gain access to the victim’s computer. Once in the system, the malware tries to run itself with extended rights in order to gain access to all the files and resources of the PC without restriction ...

Sodinokibi tries not to infect computers in Iran, Russia and other countries of the former USSR.



The ransomware program uses AES and Salsa20 algorithms to encrypt user files. AES is used to encrypt session keys, as well as data sent to the management server.



User files are encrypted using Salsa20.



To generate and distribute keys, Sodinokibi uses the Diffie-Hellman algorithm on elliptic curves.



Once on the machine, the virus instantly deletes all files from the backup folder.



At the moment, ransomware is asking for 0.32806964 BTC (≈ $ 2,500) for restoring access to encrypted files. Moreover, if the ransom is not paid within 4 days, the extortionists promise to double the amount ...



How does Sodinokibi work?



We studied one instance of Sodinokibi in our laboratory. The ransomware was packaged by a custom packer. At the same time, even after successful unpacking, there were no readable lines in the code. In addition, the software does not import any system libraries or APIs. Therefore, static antiviruses that use signatures based on readable strings and tables of imported APIs will find it very difficult to detect it.



API names and other parameters were decrypted while the software was running using the RC4 algorithm. In order to make detection even more difficult for antiviruses, this ransomware executes operations on strings using a DJB hash, rather than the strings themselves ...



Initialization



Sodinokibi begins by creating a dynamic import table. First of all, the program is convinced that it is the only copy in the system by the method of checking mutexes. After checking, it decrypts the JSON configuration using RC4, which is stored in the program file and checks the boolean value of the “exp” key. If its value is “true”, Sodinokibi tries to launch an exploit. It was so in our sample, so it performed the function of exploiting vulnerabilities









Decrypted JSON Configuration



The code that runs the exploit checks to see if the September 11, 2018 update (KB4457138) was installed on the computer. This patch addresses many of the vulnerabilities below. And if it is not on the machine, Ransomware proceeds to launch 32- or 64-bit shellcode, depending on the platform on which the malware is running. We believe the ransomware is trying to elevate privileges to an administrator using CVE-2018-8440.





Snippet 1



The list of vulnerabilities that patch KB4457138 fixes:



Patch KB4457138 fixes the vulnerabilities:







If a vulnerability is not detected in the system and the process continues to work as a regular user, the RUNAS command will be used to start another instance, but with administrative rights, and the current one working with limited privileges will be completed. The full pseudocode is shown in the screenshot below.







After Sodinokibi successfully starts in administrator mode, the software performs an additional preliminary check and clarifies the value of the “bro” key in the JSON configuration and finds out the country of location. It will not try to infect computers from the following countries if such location parameters were set in the computer settings.





Refining language IDs



List of Exception Countries





* Editor’s note: for an unknown reason, the authors specifically highlight the Tatar locale in Russia



After passing the test, the malware terminates the mysql.exe process (if it was started) in order to gain access to the MySQL files and encrypt them. After that, the ransomware removes shadow copies of Windows using vssadmin, and also disables the Windows Recovery system using bcdedit:



vssadmin.exe Delete Shadows /All /Quiet & bcedit /set {default}

recoveryenabled No & bcedit /set {default} bootstatuspolice ignorealfailures








Before encrypting user files, Sodinokibi searches all file systems, including network folders, to find directories with the name “backup” and permanently deletes them. Interestingly, before deleting the directory itself, the malware first replaces the content in all such folders with a random set of bytes to make recovery impossible in principle. Fortunately, Acronis Backup files cannot be deleted so simply because they are protected at the kernel level, specifically to prevent ransomware from taking such actions.



Key generation



Sodinokibi uses the Diffie – Hellman Elliptic Curve Generation and Exchange Protocol (ECDH). The generated session keys are used in symmetric encryption algorithms, and different types of data are encrypted using different methods - AES and Salsa20.



AES is used to encrypt a private key from a pair of private and public keys that are generated locally on the user machine. It also encrypts data during transmission over the network. Salsa20 is used to encrypt user files.



Sodinokibi contains two different public keys, one of which is part of the JSON configuration, and the second is embedded in the binary. These public keys will be used to encrypt the private key created on the machine. The specific steps of key generation and encryption are as follows:



Step 1. Generation of a session pair from a private (secret, random number) and public key on the local machine.





Local private and public key generation



The encryption of the private key from Step 1 occurs using the public key from the JSON configuration



Step 2. Generate another pair of private and public keys.



Step 3. Using the private key from Step 2 and the public key (pk key value), a public key is generated from JSON, and after hashing it, a symmetric key is obtained.





Generate a symmetric key using a shared key



Step 4. Generation of a 16-bit IV (initialization vector).



Step 5. Encrypt the private key generated in Step 1 using AES with the key and IV, which were obtained during Steps 3 and 4.



Step 6. Calculation of CRC32 for the encrypted private key, which turned out in step 5.



Step 7. Adding IV and CRC32 to the end of the buffer containing the encrypted private key from Step 5.



Step 8. Saving the buffer to the associated file with the offset (marked “sk_key”).





Encrypt the private key from Step 1 using the attacker's public keys



Encrypt the private key from Step 1 using the public key contained in the binary file.



Step 9. Repeat steps 2 to 7 using another public key that was embedded in the binary file in Step 3.



Step 10. Saving the buffer to the associated file with an offset in memory (mark “0_key”)

sk_key, 0_key and pk_key are written to the registry accordingly, depending on the access rights received by the program ...



HKLM \ SOFTWARE \ recfg \ sk_key or HKCU \ SOFTWARE \ recfg \ sk_key

HKLM \ SOFTWARE \ recfg \ 0_key or HKCU \ SOFTWARE \ recfg \ 0_key

HKLM \ SOFTWARE \ recfg \ pk_key or HKCU \ SOFTWARE \ recfg \ pk_key



Encrypted secret key in the registry

Key generation for individual files with Salsa20



Step 11. Generation of a new pair from the public and private key.



Step 12. Generate a shared key using the session public key created in Step 2 and hash to obtain the next symmetric key needed to generate the keys in Salsa20.



Step 13. Installing a 256-bit key (32 bytes) in Salsa20



Step 14. Generate an 8-bit IV for Salsa20 keys



Step 15. Salsa20 key generation



Step 16. Using Salsa20 key_state to encrypt user files with Salsa20.





Salsa20 key generation for each file

Repeat Steps 11 through 16 for each encrypted file.



Illustration of encryption and decryption



To better understand how the keys are generated and transmitted between the computers of the attacker and the victim, you need to figure out how the Diffie Hellman algorithm works - this is easy to illustrate.



Encryption process





Diffie-Hellman Elliptic Curve Key Exchange (ECDH)





A detailed description of the encryption process in Sodinokibi



In order to decrypt the data, the private keys of the attacker will be required. But they are not published anywhere, and therefore it is impossible to restore files.



image

Decryption process (the secret of the attacker is his private key)



image

The simplified process of decrypting user files is illustrated below.



File Encryption on Local Hard Drives and Network Folders



To encrypt user files, Sodinokibi uses I / O Completion Ports and launches several encryption streams, but no more than twice the number of processor cores on the machine, associating these streams with a specially created I / O port. These threads use the GetQueuedCompletionStatus Win API function to wait for a packet to arrive on the I / O port before starting file encryption.



As soon as streams are created and go waiting for I / O packets to arrive, Sodinokibi begins to iterate over user files on all local drives and in all network folders, excluding CDROM and RAMDISK and assign them to the corresponding I / O completion ports. For all files that do not fall under the list of exceptions in the names of folders, files and extensions, the AddFileToIoCompletionPort function is called and then PostQueuedCompletionStatus This passes the execution to the encryption stream, which waits for information on the I / O completion port to start file encryption.



The AddFileToIoCompletionPort function also generates a unique Salsa20 key for each file to be encrypted, and passes the Salsa20 key to the encryption stream along with other metadata that should be recorded after encryption using the lpOverlapped parameter of the PostQueuedCompletionStatus Win API function.



After processing the files in each directory, except for the exception, a file is created with a ransom demand. When the files to be encrypted end, the streams go into a loop and wait until the total number of encrypted and renamed files reaches the total number of files transferred to the I / O completion port.



Finally, the system sets a flag that indicates that there are no more files to encrypt and sends several I / O packets signaling the completion of the process. Thanks to this, the cessation of additional encryption streams that were waiting for data is achieved.



image



List of Exception Folders





The encryption stream takes on reading the contents of the file, encrypting, writing back to the same file, adding meta-data including the encrypted session private key, the public part of ECDH on each file and the Salsa20 initialization vector used to encrypt the file.



After that, the stream renames the file, adding to the name a randomly generated name. Files are encrypted with the Salsa20 algorithm using the EncryptAndWrite function.



The following is an example of calling the EncryptingThreadRoutine function.



image

File structure after encryption



image

Encrypted file structure



Network activity



After the encryption process is completed, the ransomware prepares the data for sending to the management server. The data includes various fields from the JSON configuration, system information, and encryption keys. The prepared data is also written to the registry under the key “[HKLM | HKCU] \ SOFTWARE \ recfg \ stat" before they are encrypted by AES and sent to the attacker’s server ...



image



Network Data Transfer







The domain name consists of: sochi-okna23 [.] Ru + part of address 1





and part of address 2





image

URL Generation



Ransom demand



Sodinokibi has a template for writing a buyback request, which leaves room for user data. They automatically substitute the name, user id (uid - description above) and the key. The buyback request is placed in each directory, with the exception of exceptions.



image



Decryption



image



There is no free way to decrypt the data for this ransomware, and the only way to recover the data is to use the decryption service provided by the attacker. Go to it following the instructions in the ransom request ...



image



Conclusion



We recommend that you use advanced anti-ransomware protection and keep your antivirus systems up to date. All Acronis products contain enhanced ransomware protection and can protect you from such an attack, minimizing the risk of data loss.



Cyber ​​protection is contained in Acronis True Image 2019 personal solution, as well as in Acronis Backup business systems, which are accompanied by an anti-malware module based on artificial intelligence called Acronis Active Protection. Thanks to this, both systems are able to protect users from Sodinokibi.



All Articles