Nowadays the Russian segment of the Web is not dominated by CryptoWall or CTB-Locker, Russia has seen the formation of an "ecosystem" consisting of other types of ransom trojans, which generally don't enter the global arena. Today, we will learn about some of them and, as a bonus, we will briefly run through some "fashionable" trends in global ransomware.

Common patterns

• Most Russian ransomware trojans, unlike their publicity seeking foreign colleagues (CryptoLocker, CryptoWall, TorrentLocker, TeslaCrypt), do not parade their names.
• Trojan creators often use "simple" development tools, ready-made encryption utilities, sometimes even simple archiving utilities, which suggests that malware writers may not be very skilled. Naturally, this rule has some exceptions.

Trojan-Ransom.Win32.Rakhni

Also known as Trojan.Encoder.398 and Win32/Filecoder.NDE, its original name is unknown. This trojan first appeared in 2013 (which could be considered as the year of ransomware, as that was the year when their number skyrocketed). Since then, Rakhni has seen some major changes, but let's not delve into history but instead look closer at a modern sample discovered in September 2015.

This trojan is usually distributed unpacked. If we open the file in Hiew (Fig. 1), we immediately see the traditional frightening phrases, the attacker's email address and a list of extensions which will be used to search files. An experienced user will see that the file was written in Delphi (well, who said they don't use Delphi for coding any more?:) – Editor), you can check this by using PEiD, Detect It Easy or any other convenient tool. Using the lines at the end of the file, it is also easy to discover that DCPCrypt2 was used, so we can guess that the crypto-algorithm implementation was taken from there (later, this guess turned out to be correct).

Interactive Delphi Reconstructor is a convenient tool to analyse samples created using Delphi; you can study it right there or generate an idc-script for subsequent import into IDA. IDR recognizes most library functions correctly, so let's skip routine statistic analysis and jump to the most interesting part, to the results.

Search files for encryption

The trojan roams connected disks, searches for files using the extension list and saves their paths encrypted into the text file %TEMP%\allfiles.list. The paths are encrypted using the Blowfish algorithm in CFB-8 mode, SHA1 hash from the "lklaljga" line found in the body is used as the key, and the total number of found files is saved in the global variable.

Communication with the command server

After all the files with the required extensions are found, the trojan sends a request to C&C:

http:///index.php?ui=s&id=&c=

Here, install-id is a line generated based on the names of the user and the machine, and num-files is the number of encodable files.

In response, the server responds with a line with data in JSON format.

{
  "email": "filesos@yeah.net",
  "key": "",    //password for file encryption
  "ext": "",            //line added to the extension of the encrypted file after the attacker's email address
  "hashType": 1,                          //hash number for file encryption
  "cipherType": 2,                        //cipher number for file encryption
  "cmType": 3,                            //cipher mode
  "saltSize": 4,                          //salt size
  "Ct": 5,                                //cipher number for name encryption
  "Ht": 6,                                //hash number for name encryption
  "KeyStr": ""  //name encryption password
}

If C&C does not respond, the trojan does not stop operating, instead, it uses 1 of the 4 variants of such JSON config contained in its body.

File encryption

Rakhni reads the previously generated %TEMP%\allfiles.list file with the list of paths, decrypts each line and processes the respective file. Data from the JSON configuration is used to select one of 18 ciphers:

• Blowfish
• Cast128
• Cast256
• DES
• GOST
• ICE
• IDEA
• MARS
• MISTY1
• 3DES
• RC4
• RC5
• RC6
• Rijndael (basis of AES standard)
• Serpent
• TEA
• Twofish
• RC2

and one of 9 hashes:

• SHA1
• SHA256
• SHA512
• MD4
• MD5
• HAVAL
• RIPEMD128
• RIPEMD160
• Tiger

Then a salt of preset length is generated, the password from the config is hashed with the salt, the result is used as a key for the selected cipher. Each time a new IV is generated (subsequently, just like the salt, it is saved in the beginning of the encrypted file). The content of each file is then encrypted in the selected mode (CBC, CFB-8, CFB, OFB or CTR).

However, the modern Rakhni sample does not stop here. In order to make more mess, it also encrypts the file name – it uses Ct, Ht, KeyStr config fields as encryption parameters, hashes without salt, and uses CFB-8 cipher mode. It then encrypts the resultant byte array in base64, and sometimes replaces "/" symbols with a "{slash}" line. In the end, the encrypted file gets a name which resembles the following:

HNo0WXDGQqCW6Upfo0SO9NTFcRM592wdN52nTg==.filesos@yeah.net_Lklde

The trojan saves the attacker's demands in How_To_Decipher_Files.html files.

Other features

Like a lot of crypto-ransomware, Rakhni deletes shadow copies, but does it in an unusual way. It drops on the disk and launches a vbs-script, which, in turn, sends a request to the WMI system (Win32_ShadowCopy class) to delete the available previous file versions. Why is it done like that? Probably, because the author is trying to fool pro-active antivirus detection.

Trojan-Ransom.Win32.Cryakl

Other names: Ransom:Win32/Simlosap.A, Trojan.Encoder.567, Win32/Filecoder.CQ.

A year ago, Kaspersky Lab published an analysis of the version of this trojan that was available at that time. We will now look at the modern sample and see what has changed in the previous months.

Cryakl is usually distributed packed. I came across samples packed with Armadillo, but lately a self-written packer based on Visual Basic has been used more often. It isn't very sophisticated: it decrypts the payload in the form of the original PE, starts a copy of its process and inserts the target code in it.

The packer is removed trivially: we put the breakpoint on CreateProcess when it activates, we then search for an area with RW rights, about 400 KB big and usually located before the addresses, which are used to project systemic DLLs. Fig. 2 shows that this area contains something which resembles a PE file. We dump the area and extract an untouched original PE.

Let's look at the unpacked sample and use available tools to determine the compiler (Delphi 6.0-7.0 produced in 2001-2002!), and upload the file in IDR, IDA or other tool for statistical analysis. The lines FGIntPrimeGeneration, FGInt, FGIntRSA contained within the body suggest that the trojan uses third-party RSA implementation. The sources of FGInt library, which can be found using any search browser, help the analysis process significantly. By the way, RSA implementation in this library leads us to reflect on the world's fate, as work with large numbers in RSAEncrypt procedure is performed using a line representation in the binary system (i.e., instead of the number 0x123, the library will work with the line "100100011" = "\x31\x30\x30\x31\x30\x30\x30\x31\x31").

Key generation

After initiation, the trojan generates an infection ID in the format id = <random line>-<date and time>@<random number>, as well as several keys for different algorithms:

• simpass (2048 upper-case Roman alphabet symbols) and poly (20 numbers from 0 to 9) for self-written symmetric cipher of multiple-valued replacement
• a couple of RSA-768 keys (rsaPub = (n,e), rsaPriv = (n,d), where e = 65537, n and d are generated according to a self-made pattern)

The Cryakl body also contains 3 RSA-768 open keys inserted by the attacker. When the above-mentioned key data is generated, it is represented in the form of lines, then each of them concatenates with the "asshole" line and is encrypted by RSA using each of the 3 keys contained within the body. The resultant encrypted data is glued together using the : symbol and saved in the global variable, let's call it encryptedKeyData.

File encryption

A personal "file key", 30,000 bytes long, is generated for each file based on simpass.

The first 30,000 bytes of the file's contents are encrypted on fileKey and poly by a symmetric algorithm, which may be represented as a pseudo-code in the following form:

for (int i = 0; i < 30000; i++)buf[i] = TransformByte(buf[i], fileKey[i], poly[i % 20]);

The TransformByte procedure represents 10 transformations of open text based on fileKey byte and poly byte:

switch (poly - '0'){
  case 0:
    result = b + key;
    break;
  case 1:
    result = b - key;
    break;
  case 2:
    result = b + key + poly;
    break;
  case 3:
    result = b + key + poly - '0';
    break;
  case 4:
    result = b - key - poly;
    break;
  case 5:
    result = b - key - poly + '0';
    break;
  case 6:
    result = b + poly - '0';
    break;
  case 7:
    result = b - poly + '0';
    break;
  case 8:
    result = b + poly;
    break;
  case 9:
    result = b - poly;
    break;
}

If the file is longer than 30,000 bytes, the trojan selects 3 random blocks 1,024 bytes long and encrypts each of them using RSA with an open key generated at the start of the process.

Upon completion of these activities, Cryakl forms a service structure and places it in the end of the encrypted file. The structure format is as follows:

{ENCRYPTSTART}                          //structure start mark
{
  <4 hex symbols>-<4 hex symbols>:    //serial number of the system volume (separated with "-")
  <32 hex symbols>:                   //the line contained within the sample (looks like hash)
             //encrypted key data `encrypedKeyData`
}
{}                               //original file size
{CL 1.1.0.0}                            //Cryakl version
{}                        //original file name
{<32 hex symbols>}                      //MD5 from key data (`fileKey`, `poly`, `rsaPriv`)
{}{}...{}    //numbers used for `fileKey` generation based on `simpass`
{BLOCKSSTART}           //mark showing the start of information on RSA-encrypted blocks
{}               //block shift coefficient (offs = coeff*1024)
{}               //total block size
{}     //last bytes of the encrypted block data
...
{BLOCKSEND}             //end of the information about RSA-encrypted blocks
{}               //size of the whole structure (excluding this and subsequent fields)
{ENCRYPTENDED}          //structure end mark

As a result, the encrypted file is renamed using the following scheme:

email-.ver-CL 1.1.0.0.id-.randomname-..cbf

Communication with the command server

The request sent to C&C has the following format:

http:///inst.php?vers=CL 1.1.0.0&id=&sender=

The GOOD line is expected in return. However, if the "knock back" fails, the trojan doesn't stop and commences file encryption anyway.

Other features

Cryakl sets a desktop wallpaper contained in the sample's resources in JPG format. As it proceeds, the trojan first saves its resource in the desk.jpg file, then converts it into bmp using TJPEGImage and TBitmap classes, and sets the bmp file as desktop wallpaper.

The trojan creator usually chooses different popular characters for the image. It was Fantomas in the above-mentioned article, but has now been replaced by a character from South Park (Fig. 3).

Trojan-Ransom.Win32.Aura

It is one of the few encoders with different versions which attack victims both in the CIS and other countries. It is also known as Ransom:Win32/Isda, Trojan:W32/BandarChor and Trojan.Encoder.741.

As with the two previous trojans, Aura was written using Delphi. It is distributed in different ways, mostly in packers, sometimes even multi-layered ones (for instance, UPX + VB-packer + UPX, ASPack + VB-packer + UPX etc.). After unpacking, we see that, in contrast to Rakhni and Cryakl, whose "payload" started right at the entrance, Aura execution starts from the standard procedure of form initialization (Fig. 4). In order to understand where the payload itself is, we will have to look through all event processors. In the analysed sample, the preparation for work is performed in TForm1.FormCreate, and the search and encryption of files in TForm1.Timer1Timer.

Communication with the command server

At the start, Aura generates an infection ID consisting of 10 figures, as well as a tail line in .id-numbers_blockchain@inbox.com form, which will subsequently be used as an extension of the encrypted files. Immediately after that, the trojan sends a request to C&C:

http:///script.php?number=255&id=&pc=&tail=

The number parameter refers to the length of the requested password; in response to this request, C&C sends a line of 255 symbols (in our case). In the analysed modification of Aura, this line is broken down into 8 parts, which are subsequently used for file encryption. Other modifications don't do that, instead they use a "lump" password. The breakdown scheme may be represented as a pseudocode in the following way:

