{"id":12164,"date":"2018-04-30T10:10:14","date_gmt":"2018-04-30T18:10:14","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2018\/04\/30\/news-5933\/"},"modified":"2018-04-30T10:10:14","modified_gmt":"2018-04-30T18:10:14","slug":"news-5933","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2018\/04\/30\/news-5933\/","title":{"rendered":"Spartacus ransomware: introduction to a strain of unsophisticated malware"},"content":{"rendered":"

Credit to Author: Vasilios Hioureas| Date: Mon, 30 Apr 2018 17:40:09 +0000<\/strong><\/p>\n

Spartacus ransomware is a new sample that has been circulating in 2018. Written in C#, the original sample is obfuscated, which we will go over as we extract it to its readable state.<\/p>\n

Spartacus is a relatively straight-forward ransomware sample and uses some similar techniques and code to others we have seen in the past, such as ShiOne, Blackheart, and Satyr. However, there is no sure relationship between these samples and the actors. I mention it mainly to show that they share similar functionality and are basic in form.<\/p>\n

In the case of Satyr and Blackheart, the code is nearly identical, with Spartacus following almost the same code flow with some modifications. If I were to make an assumption, I would say they are either the same actor or the actors for each of them used the same code. But again, there are no facts to prove this as of now.<\/p>\n

In general, what we notice is that there is a string of these .NET ransomware popping up, all of them more or less the same or similar. It is just an easy form of ransomware that criminals are creating, as it obviously does not take much time or thought to make.<\/p>\n

There is nothing impressive about them, in fact just the opposite. I would say they are boring at best. So why are we writing about one of them? The analysis of Spartacus can essentially be a used as a base knowledge for anyone analyzing variants of these basic .NET ransomware that they may come across in the future.<\/p>\n

The two take aways from this article will be understanding the code in detail, and understanding how to get an obfuscated .NET sample into a readable state.<\/p>\n

Spartacus<\/h3>\n

Before we begin, I want to mention one characteristic about Spartacus’ encryption method. Spartacus starts by generating a unique key for encryption done with the Rijndael<\/a> algorithm. (The Rijndael<\/a> algorithm is a version of AES.)<\/p>\n

This key is saved and used to encrypt every single file, meaning that two identical files will have the same cipher-text. The AES key is encrypted with a RSA key embedded in the file. The cipher-text is encoded and shown to the user in the ransom note.<\/p>\n

\"\"<\/p>\n

The fact that the\u00a0RSA key is statically embedded in the ransomware implies that the private key exists on the server side of the ransomware author’s system. Thus, all AES keys from all victims of this particular strain can be decrypted using this one key if it is ever leaked.<\/p>\n

As this ransomware is not extremely complex, we will go straight to the deep technical analysis and code walkthrough.<\/p>\n

Unpacking<\/h3>\n

When we first open the sample of Spartacus in ILSpy, we see this:<\/p>\n

\"\"<\/p>\n

The code of the functions is not visible and as you can see, everything is obfuscated. In these scenarios, I like to use a tool called de4dot<\/strong>. It will process the file and output a clean readable version. The -r flag is where you set the directory, which contains the obfuscated .NET sample.<\/p>\n

\"\"<\/p>\n

This gives us the clean version, which we will be using for our analysis going forward.<\/p>\n

\"\"<\/p>\n

Analysis<\/h3>\n

Let’s begin with the Main function shown below.<\/p>\n

\"\"<\/p>\n

It starts by making sure there is only one instance of this malware running on the system. It does so by the CheckRunProgram<\/strong> function, which, among other things, creates a mutex and makes sure it is unique.<\/p>\n

\"\"<\/p>\n

After this check is complete, it executes\u00a0smethod_3<\/strong> in a thread.<\/p>\n

Before the smethod_3 begins, the constructor for this class gets automatically called now and sets up all the private members (variables), which include all special folders to search and encrypt. It also generates the AES key, which is unique to the victim, using the\u00a0KeyGenerator.GetUniqueKey(133)<\/strong> function. The special folders can be viewed below and will be referenced throughout the ransomware to begin folder traversing.<\/p>\n

\"\"<\/p>\n

The keygen function as I mentioned is\u00a0GetUniqueKey(), <\/strong>the\u00a0details of which are below. Essentially, it just creates a series of cryptographically strong random numbers using the\u00a0RNGCryptoServiceProvider.GetNonZeroBytes\u00a0<\/strong>API function. It then uses that series of random numbers as indexes to the character set
array = “abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”\u00a0<\/strong>to build a unique string of characters. This is the AES key, which will encrypt all files going forward.<\/p>\n

\"\"<\/p>\n

Now that the constructor of the class has been initiated, let’s take a look at the\u00a0smethod_3\u00a0<\/strong>function that was called.<\/p>\n

\"\"<\/p>\n

This function iterates the list of special folders, which was generated in the constructor and begins its recursive traversal encrypting every file in the folders using the smethod_6<\/strong> function. One thing I will note here is that the encryption loop does not discriminate file types or special files. It will encrypt everything it comes across. Also, you can see smethod_1<\/strong> being called. This may be a leftover mistake of the programmer, as its output is not used anywhere in the program and is called later on when it’s time to display the encrypted key to the user.<\/p>\n

As I mentioned, the smethod_6<\/strong> function is the one doing all the encryption, but the smethod_5<\/strong>\u00a0function is the recursive function that will dig into each sub folder of whatever location it starts at, calling smethod_6<\/strong> on each iteration to encrypt the files in that sub folder.<\/p>\n

\"\"<\/p>\n

As you can see, it calls itself so that it will eventually cover every single sub folder. Then it calls\u00a0smethod_6<\/strong> to do the actual encryption, looping through every file in that folder.<\/p>\n

\"\"<\/p>\n

This method iterates all files in the current folder. The only stipulation is that the file is not already encrypted. This is the portion here, which simply makes sure the extension is not already .Spartacus:<\/strong><\/p>\n

if (Path.GetExtension(text) == \".Spartacus\")  {   return;  }<\/pre>\n
If this check passes, it calls smethod_7<\/strong>, which does the file content rewriting with the encrypted version.<\/p>\n
\"\"<\/p>\n
The function calls smethod_0<\/strong>, which encrypts the original file data, and then the next two lines write the encrypted data into the file and rename it with the .Spartacus<\/strong> extension. A quick note: Another sign that every single file is encrypted with the same key is that this ransomware does not write the encrypted AES key into the file, which we see in other ransomware that perform unique file encryptions.<\/p>\n
\"\"<\/p>\n
As you can see here, it uses the Rijndael method\u2014AES using ECB mode. The key that was generated in the constructor is hashed with MD5, and that is actually what is used as the key itself.<\/p>\n
Now we have gone through the whole process for file encryption on the main file system, through all the sub functions called inside of the parent function smethod_3.<\/strong><\/p>\n
Let’s go back to the main function now to the next line, which calls\u00a0smethod_4():<\/strong><\/p>\n
\"\"<\/p>\n
smethod_4<\/strong> basically performs exactly the same set of recursive function calls as we saw in smethod_3<\/strong>, however, rather than looping through special folders, it is now iterating over all logical drives that are attached to the system. So all external or mapped drives will be encrypted as well.<\/p>\n
\"\"<\/p>\n
We do not need to go through all these details now as we have already covered their functionality, being that they are identical to the earlier function calls. The only thing I will mention is that smethod_6<\/strong> is called twice.<\/strong>\u00a0This is done most likely to speed up the encryption by having it run on two threads.<\/p>\n
Back to main: the next and final important function call is:<\/p>\n
Application.Run(new Form1());<\/pre>\n
This will display the ransom note to the user and show the encrypted AES key in the ransom note.<\/p>\n
\"\"<\/p>\n
It starts by calling smethod_1()<\/strong>. As I mentioned above, this simply takes the AES key, which was generated at the beginning and encrypts it using the hard-coded public RSA key.<\/p>\n
public static string smethod_1()  {   return Convert.ToBase64String(Class1.smethod_2(\"<RSAKeyValue><Modulus>xA4fTMirLDPi4rnQUX1GNvHC41PZUR\/fDIbHnNBtpY0w2Qc4H2HPaBsKepU33RPXN5EnwGqQ5lhFaNnLGnwYjo7w6OCkU+q0dRev14ndx44k1QACTEz4JmP9VGSia6SwHPbD2TdGJsqSulPkK7YHPGlvLKk4IYF59fUfhSPiWleURYiD50Ll2YxkGxwqEYVSrkrr7DMnNRId502NbxrLWlAVk\/XE2KLvi0g9B1q2Uu\/PVrUgcxX+4wu9815Ia8dSgYBmftxky427OUoeCC4jFQWjEJlUNE8rvQZO5kllCvPDREvHd42nXIBlULvZ8aiv4b7NabWH1zcd2buYHHyGLQ==<\/Modulus><Exponent>AQAB<\/Exponent><\/RSAKeyValue>\", Encoding.UTF8.GetBytes(Class2.smethod_0())));  }<\/pre>\n
The RSA key is hard coded and embedded into the ransomware, which means that the author has generated the private key in advance on his side.<\/p>\n
It then iterates all drives and writes the ransom note there. Finally, it opens the ransom note displaying the message and the RSA-encrypted AES key, which will be used by the victim in order to decrypt.<\/p>\n
After all of this, the final thing it does is call smethod_0<\/strong>,\u00a0<\/strong>which deletes shadow volumes in order to prevent the user from using as a Windows restore point.<\/p>\n
\"\"<\/p>\n
This ransomware is purely offline in that there are no network communications back to the author or any C2 server. The ransomware author does not know who he has infected until they email him with their personal ID, which is the AES key. This also means that the decryption tool the author will send is likely embedded with the AES key, which unfortunately will be unique to the specific victim.<\/p>\n
There is nothing special or innovative about this sample, but that does not mean it is not dangerous. It will still do its job\u2014at the moment there is no decryptor for this. The only slight possibility to save yourself if you realize you are being hit with this malware is to perform a process memory dump, in which case there is a slight possibility of extracting the keys from memory.<\/p>\n
In general, it is always a good idea to perform a memory dump of any malware on your system before killing the process in the slight chance that some keys can be recovered.<\/p>\n
The post Spartacus ransomware: introduction to a strain of unsophisticated malware<\/a> appeared first on Malwarebytes Labs<\/a>.<\/p>\n
https:\/\/blog.malwarebytes.com\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Credit to Author: Vasilios Hioureas| Date: Mon, 30 Apr 2018 17:40:09 +0000<\/strong><\/p>\n\n\n\n
<\/a><\/td>\n<\/tr>\n
Spartacus ransomware is a fairly new variant seen in 2018. We’ll walk you through the malware sample to analyze the code in detail, and help you learn how to get an obfuscated .NET sample into a readable state.<\/p>\n
Categories: <\/p>\n