As discussed in numbers of our previous posts, GandCrab has been distributed in different ways. So far, GandCrab has transformed itself by updating its version and the latest is v5.2. AhnLab ASEC discovered that its method to check the extension of encryption target and conduct the encryption is different to the previous version.
GandCrab v5.2 separates extension list into 3 groups and manages them. The list is as below.
Figure 1 – List of extensions in 3 groups
As aforementioned, an extension in the first list is excluded from the encryption target if it matches. In case of the second list, it is speculated to be a fake list since none is used after comparison in the internal code. Thus, the second list carries out encryption, by the size of 0x100000 since it is not included in the third extension list; this will be explained in detail below. As for the third list, it makes difference in encryption method based on whether an extension matches or not.
The way GandCrab v5.2 uses necessary key for encryption is not too different from what we elaborated on v4.x. However, the previous version used to save Salsa20 key or local individual key in the registry while the new one only saves the key in ransom note after conducting Base64 encryption. This would make it need to have ransom note when requesting operators to restore.
Figure 2 – Encryption key information managed via same mean
GandCrab v5.2 utilizes Salsa20 algorithm just like previous version, conducting encryption by separating files by the size of 0x100000 from the front. If the file matches the third extension list, it encrypts the whole file. If not, it encrypts the file from the front to 0x100000. Then, it saves this information in the sublevel of the file.
Figure 3 – Information of data saved in sublevel after encryption
Therefore, when ‘encrypted size’ is saved, the data of which its size is same with original file encrypted if it matches the third extension list. In case it does not match, 0x100000 is saved if its size is smaller than 0x100000). Hence, the data will be saved as below if the file size is bigger than 0x100000 and does not match the third list. The red data below are the ones different when compared to the original file.
We were able to find out the conditions of encryption exclusion through the routine that conducts encryption differently per extension. Those conditions are as below.
1. As seen in the Figure 2, there is a fixed value ‘0x1829899381820300’ among the data saved in the sublevel after encryption. This value takes the file away from encryption target, which means that encrypted file cannot be re-infected or re-encrypted.
2. Upon approaching the target file, the ransomware uses CreateFile API to set 0x88000000 in the dwFlagsAndAttributes property. Although the extension belongs to the encryption target, it is excluded from the target if its property is ‘read-only’.
The overview of conditions for excluding targets from encryption process is as below:
1. If the file’s extension is one of the following (The first extension list from the table above):
|ani, cab, cpl, cur, diagcab, diagpkg, dll, drv, lock, hlp, ldf, icl, icns, ico, ics, lnk, key, idx, mod, mpa, msc, msp, msstyles, msu, nomedia, ocx, prf, rom, rtp, scr, shs, spl, sys, theme, themepack, exe, bat, cmd, gandcrab, KRAB, CRAB, zerophage_i_like_your_pictures (42 extensions)|
2. If one of the following data is included in the filename
|desktop.ini ntuser.dat iconcache.db bootsect.bak boot.ini ntuser.dat.log thumbs.유 -DECRYPT.txt -DECRYPT.html CRAB-DECRYPT.html KRAB-DECRYPT.txt CRAB-DECRYPT.txt ntldr NTDETECT.COM Bootfont.bin|
3. If one of the following data is included in the folder path:
|\program data\ \IETIdCache\ \Boot\ \Program Files\ \Tor Browser\ \All Users\ \Local Settings\ \Windows\|
4. If the value below is present at the end of the file
5. If the file’s property is set as ‘read-only’
AhnLab has been continuously monitoring the changes in distribution of GandCrab and its specific features. We are also updating our detection methods.