LStrCopy(password, 1, 32, &passwordPart1);
LStrCopy(password, 33, 64, &passwordPart2);
LStrCopy(password, 65, 96, &passwordPart3);
LStrCopy(password, 97, 128, &passwordPart4);
LStrCopy(password, 129, 160, &passwordPart5);
LStrCopy(password, 161, 192, &passwordPart6);
LStrCopy(password, 193, 224, &passwordPart7);
LStrCopy(password, 225, 256, &passwordPart8);

File encryption

Before commencing file search, Aura uses a simple anti-emulation trick - call of an API function with incorrect parameters and examination of the returned value.

push    16713F4h        ; cchData
push    offset aFsasgd  ; "fsasgd"
push    288FEB4h        ; LCType
push    67608h          ; Locale
call    GetLocaleInfoA
call    GetLastError
cmp     eax, ERROR_INVALID_PARAMETER
jnz     exit

The body of the sample has not revealed any indications of where the cryptography implementation originates (the "StreamAES" line surely hints at something, but searching it didn't result in a clear answer). So, we are using the constants to confirm the suggestion that it is indeed AES; analysis (statistical and dynamic) reveals that the CBC mode was used. No provisions were made for the procedure of transforming the password into a key - just the first 16 bytes of the password are taken. The same value, 16 bytes from 0 to 15, is always used as IV.

During file encryption, the analysed trojan sample takes the first 30,000 bytes of the file's contents (if it is smaller, it takes the whole file) and encrypts it with passwordPart1 password. A 32-bit number, equal to the size of the encrypted data, is recorded at the beginning of the file. This number is followed by the cipher text, without the first dword, and the first dword of the cipher text is recorded at the very end of the file. It is followed by a shift of this dword in the form of a text line, and then by the 1 byte containing the length of this text line.

This is where encryption of the 1st layer is completed and the trojan repeats the same actions with passwordPart2, ..., passwordPart8 passwords. As a result, the first 30,000 bytes of the file are encrypted 8 times, and a structure of 8 blocks, 1 for each layer, is formed at the end of the encrypted file.

4 bytes                         //The first dword of the cipher textnumber in the form of a text line    //shift of this dword
1 byte                          //length of this text line

The encrypted file gets an additional extension of .id-numbers_blockchain@inbox.com type, where the id is followed by the infection ID.

Note: the 8-layer encryption was identified only in samples with the blockchain@inbox.com return address. All other Aura modifications don't divide the C&C password into parts and use only 1 layer in encryption.

Other features

Just like Cryakl, Aura sets desktop wallpaper with a ransom demand. Sometimes they introduce hot topics, remember the fuss about Ebola a year ago, when the Aura modification with a help@antivirusebola.com return address and respective images was also distributed. In our present-day sample, the desktop wallpaper uses the picture of Edward Snowden, the former NSA employee who has become a transparency advocate (Fig. 6).

Trojan-Ransom.Win32.Shade

Also known as Ransom:Win32/Troldesh, Trojan.Encoder.858, Win32/Filecoder.ED; like with other reviewed encoders, the original name is unknown. Recently, a rather detailed review of this trojan was [published] (https://securelist.ru/analysis/obzor/26790/shifrovalshhik-shade-dvojnaya-ugroza/), so we will briefly list its features and look at some minor changes which have occurred since that publication.

Shade was written using C++, it is usually distributed packed (different self-made packers + UPX). Recently, there have been cases of Shade being spread in the form of PE inside an OLE-container built in the document "Hello.docx". Fig. 7 shows what it looks like from the victim's perspective. There is no automatic infection - the victim is asked to click the icon inside the document.

Main functionality

The trojan uses AES-256 algorithm in CBC mode for file encryption; it generates 2 keys for each file - it uses one to encrypt the content and the other to encrypt the file name; it uses an array of 16 zero bytes as IV. It then encrypts these unique AES keys with an RSA algorithm on a 3,072-bit key received from C&C or (if it is unavailable) one selected from the set of keys built in the trojan's body.

The encrypted files are renamed base64(AES(originalName)).xtbl, or originalName.ytbl, if the first variant is impossible for some reason. The recently identified samples have revealed that the .xtbl extension has been replaced with a .breaking_bad one, and the .ytbl line has been replaced with a .heisenberg, which is an explicit reference to the popular TV show.

Other noteworthy changes in the modern samples in comparison to the old ones include the decreased size - ~780KB instead of ~1.8MB. This happened due be removing the link with the Tor client and by not using C&C in this anonymous network.

Additional functionality

When the files are encrypted, Shade doesn't complete its process but initiates a permanent cycle, where, using random time intervals, it requests a list of URLs from C&C which lead to samples of additional malware, which it then downloads and installs in the system. So, it turns out to be not only an encoder but a downloading bot as well, so I urge that you perform a comprehensive treatment of a system where Shade has been discovered.

Other features

Funny observations: the trojan memory dump reveals an "Easter egg" - a line addressed to antivirus analysts. Fig. 9 and 10 show the respective lines from the sample dumps from June 3 and September 24, 2015.

A final taster

Let's have a brief look at some unusual crypto-ransomware and trends observed among the encoders.

An encoding worm

The Virus.Win32.PolyRansom (Virus:Win32/Nabucur, W32/VirRnsm, one of its versions is also known as "Operation Global III") polymorphous worm spreads through all media that it can get access to. It differs from other worms by encrypting the victim's file (by a simple xor dword + rol byte algorithm), it places it in encrypted form in the body of its morphous copy (not in the overlay, but inside the section) and replaces the original file with this copy. The process repeats itself for a certain list of extensions, .exe is a part of the list. As a result, it is more complicated to treat a system infected with this worm than with other common worms and even PE infectors, because if you simply delete all malware, the victim will simply lose his/her files.

When a copy of the worm is launched, it decrypts and opens the original file by itself, so that the victim doesn't suspect anything. However, within a few minutes (when the worm spreads in the accessible media), the PC screen is blocked like with old ransomware, which have now become less popular.

Ransomware as a service

A model of encoder distribution based on an affiliate program available to all. Roughly speaking, this is an online malware builder: after registration on the web resource (usually located in the Tor network), anyone can generate a sample and spread it as he/she wants (I should remind readers that these actions are punishable in accordance with the Criminal Code of the Russian Federation). The creator of the online builder automatically collects a certain percentage from the money received in this way.

Last year saw at least 2 ransom-demanding trojans which exploit this scheme and have caused a great stir in the media.

Tox

One of them, Tox (don't confuse it with the decentralized messenger of the same name), was discovered in May 2015. According to bleepingcomputer, 900 infections were identified over a three day period. In June, the author of the service [called it quits] (https://threatpost.ru/author-behind-ransomware-tox-calls-it-quits-sells-platform/8824/) and decided to sell it.

Encryptor RaaS

Another one is just called Encryptor RaaS (Ransomware as a Service). The constructor's interface can be seen at kernelmode. The trojan's developer claims that the commission will be 20 percent of the money acquired through ransom.

Encryptor RaaS (Trojan-Ransom.Win32.Raas, Ransom:Win32/Sarento, Trojan.Encoder.1479, Win32/Filecoder.EZ) uses the GMP library to deal with large numbers. It encrypts the victim's files with an RC5 cipher and generates a key for each file using the RtlGenRandom API function. Then the key, together with service information, is encrypted using the RSA algorithm with a 2,048-bit key built in the trojan's body.

It has an interesting feature - the trojan deliberately avoids files with the wallet.dat name. The following code is in the file name examination procedure:

mov     edi, offset aWalletDat ; "wallet.dat"
mov     ecx, 0Bh
mov     esi, ebx
repe cmpsb
jz      exit

Apparently, it has been done to avoid accidentally depriving the victim of the ability to pay the ransom.

Instead of a conclusion

Computer extortion has become increasingly more widespread in recent years. To avoid becoming a victim, use your common sense and the latest software. Regularly make backup copies of all your valuable files, this will not only protect them from malware but from equipment failure and other unpleasant surprises.