A connection between the Sodinokibi and GandCrab ransomware families?

Summary

The Sodinokibi malware is a new ransomware family that was first described in an attack by Cisco Talos. In this attack, they noted it was strange that both Sodinokibi and GandCrab were used. In this post we will show a stronger indication of a connection between the GandCrab and Sodinokibi ransomware families, based on a comparison of their code for generating random URLs as well as some circumstantial evidence regarding the occurrence of new binaries from these families.

Introduction

Over the past few weeks, the new Sodinokibi ransomware family has appeared in the wild. As far as we know, Cisco Talos was the first to report on this family as part of an attack in which the actors also deployed the well-known GandCrab ransomware. The Cisco Talos team also noted how it was strange to see a single actor deploying two different ransomware families during the same attack.

Published technical details on Sodinokibi ransomware binaries have been scarce so far. Apart from the Talos blog post containing a more in-depth analysis seems to be by BluVector discussing mainly the embedded, encrypted configuration.

In this post, we will focus more on the network activity of the Sodinokibi malware, about which to our knowledge very little has been published so far. During our analysis of the network activity, we have encountered another remarkable link between the Sodinokibi and GandCrab ransomware families.

Sodinokibi HTTPS POST requests

As mentioned by the BluVector team, Sodinokibi malware binaries contain an encrypted configuration. The binary that we have analyzed for this post also contains a separate section for the encrypted configuration, although in our binary this section is called ‘.grrr’. After RC4 decryption using the key from the same section, a list of seemingly legitimate domains can be extracted from the resulting JSON.

The malware attempts to contact each of these domains in a loop. For each domain, an HTTPS POST request is performed with a randomized URL that consists of two random directory components and a randomized filename with one of several image file extensions. For example: “/content/pictures/eikbvcpurtki.gif” or “/static/temp/ayoadvrptpvo.png”. We will discuss how this URL is constructed in more detail below.

The data of the POST request is encrypted using AES256 in CTR (‘counter’) mode. The use of CTR mode with AES256 is rather uncommon: most malware families that use a stream cipher for encryption, simply use a dedicated stream cipher such as RC4, instead of a block cipher in CTR mode.

For an individual infection, the POST data is identical for each of the domains: the data is generated before any communication takes place and is stored in the registry. The decrypted data consists of a JSON data structure containing information on the infection and the infected system.

Sodinokibi random URLs

The Sodinokibi malware binary contains three lists of strings that are used in the construction of the random URLs. Two lists of directory names, and one list of filename extensions. The filename itself is constructed by concatenating an even number of random lower-case letters (at least 2 and at most 20).

The code for this process, containing the lists of possible URL parts, is shown below:

Random values are obtained from a rather elaborate pseudo random number generator (PRNG) and differ between runs, leading to different URLs each time. A new URL is generated for each HTTPS POST request.

This process for generating random URLs reminded us of a piece of code we encountered some time ago when analyzing the GandCrab ransomware family. We decided to further investigate this and perform a more in-depth code comparison between the Sodinokibi and GandCrab ransomware families.

GandCrab random URLs

For our comparison, we have used a recent GandCrab 5.0.3 binary. The GandCrab code at first sight looks very different, as it splits the functionality for generating random URLs over three separate functions, where in Sodinokibi, the code to generate the random URLs is more concentrated in a single function as we have seen. The outer-most of these three functions also calls the function that actually performs the HTTPS POST request.

GandCrab uses a in lined linear congruential generator (LCG) to generate the random numbers for its URLs. This is the source of the additional calculations and assignments that can be seen interspersed in the lists of possible URL parts. (In Sodinokibi, generating random numbers is done by a rather more elaborate process in a separate function, leading to cleaner code.)

The list of possible parts for the first directory in the URL can easily be spotted in this function, as well as the list of filename extensions. Although both lists are not exactly equal to the lists in Sodinokibi, the resemblance does reek of more than just coincidence.

The second function in GandCrab that contributes to the randomized URLs is used to determine the second directory part. This function is rather simple:

Again, the list of possible URL parts is not exactly equal to that encountered in Sodinokibi, but there is definitely a clear degree of similarity.

The third function in GandCrab that contributes to the random URLs, is the function that generates the random filename:

This function contains a list of 16 lower-case letter pairs. A number of these pairs are picked at random and concatenated to obtain a filename. In Sodinokibi, this part of the algorithm works somewhat differently: instead of a hard-coded list of letter pairs, Sodinokibi generates pairs of random letters. The code that determines how many of these to generate however, is strikingly similar.

When asked to generate a string of random length, most programmers will probably first generate a random number to use as length, and then in a loop generate letters up until this length. That approach is (as expected) also commonly encountered in malware, for example in many DGAs that generate domains of variable length. The approach used in both GandCrab and Sodinokibi however is different: both contain a loop that repeatedly appends two letters to the filename that is generated. After each iteration, a new random length is generated, against which the current number of letter pairs is compared. This could be caused by code like “for(i = 0; i < 1 + random(9); ++i)” whereby the length is erroneously recalculated on every loop iteration.

In this third function there are also plenty of differences: a fixed list of letter pairs versus pairs of random letters, a different PRNG, a different maximum length. But we still feel the similarities are more than just a coincidence: both generate random filenames with an even number of letters by appending two letters at a time, and even more noteworthy, both use the same contrived approach to generate filenames of a random length.

The GandCrab connection

The Cisco Talos team reported how they encountered both Sodinokibi and GandCrab in a single attack, dubbing this ‘The GandCrab affiliate connection’. Besides a connection through an actor using both families, there seems to also be a more technical connection between them. Even though the code bases differ significantly, the lists of strings that are used to generate the URLs are very similar (although not identical), and there are some striking similarities in how this specific part of the code works, e.g., in the somewhat far-fetched way that the random length of the filename is repeatedly recalculated.

On top of our technical analysis, we have also encountered another bit of circumstantial evidence supporting a possible connection between GandCrab and Sodinokibi: the number of new GandCrab binaries that we have encountered during the last couple of weeks has decreased significantly when compared to the weeks before that. This coincides rather remarkably with the appearance of the new Sodinokibi family.

Although we currently have no more direct evidence, we would not be surprised if there was some connection between the author(s) of both ransomware families.

How did Tesorion detect the new Sodinokibi malware family?

Tesorion has developed automated threat intelligence systems which analyze many potential malware samples each day. These systems detected several unknown binaries that showed signs of malicious behavior in general, and ransomware-like behavior in particular. As these binaries did not correspond to any known malware families, further analysis was undertaken. As our analysis showed the same behavior described in the publications by the Cisco Talos and BluVector teams, we came to the conclusion that the binaries we investigated corresponded to the Sodinokibi family those teams had also encountered.

Indicators of Compromise (IoC)

Ransomware samples used for analysis and comparison:

Sodinokibi SHA256: 246aea5a28ed117238ed0da8e6c96a9a9f1c627613d0f9f57da3e819f57231eb
GandCrab SHA256: 9511eab8c9dec309bdb5839641d4195d9b85b44c4a20b3f2f6d10c9ee4b32def

There are more than 1000 domains contacted using HTTPS POST requests by this Sodinokibi sample alone. Please note: these domains are not necessarily malicious, but they are contacted by this binary and could be used in investigations.

The first 15 hostnames this sample requests are: