Tuesday, 22 September 2015

TeslaCrypt 2.1 Analysis: Cracking "Ping" Message

At the beginning of September 2015, we discovered a new version of TeslaCrypt - 2.1 in the customer's network. The sample (MD5: b10d45335b8de97e6bc1d5cc9449c323) was loosely detected by the majority of AV signature engines on the Virustotal. The detection rate was 4/57 and can be explained by using code obfuscation, which proved its efficiency. The previous TeslaCrypt 2.0 was already well described by Kaspersky Lab, so we will use the same naming convention for encryption keys as on the Securelist for this post.

Now, TeslaCrypt 2.1 sends extra information in the C&C request in an encrypted way. The list of domains used as “gates” will be presented below with corresponding Yara rule, as well as a mechanism used to encrypt data sent to the remote server, which has not been yet explained anywhere.


Once executed it moves itself to %AppData% folder and launches itself from this folder. This ransomware runs 5 threads to implement different activities simultaneously. Among them:

  • encrypting files 
  • removing shadow copies of files: "vssadmin.exe delete Shadows /All /Quiet"
  • closing processes of analysis tools

It creates registry key named with the installation id. The registry data and a file header structure with stored keys remained unchanged from 2.0.


TeslyCrypt uses both active and passive protection.

1. Active protection

It closes the processes with following strings in names:

  • taskmgr 
  • procexp 
  • regedit 
  • msconfig 

It checks for the debugger running with "IsDebuggerPresent".

2. Passive protection

The code is obfuscated that complicates analysis process and helps to avoid being detected by AV. For instance, all API functions are called via wrappers with "push-ret" inside instead of normal "call"s. So you don't see the list of imported API functions.

File Encryption

TeslaCrypt encrypts the files with the following extensions:
.r3d .css .fsh .lvl .p12 .rim .vcf .3fr .csv .gdb .m2 .p7b .rofl .vdf .7z .d3dbsp .gho .m3u .p7c .rtf .vfs0 .accdb .das .hkdb .m4a .pak .rw2 .vpk .ai .dazip .hkx .map .pdd .rwl .vpp_pc .apk .db0 .hplg .mcmeta .pdf .sav .vtf .arch00 .dba .hvpl .mdb .pef .sb .w3x .arw .dbf .ibank .mdbackup .pem .sid .wb2 .asset .dcr .icxs .mddata .pfx .sidd .wma .avi .der .indd .mdf .pkpass .sidn .wmo .bar .desc .itdb .mef .png .sie .wmv .bay .dmp .itl .menu .ppt .sis .wotreplay .bc6 .dng .itm .mlx .pptm .slm .wpd .bc7 .doc .iwd .mov .pptx .snx .wps .big .docm .iwi .mp4 .psd .sql .x3f .bik .docx .jpe .mpqge .psk .sr2 .xf .bkf .dwg .jpeg .mrwref .pst .srf .xlk .bkp .dxg .jpg .ncf .ptx .srw .xls .blob .epk .js .nrw .py .sum .xlsb .bsa .eps .kdb .ntl .qdf .svg .xlsm .cas .erf .kdc .odb .qic .syncdb .xlsx .cdr .esm .kf .odc .raf .t12 .xxx .cer .ff .layout .odm .rar .t13 .zip .cfr .flv .lbf .odp .raw .tax .ztmp .cr2 .forge .litemod .ods .rb .tor .crt .fos .lrf .odt .re4 .txt .crw .fpk .ltx .orf .rgss3a .upk 
It doesn’t encrypt files in the following folders:

  • %Windows%
  • %Program Files% 
  • %Application Data% 

The encrypted files get “.abc” extension and the recovery messages in text and html are placed in every folder as before.

To encrypt the data, it uses OpenSSL AES-256-CBC. The key is generated for every encryption session and the key length is 256 bits.

It is expanded to 240 bytes (1920 bits) round keys used to encrypt the data buffer. Once encryption is finished, the cryptolocker wipes the AES key from the memory with “FF”s.

It uses Elliptic curve Diffie-Hellman (ECDH) key agreement protocol to generate Bitcoin address to pay a ransom and to restore AES encryption key. It uses standard Secp256k1 elliptic curve.

C&C Communication

It starts with getting victim's IP address for the "Ping" message:

Then "Ping" message is constructed to be sent to C&C:


TeslaCrypt 2.1 has a new parameter “dh=” in the "Ping" message, which is master_ecdh_secret_mul value.

It is not clear yet why the attacker in 2.1 needs this extra parameter also stored in an encrypted file.
If you know master_btc_priv (“key=” parameter) is enough to withdraw money from the generated bitcoin address (which is a hash of master_btc_pub represented in base58) in “addr=” parameter.

The URL parameters are encrypted using the same AES algorithm as for encrypting files, but with another key stored as a 32 bytes constant in the body.
67 E6 09 6A 85 AE 67 BB 72 F3 6E 3C 3A F5 4F A5 7F 52 0E 51 8C 68 05 9B AB D9 83 1F 19 CD E0 5B 
It is transformed using the following string found in the binary:

The string is 31 bytes, therefore, “0x80” character added as 32nd byte:
65 77 74 65 72 77 6C 3B 6B 74 6A 77 65 72 74 6C 3B 65 77 72 74 3B 77 65 6C 72 6B 77 65 72 74 80

Initialization vector (IV):
The obtained key:
37 D5 FA EE 1D 3F 9E D3 E0 31 3F 1E DC 4F 18 45 F7 08 AD 61 6D E5 C0 C9 B7 A6 D8 5B EC 3C 2F 01 

Then quadbytes are mirrored. And after all, we have 32 bytes encryption key:
EE FA D5 37 D3 9E 3F 1D 1E 3F 31 E0 45 18 4F DC 61 AD 08 F7 C9 C0 E5 6D 5B D8 A6 B7 01 2F 3C EC 
The encrypted message looks like:
And can be sent to the attacker now.

The response is verified to be sure the information was "inserted" to the attacker's database:

Hardcoded URLs that are hijacked web servers used to deliver "Ping" messages to the attacker:

To decrypt, save the encrypted message from URL to a file (e.g. url.dat) and run the following command:
$ openssl aes-256-cbc -d -in url.dat -K EEFAD537D39E3F1D1E3F31E045184FDC61AD08F7C9C0E56D5BD8A6B7012F3CEC -iv DEADBEEF0000BEEFDEAD0000BEEFDEAD -out urldecrypted.txt 
It will work for the messages created by the same sample at least, and, supposedly, for all 2.1.0 binaries.

Decryption Service

The cryptolocker leaves the message how to recover files. You need to visit the web service in TOR network and get further instructions:

Good news is that you can decrypt one file for free :) However, it may take time. Probably, the service is overloaded due to the big number of victims.


1. We can decrypt the "Ping" message and retrieve the private Bitcoin key sent to the attacker.

2. Once we have the private Bitcoin key we can:

NioGuard Analysis System (NAS)

You can find the detailed report in our online malware analysis system nas.nioguard.com by MD5: b10d45335b8de97e6bc1d5cc9449c323.

Yara rule to detect network traffic:

rule TeslaCrypt21_pcap { meta: description = "TeslaCrypt2.1 C&C servers detection in pcaps" filetype = "pcap" source = "NioGuard Security Lab http://nioguard.com/" strings: $a1 = "josemanuelegea.es" $a2 = /\/(.*?)\/misc.php/ $b1 = "bostonhygiene.com" $b2 = /\/(.*?)\/misc.php/ $c1 = "arborvictoria.com" $c2 = /\/(.*?)\/misc.php/ $d1 = "myconsulting.es" $d2 = /\/(.*?)\/misc.php/ $e1 = "prettybaked.pl" $e2 = /\/(.*?)\/misc.php/ condition: ($a1 and $a2 )or ($b1 and $b2) or ($c1 and $c2) or ($d1 and $d2) or ($e1 and $e2) }


For more information join us at the talk about ransomware at Virus Bulletin 2015 conference in Prague soon.  

Thanks to Anders Carlsson, a forensics expert from BTH, I'm glad to work with in ENGENSEC project.

  • Alexander Adamov: ada {at} nioguard.com
  • Anders Carlsson: aca {at} bth.se

No comments:

Post a Comment