Ransomware REvil - Sodinokibi: Technical analysis and Threat Intelligence Report

The Sodinokibi ransomware, also known as REvil, made its first appearance in April 2019 and seems to have filled the hole left behind GandCrab

Sodinokibi ransomware, also known as REvil, made it first appearance in April 2019, where it looks to exploit the Oracle WebLogic Server vulnerability to propagate itself.

C.R.A.M. (Research Centre Anti-Malware) of TG Soft has analysed ransomware evolution in the last few months.

Download the report in PDF: Technical analysis and Threat Intelligence REPORT

Last update: 2019-08-08



In Italy it made first appearance  in May 24th 2019, with a RDP attack, as we posted in the tweet of May 28th 2019:

The authors of Sodinokibi ransomware, even if they are the first versions of their creation, seem to have a long experience in this threats of cyber-crime.
Some researchers have identified the similarities with GandCrab ransomware,  whose project was shut down in  beginning June. It seems that Sodinokibi ransomware is the right candidate to fill the hole left behind GandCrab.

Infection Vector

Sodinokibi ransomware uses different methods of propagation:
  • Oracle WebLogic Server Vulnerability
  • RDP attacks
  • Spam Campaigns
  • Watering hole
  • Exploit kit and malvertising
In Italy, we have observed that Sodinokibi ransomware used various methods of propagation.  All such methods have been found in Italy except Oracle WebLogic Server vulnerability.
The first attack that we have record was on 24th May 2019, in this case the infection vector was through RDP attack. This kind of infection vector execute a brute force on credentials, it has already been used by other ransomware as Dharma.
Interestingly, the IP 151.106.56[.]254 used by cyber criminal to access via RDP was the same IP dentified in other RDP attacks in June of this year.
Affiliates have used spam campaigns to distributed Sodinokibi ransomware, that was recorded in June. A new campaign was discovered which deals:
  • Booking.com
  • DHL
 “Booking.com” campaign in the summer months, is very apt choose with the summer holiday season approaches, it may induce the victims to open the attachment.
In the images below, we can see the two malspam campaigns of Sodinokibi.

Booking DHL

In Italy the first case of watering hole was recorded on website “winrar.it” a distributor of WinRar in Italy. For the whole day on Wednsday the 19th June was downloaded Sodinokibi instead of setup of WinRar.

In 2016 “winrar.it” website was already attacked by APT StrongPity, here too this was watering hole attack, in which the setup of WinRar was modified to include and downloaded also StrongPity spy malware.

If in 2016 the attack on “winrar.it” was organized by a professional cyber-espionage organization, in the attack of this year the attackers have replaced the setup of WinRar with Sodinokibi. Who downloaded WinRar in the afternoon of 19th June, could find something strange in the downloaded file, the icons, actually, are not like the WinRar ones, as we can see in the figures below:

Icona Icona 2
In addition, the execution of file does not downloaded WinRar, as has been the case of StronPity ransomware.

Attackers have poorly exploited the watering hole attack to winrar.it.

In other cases involving the spread of Sodinokibi, registered in Italy on 7th June 2019, were utilized malvertising attack .
The authors of Sodinokibi seem to be very active in spreading the ransomware.
Back on top

Sodinokibi Ransomware Analysys

Then we analyze Sodinokibi version 1.1.
When the file infected from ransomware is executed, Sodinokibi generates a different mutex for each build, as en example :
  • Global\D382D713-AA87-457D-DDD3-C3DDD8DFBC96
