The Children of CryptoLocker, Part 2. TeslaCrypt, TorLocker, TorrentLocker

Previous part: The Children of CryptoLocker, Part 1

The first examples of malware that encrypts files and then demands money for decryption appeared a long time ago. Just remember Trojan.Xorist with its primitive encryption algorithm based on XOR, or Trojan.ArchiveLock written in PureBasic, which used regular WinRAR for encryption and Sysinternals SDelete for deleting encrypted files, and demanded as much as five thousand dollars for decryption. However, it was CryptoLocker that established the bad trend among virus writers to use the latest achievements in cryptography as quite stable encryption algorithms. Today, we will investigate several encryption-based trojans which emerged after the notorious spread of CryptoLocker on the internet (or at the same time).

TeslaCrypt

The first samples of this malware appeared in November 2014 (the first sample was uploaded to virustotal.com on November 11, 2014). However, TeslaCrypt became widespread soon after, at the beginning of March 2015. During its existence, this locker changed several times, and the latest version is TeslaCrypt 2.0.0.

Window with a ransomware TeslaCrypt version 0.4.0 (RSA-2048 is written for intimidation, really AES-256-CBC is used)

Window with a ransomware TeslaCrypt version 0.4.0 (RSA-2048 is written for intimidation, really AES-256-CBC is used)

File encryption

TeslaCrypt selects many types of files for encryption (around 200), gaming file types have also found their way onto the list (saves, user profiles, etc.):

Bethesda Softworks settings file
F.E.A.R. 2 game
Steam NCF Valve Pak
Call of Duty
EA Sports
Unreal 3
Unity scene
Assassin’s Creed game
Skyrim animation
Bioshock 2
Leagues of Legends
DAYZ profile file
RPG Maker VX RGSS
World of Tanks battle
Minecraft mod
Unreal Engine 3 game file
Starcraft saved game
S.T.A.L.K.E.R. game file
Dragon Age Origins game

The encryption scheme itself changed from one version to another. Initially, it was an implementation of the AES-256-CBC algorithm, with the decryption key saved in the "key.dat" file until all files are encrypted (after encryption of the last file, this key is erased with zeroes).

In later versions (in particular, 0.4.0), the decryption key was saved in the "storage.bin" file not in open form, but modified with a digital signature algorithm with elliptic curves (sample called secp256k1) and erased with random bytes after encryption of the last file.

In later versions (TeslaCrypt 2.0.0), the encryption algorithm became much more sophisticated. Probably the authors of this trojan looked at Critroni's encryption mechanism and copied it for their creation almost unchanged. All algorithms are implemented with a freely distributed "cryptlib" library of, presumably, version 3.4.1 (the locker's body contains the lines with names of the source files from this library: bn_lib.c, ec_lid.c, ec_key.c, etc.). The difference in TeslaCrypt algorithm implementations from their implementations in CTB-Locker is that session keys are not generated for each file, but for the current computer session (until the next reboot).

Before encrypting the files, TeslaCrypt deletes all system backups (shadow copies) of the victim's files with the command

vssadmin.exe delete shadows /all /quiet

vssadmin.exe

Vssadmin.exe is a utility that allows you to administer Shadow Volume Copies. (Volume Snapshot Service or Volume Shadow Copy Service). This service is used in the standard system recovery process and in different backup copying/data archiving software (Handy Backup, Leo Backup, etc.). Some encryption-based lockers use this utility to delete all created shadow copies, which, naturally, makes it impossible to recover encrypted files. As a rule, in this case the command looks like vssadmin.exe delete shadows /all /quiet, where the delete shadows parameter refers to the deletion of shadow copies, the /all parameter says that all shadow copies must be deleted, and the /quiet parameter means that all the performed actions must be unnoticed by the user, without displaying any messages.

TeslaCrypt 2.0.0. saves the information required for work in the register (and not in the files, as before). The trojan's identifier is saved in HKCU\Software\msys\ID, while HKCU\Software\<trojan ID>\data is used to store the number of the Bitcoin wallet, the master-public public key, the ECDH algorithm's shared secret and other service information (neither master-private nor session-private are saved anywhere).

TeslaCrypt service information saved in the registry

TeslaCrypt service information saved in the registry

An interesting feature of the latest TeslaCrypt version is that the ransom demand message is not displayed in a GUI window but as an HTML page which is copied from CryptoWall (interestingly, TeslaCrypt disguises itself as the infamous CryptoWall — evidently, to scare the victim even more).

Page with a payment demand where TeslaCrypt disguises itself as CryptoWall

Page with a payment demand where TeslaCrypt disguises itself as CryptoWall

Connection with the command server

The body of the trojan contains a statistical list of C&C addresses. The servers themselves are located in the Tor network, but communication is performed with tor2web services (to2web.org was used in the sample under investigation).

In the first versions of TeslaCrypt, queries to the command server were sent in open form, in subsequent versions they were encrypted using the AES-256-CBC algorithm. The SHA-256 hash from the line contained in the body of the virus is used as key.

Analysis difficulties

In a separate torrent, the trojan, using CreateToolhelp32Snapshot, Process32First and Process32Next API functions, looks for processes with taskmgr.exe, regedit.exe, cmd.exe, procexp.exe, msconfig.exe names and terminates them.

In addition, not all lines are stored in open form in the body of the virus and are concealed with a rather simple encryption mechanism.

TorLocker

The first attack using this locker was recorded in fall last year. In almost all cases, Torlocker samples are associated with two versions — 1.0 (in English) and 2.0 (in English and Japanese). The main difference between the versions consists of the methods for complicating code analysis and the used source of additional modules: in version 2.0, these modules are downloaded from the Internet, while in version 1.0 they are extracted from the data section.

Window with a payment demand from TorLocker 2.0

Window with a payment demand from TorLocker 2.0

File encryption

TorLocker seeks to operate on a huge number of file types, from office documents, video and audio records, and images to virtual machine files, encryption keys, certificates etc.:

.3gp .7z .accdb .ai .aiff .arw .avi .backup .bay .bin .blend .cdr .cer
.cr2 .crt .crw .dat .dbf .dcr .der .dit .dng .doc .docm .docx .dwg .dxf
.dxg .edb .eps .erf .flac .gif .hdd .indd .jpe .jpg .jpeg .kdc .kwm .log
.m2ts .m4p .mdb .mdf .mef .mkv .mov .mp3 .mp4 .mpg .mpeg .mrw .ndf .nef
.nrw .nvram .odb .odm .odp .ods .odt .ogg .orf .p12 .p7b .p7c .pdd .pdf
.pef .pem .pfx .pif .png .ppt .pptm .pptx .psd .pst .ptx .pwm .qcow .qcow2
.qed .r3d .raf .rar .raw .rtf .rvt .rw2 .rwl .sav .sql .srf .srw .stm
.txt .vbox .vdi .vhd .vhdx .vmdk .vmsd .vmx .vmxf .vob .wav .wb2 .wma .wmv
.wpd .wps .xlk .xls .xlsb .xlsm .xlsx .zip

When launched, TorLocker selects one of the 128 public RSA keys embedded in the body, using the computer name and the serial number of the logical drive.

The files are encrypted with the AES-256 algorithm, with an individual encryption key for each file. If the file size exceeds 512 Mbytes, only the first 512 Mbytes are encrypted. Then, a 512-byte service section is added to the end of each file: 32 bytes of padding, 4 bytes of the Trojan’s identifier, and 476 bytes of the used AES key encrypted with RSA-2048, selected by a public key at the beginning of the operation. The encrypted data is written on top of the original, non-encrypted data; no new file is created, and the old file is not deleted. The name and the extension of the encrypted files are not changed.

Connection with the command server

Connection to the command server is established only after all the files are encrypted. For this reason, the trojan's operation goes unnoticed and can't be detected through atypical network activity.

All command server addresses are written in the trojan's body, the tor.exe Tor client connects them using polipo.exe proxy. These two files are either extracted from the virus's data section (in version 1.0) or downloaded from the Internet (in version 2.0).

Names of command servers in the body of TorLocker 2.0

Names of command servers in the body of TorLocker 2.0

Download and run tor.exe and polipo.exe in TorLocker 2.0

Download and run tor.exe and polipo.exe in TorLocker 2.0

Analysis difficulties

Usually, the representatives of this family are packed with UPX, in addition, the data section is encrypted using the AES algorithm with a 256-byte key (the first four bytes of this key are written at the end of the encrypted files and used as an identifier of the specific trojan sample).

The code itself is generously diluted with sequences of meaningless commands which are not executed under any conditions (so called "hanging bytes") and only deal with unconditional transfer command.

Cryptocontainer settings in TorLocker 2.0 (hanging bytes are seen before and after

Cryptocontainer settings in TorLocker 2.0 (hanging bytes are seen before and after

When launched, TorLocker creates a separate torrent which, using CreateToolhelp32Snapshot, Process32First and Process32Next API functions, looks for processes with taskmgr.exe, regedit.exe, procexp.exe, procexp64.exe names and terminates them.

TorrentLocker

The first infections with this locker were recorded in early February 2014. The name was taken from the name of the Bit Torrent Application register section, which was created with the first versions of this locker for storing service information. This virus only spread through infested spam email.

File encryption

TorrentLocker encrypts about 250 different files, which makes it impossible to do anything productive on the infected computer. The AES-256-CBC algorithm is used for file encryption (the first versions used the AES-256-CTR algorithm, the same key and initialization vector were used for all files, which made the algorithm vulnerable and made it possible to recover the files without any financial losses).

The AES key is generated once based on values received from several API functions (GetTickCount, GetCurrentProcessId, GetCurrentThreadId, GetProcessHeap, GetThreadTimes, GetProcessTimes). After the files are encrypted, the AES key is encrypted with an RSA public key, which is found in the malware file, and is written at the end of the encrypted file together with the hash total of the AES key and the value of the encrypted AES key. To decrease the load on the processor and the encryption time, TorrentLocker only encrypts the first two megabytes of the file (if the file is larger than two megabytes, otherwise the file is encrypted in full). The freely distributed LibTomCrypt library is used to implement the encryption algorithms.

Connection with the command server

In the first versions, communication with the command center was established using the hard-coded address in the locker's body. In the later versions (after October 2014), dynamic address generation algorithm was added, which worked if connection to a hard-coded C&C server failed. It provided an auxiliary list of thirty command center domain names.

The whole traffic is encrypted either with SSL protocol or with chain-XOR algorithm. Information for identifying the user (from the name of the computer, the system installation date and the OS version), is delivered to the command server. This identifier makes it possible to establish the fact of payment later and allows file decryption.

Analysis difficulties

TorrentLocker uses several methods for counteracting debugging and identification of the virtual environment. In particular, using the OutputDebugString API function, which is activated 320,500 times per cycle. Under the debugger, this causes the debugging process to hang.

AntiVM in TorrentLocker

AntiVM in TorrentLocker

Antidebugging in TorrentLocker based on OutputDebugString

Antidebugging in TorrentLocker based on OutputDebugString

Moreover, a 2-level encryption of the trojan's code is performed using the RC4 algorithm. After decryption, the trojan introduces the code directly responsible for execution of the locker's malicious functions in explorer.exe and svchost.exe processes.

Conclusion

Finally, it should be noted that the threat of an attack from a new encryption-based locker is quite relevant today. Most current lockers use all the latest advances in cryptography, and it is not always possible to recover your files without the authors of this malware and the creators of the business.


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>