A section of the file infected is decrypted with RC4, this section contains the configuration of the malware structured in this way:

    "pk": "",
    "pid": "",
    "sub": "",
    "dbg": ,
    "fast": ,
    "wipe": ,
    "wht": {
        "fld": [],
        "fls": [],
        "ext": []
    "wfld": [],
    "prc": [],
    "dmn": "",
    "net": ,
    "nbody": "",
    "nname": "",
    "exp": ,
    "img": ""

In the table below we see the description of the fields:

Field Description

Public Key in base64


Identifier of distributor


Identifier of subscription


Debug: true/false





wht -> fld

Folder exclusions

wht -> fls

Files exclusions

wht -> ext

Exclusion of the extension


Wipe folder


Process to terminate


Domains C2


Files encryption in the network: true/false


Instructions for payment


{EXT}-readme.txt ( EXT is the extension of file encrypted)

exp Exploit True/False

Image contained in alert encryption on the desktop

If "exp" field is "true" then a 32 or 64 bit shellcode is executed with the exploit CVE-2018-8453 through the elevation of privilege.

The next step is create a registry key  REcfg if it is not already exist:
If the key do not have permissions, it is created in HKEY_CURRENT_USER.
The following values are created  within REcfg:
  • pk_key
  • sk_key
  • 0_key
  • rnd_ext
  • stat
Back on top

Calculate the private and public keys

Now the private and the public keys are calculated, as we can see in the figure:


Private and public keys are calculated in this way:


The private key was generated from random number of 256 bit, from the figure we can see the random number generation subroutine PRNG (PseudoRandom Number Generators):


The function to generate PRNG use the hardware Intel Ivy Bridge, based on NIST’s SP 800-90 guidelines, through the call to assembly rdrand instruction.

The random number generated, before it becomes private key, is elaborated in this way:

At this point, starting from private key was generated public key. The private and public keys are generated using  ECC (Elliptic Curve Cryptography).

The keys (private and public) are both two numbers of 256 bit, which define two points on the elliptic curve.

The Exchange of the keys is made with the “Elliptic Curve Diffie-Hellman” (ECDH) method, where:
Given G a fixed point of the curve, where:
  • dA = private key of A (secret random number)
  • PA = G*dA = public key of A (G multiplied by dA)
  • dB = private key of B (secret random number)
  • PB = G*dB = public key of B
Sodinokibi use eliptic curve “Curve25519”, in which G={9}, developed by Dan Bernestein, as supposed in the post of  Eric Klonowski (@noblebarstool) on Twitter.
After Sodinokibi  has generated  the ECC pair of keys in the memory, which we call dk_key  (private key) and pk_key  (public key), the public key is stored in the recfg regisry key inside of the value pk_key:


[pk_key] = Public Key

Back on top

sk_key Data Structure

At this point sk_key  data structure is  generated  by the call to Sub_13597B subroutine:

pBuff_sk_key = Sub_13597B (key_pubblica_json, key_privata, size IN, size out)

The Sub_13597B aims to encrypt the private key  generated inside sk_key  data structure.
The Sub_13597B takes 4 input parameters:
  • key_pubblica_json: public key “pk” inside the json configuration section
  • key_privata: private key generated “dk
  • size IN: size of “dk
  • size out: sk_key structure dimension
Sub_13597B subroutine execute the following steps:
Allocate a buffer of 0x58 byte and copy the private key (dk_key) “key_privata” from offset 0x4 into buffer
  1. Calculate a new pairs of ECC keys, one private (dk_new) and one public (pk_new)
  2. Calculate dk_new*pk -> shared_key_new (where pk is public key inside the json configuration section) and the result is “hashato” with SHA-3.
  3. Calculate a random number of 16 byte -> random_16,  it will be used as IV (initialization vector forAES)
  4. Encrypts the buffer allocated from 0 to 0x24 via AES-256 CTR through the IV initialization vector and SHA-3 (shared_key_new)
  5. Copy the public key pk_new into buffer allocated at offset 0x24
  6. Copy the random number random_16 into buffer allocated at offset 0x44
  7. Calculate the CRC32 of the buffer allocated from 0 to 0x24 and save the result at offset 0x54
  8. Sub_13597B subroutine returns the pointer  to buffer  that is allocated to of 0x58 byte inside the sk_key data structure.
sk_key data structure, as we see on the right figure, will be stored in the registry under the same name.

We can see the call to AES-256 in CTR mode, in the figure below:


AES CTR takes the following scheme:

Back on top

0_key Data Structure

0_key data structure is generated in a similar way, by the call to Sub_13597B subroutine:

pBuff_0_key = Sub_13597B (master_key_pubblica, key_privata, size IN, size out)

The procedure for generation of 0_key  data structure is similar to that of sk_key  data structure, in this case it is used a “master public key” stored inside a executable file instead of the public key pk (the one inside the json configuration section).

The “embedded” master public key is: 

79 CD 20 FC E7 3E E1 B8 1A 43 38 12 C1 56 28 1A

04 C9 22 55 E0 D7 08 BB 9F 0B 1F 1C B9 13 06 35

Inside the 0_key data structure  we have the dk private key encrypted through the “master public key”.

0_key data structure, as we see in the figure on the right, will be saved in the registry under the same name.

Registry Key “rnd_ext”

The value “rnd_ext” is stored inside the registry key REcfg, it contains the encrypted file extension randomly calculated.

Registry Key “stat””

The value “stat” is stored inside the registry key REcfg, it contains the following string formatted:


It is stored in “stat” in encrypted and base64 encoded form.


ver Version of Sodinokibi
pid PID of  json
sub SUB of  json
pk PK ofl json
uid CRC32 of “processor brand string” and Volume Serial Number (8 bytes)
sk sk_key in BASE64
unm Username
net Name of computer
Grp Name of workgroup or domain
lng Language ID
bro True / False if the ID of language is a "friend"
Os Operating System
Bit Value: 86 or 64
Dsk Information of diski in base 64 (drive and free space)
Ext Extension of encrypted filei

Countries considered “friends” on the basis of the “bro” value:
  • Romania
  • Russia
  • Ucraina
  • Bielorussia
  • Estonia
  • Lettonia
  • Lituania
  • Tajikistan
  • Iran
  • Armenia
  • Azerbaijan
  • Georgia
  • Kazakistan
  • Kyrgyzstan
  • Turkmenistan
  • Uzbekistan

The Sodinokibi ransomware ends the current process if the keyboard language belong to the list of countries considered "friends".

The “stat” formatted string  is encrypted  with a master public key stored inside a executable file.

The master public key “embedded” is:

36 7D 49 30 85 35 C2 C3 68 60 4B 4B 7A BE 83 53

AB E6 8E 42 F9 C6 62 A5 D0 6A AD C6 F1 7D F6 1D

Back on top

Ransom instruction

Ransom instruction are prepared from the body, which is extracted from the “nbody” field of the json configuration.
The body is formatted with the following value:
  • uid
  • rnd_ext
  • stat in base 64
The “uid” is  the user ID calculated from CRC of “processor brand string” and Volume Serial Number, which is used to compose the URL where to make the ransom payment:
  • http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd.onion/<uid>
  • http://decryptor.top/<uid>

Terminate Processes and delete Shadow Copy

The processes listed in the JSON configuration under “prc” are killed and the Windows Shadow copy with the following command are deleted:

cmd.exe /c vssadmin.exe Delete Shadows /All /Quiet & bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures


Then the malware checks the "wipe" value in the JSON  configuration and if set to true it deletes all the files contained in the folders that correspond to the "wfld" value of the JSON configuration.

File encryption

A Thread is created which is pending on function “GetQueuedCompletionStatus”.

Files on local disk and network folder are numbered (if the “net” parameter of JSON configuration is a “true” value) then proceed with file encryption.

In every folder is created a .lock file and the instructions regarding the ransom with name {random extension}-readme.txt.

Files and folders that correspond to the JSON "wht" field containing the subfields "fld", "fls" and "ext", which are respectively for "folder", "files" and "extension" are excluded from encryption.

Here is an example:

"wht": {
        "fld": ["google", "mozilla", "$windows.~bt", "programdata", "$recycle.bin", "program files (x86)", "appdata", "msocache", "program files", "windows.old", "$windows.~ws", "application data", "perflogs", "windows", "boot", "intel", "system volume information", "tor browser"],
        "fls": ["bootsect.bak", "autorun.inf", "ntldr", "ntuser.dat.log", "ntuser.ini", "boot.ini", "ntuser.dat", "bootfont.bin", "desktop.ini", "thumbs.db", "iconcache.db"],
        "ext": ["exe"]

For each file intended to encryption is generated a Salsa20 key, as follows:


Encryption algorithm used by Sodinokibi is Salsa20.

The encryption key for Salsa20 is obtained in this way:
  1. Calculate a new pairs of ECC private/public  keys (dk_new_file, pk_new_file)
  2. Calculate SHA-3 (dk_new_file*pk_key) -> shared_key_salsa (where pk_key  is a public key stored inside registry under  pk_key voice). In  shared_key_salsa we will obtained the key which is plugged in Salsa20 master table.
  3. Calculate a random number of 8 byte for the initialization vector of the Salsa20 master table.
  4. Composes the Salsa20 master table.
It is created in memory a data structure that holds:
  • Handle of the file to be encrypted
  • sk_key
  • 0_key
  • pk_new_file
  • Initialization vector of Salsa20
  • The CRC32 of pk_new_file
  • Master table of Salsa20
This data structure is passed to the Thread created previously through the API functions:
  • CreateIoCompletationPort
  • PostQueuedCompletionStatus
The thread is pending on the GetQueuedCompletionStatus API function, when it receives a new call it starts the file encryption phase through the Salsa20 algorithm and then appends a part of the data structure that contains the following fields:
  • sk_key
  • 0_key
  • pk_new_file
  • Initialization vector of Salsa20
  • The CRC32 of pk_new_file
The size of the appending part varies according to the version of the Sodinokibi malware. In versions 1.0 and 1.1 the length is 0xE0 bytes whereas in version 1.2 it is 0xE4 bytes.

In the figure we can see the encryption scheme of Sodinokibi version 1.1:

Back on top

Desktop image

At the end of the files encryption, the next step is to modify the desktop image , which we can see in the figure on the right.

The image is generated using API functions for the graphics and the text is inserted using “DrawText”  function, that is loaded in “img” field through  JSON configuration.

C2 Server

We find a list of 1079 domains inside the JSON configuration.  Sodinokibi makes a connection with each domain of this list generating a URL through a DGA algorithm using the following terms: 

Term Extension
  • wp-content
  • pictures
  • news
  • pics
  • admin
  • data
  • temp
  • graphic
  • game
  • static
  • assets
  • tmp
  • uploads
  • images
  • include
  • image
  • content
  • jpg
  • gif
  • png

https://<host>/<term 1>/<term 2>/
<random chars>.<extension>

Some examples:


Sodinokibi  transmits through a "POST"  to each domain of the list the "stat" data structure in encrypted form.

From our analysis only the following domains responded with "HTTP / 1.1 200 OK":


But this does not mean that one of these domains is that of Sodinokibi C2 Server.
Back on top

Ransom payment

According to the ransom instructions, the victim have to connect to the following domains for the payment methods:
  • http://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion/<uid>
  • http://decryptor[.]top/<uid>

Victims are requested to enter first thing (img.1), the random extension and the “Key” value contained in ransom instructions  (it is the “stat” version encrypted on base64).

When victims input this data the payment amount is generated (img.2) and are provided information on how to purchase BitCoin (img.3), and in addition a support chat is included (img.4), as we can see in the following images:


The wallet for payment is generated automatically for each victim, the ransom price is $ 2,500 it doubles to $ 5,000 if payment is not made within 7 days.

How does decryption work?

The only way to recover the encrypted files by Sodinokibi is with a “dk_key” private key. The decryption key  is encrypted inside “sk_key” and “0_key”.

The attacker recovered “dk_key” in these ways:
  1. Decrypting  sk_key
  2. Decrypting  0_key
Now in order to decrypt “sk_key”  the attacker use a secret key,  the private key “dk” , which only they know. The private key “dk” is the symmetric key of the public key “pk” stored in the json configuration.
The public key “pk_new” is put in unencrypted way inside “sk_key” structure.
It is calculated the value: dk * pk_new = shared_key_new
 The “shared_key_new” is the same as: dk_new*pk.

The private key (dk_key) is encrypted with AES-256 CTR through the "SHA-3 (shared_key_new" and the random number (IV) which is on offset 0x44.
Decrypting the buffer from 0x4 to 0x24 with AES-256, through "SHA-3 (shared_key_new)" and the random number you get "dk_key".

Now the same procedure can be performed to decrypted “0_key”, in this case is used the master private key, which only the authors of Sodinokibi know, to get “dk_key”.


Now we know dk_key so to determinate the encryption key used in Salsa20 we execute the following operation:

SHA-3 (dk_key *pk_new_file) = shared_key_salsa

Where the public key pk_new_file  is put in unencrypted way at the end of the encrypted file.

shared_key_salsa is also equals to SHA-3 (dk_new_file*pk_key)

In shared_key_salsa we will have the key that is inserted in the Salsa20 master table.
Now it is possible to decrypt the files through shared_key_salsa.

Back on top


The authors of Sodinokibi have developed the following versions:

Version Date Size appending data
1.0a 2019-04-23 0xe0
1.0b 2019-04-27 0xe0
1.0c 2019-04-29 0xe0
1.1 2019-05-05 0xe0
1.2 2019-06-10 0xe4
1.3a 2019-07-08 0xe4
1.3b 2019-08-02 0xe4

Version 1.2

In version 1.2 the registry key "sub_key " has been added which contains the public key of the json configuration (pk) and the data size in the encrypted files is 0xe4 bytes, where an additional control dword with value 0 has been added.

Version 1.3

In this version has been added a field called “svc” in the json config. This field contains a list of services to delete, as we can see in the figure.

Furthermore to verify if the victim is from a “friend” country, in addition to check of language of keyboard has been added checks on the default language and on system language, as we can see in the figure.

It uses WQL to determinate the creation of processes:

SELECT * FROM __InstanceCreationEvent WITHIN 1 WHERE TargetInstance ISA 'Win32_Process'

Furthermore it uses a new key of registry instead of “REcfg”:
  • HKEY_LOCAL_MACHINE\SOFTWARE\QtProject\OrganizationDefaults
Inside to QtProject\OrganizationDefaults are saved the following values:
  • pvg
  • sxsP
  • BDDC8
  • f7gVD7
  • Xu7Nnkd
  • sMMnxpgk

Table of comparison for the version 1.2 and 1.3:

Vers. 1.2: REcfg Vers. 1.3a: QtProject\OrganizationDefaults
sub_key pvg
pk_key sxsP
sk_key BDDC8
0_key f7gVD7
rnd_ext Xu7Nnkd
stat sMMnxpgk


The trend of Sodinokibi malware campaigns has been monitored between April and July 2019.

In the table below we can see the campaigns monitored:


The fields from the table are the following:
  1. Campaign Date
  2. Type of Campaign
  3. PK (public key inside the JSON configuration)
  4. PID present in JSON configuration
  5. SUB present in JSON configuration
  6. Sodinokibi version
  7. Date the master file of Sodinokibi is compiled

PID field identify the group has acquired the service Sodinokibi ransomware (RAAS). SUB  field probably identify “SUBSCRIPTION” that is the period of validity of the service.

The pairs of PID & SUB with identical value have the same public key (PK), how we can see in the case of PID:7 and SUB: 3.

The campaign with PID 7 was the first to use Oracle Weblogic vulnerability to distribute the ransomware on 25 April 2019 (SUB:3), the same group seems to be associated with the Watering Hole attack campaign to distributor of WinRar in Italy on 19th June 2019 with a new SUB: 474.

As we can see, the group with PID: 7 has purchased more subscription periods. Using the three parameters PID-SUB-PK, one can identify the campaign associated with the same actor.

Until early July of this year, the PID 40 was the highest value, this suggests that there are at least 40different groups. The highest value of SUB was 607 which could indicate that at least 607 subscription periods have been purchased.

We compare in the graphic here below, the date of compilation of the malware and the SUB value present in json configuration. It is possible to see how the curve growth strongly suggesting  that the Sodinokibi CryptoMalware is distributed with the “as-a-service” method.

Back on top


The authors of Sodinokibi are individuals with a certain level of technical knowledge and probably this ransomware is not their first creation and it is actively developed.

This project is developed to be distributed with model RaaS (Ransomware-as-a-Service).

Sodinokibi ransomware uses for file encryption the algorithm Salsa20 with a key exchange method based on ECDH.

Sodinokibi operation spreads wide in the last month, through a different methods to distribute the ransomware via Malspam, RigEK, RDP attacks, ecc. The attackers with the recent decision to shutting down GandCrab Ransomware operation left a hole, that seem to exploited by Sodinokibi.




Back on top

Authors: Gianfranco Tonello, Michele Zuin and Federico Girotto
TG Soft's Research Centre (C.R.A.M.)

Any information published on our site may be used and published on other websites, blogs, forums, facebook and/or in any other form both in paper and electronic form as long as the source is always and in any case cited explicitly “Source: CRAM by TG Soft www.tgsoft.it” with a clickable link to the original information and / or web page from which textual content, ideas and / or images have been extrapolated.
It will be appreciated in case of use of the information of C.R.A.M. by TG Soft www.tgsoft.it in the report of summary articles the following acknowledgment/thanks “Thanks to Anti-Malware Research Center C.R.A.M. by TG Soft of which we point out the direct link to the original information: [direct clickable link]”

Vir.IT eXplorer PRO is certified by the biggest international organisation: