FindinLoveLetter from TeslaCryptg yourself victim to Ransomware is a lot like having the power go out on you while typing an extremely important document — the resulting (foul) language is the same, and the odds of getting the files back on your own are equally dismal.

Ending April on a good note, our friends at the 
Talos Security Intelligence and Research Group released a tool alongside their blog post on TeslaCrypt, one of the most recent variants of ransomware. TeslaCrypt presents itself with a love letter of sorts, claiming to have protected your files with encryption just for you; but in reality, it was a little nefarious — more like a letter from a disgruntled ex.

Although TeslaCrypt claimed to be using an asymmetric key, Talos found that this was not the case. TeslaCrypt was using a symmetric key and thus could be used to decrypt the encrypted files, and the tool Talos released would do just that. A lot happens in five months.

Back at the lab

When new samples of TeslaCrypt came through OpenDNS Security Labs, it became apparent that something had changed when our auto-analysis failed. Some updates on our analysis system fixed the problems, but we were curious to find out what else had changed — TeslaCrypt had earned itself a revisit.

After running the sample through dynamic analysis a few times and making note of file and registry changes, running processes, and network traffic, we made a quick run through a debugger, setting software breakpoints on VirtualAlloc, and hardware breakpoints on the memory that had been allocated to follow through any unpacking. After inserting a few EBFEs (jump to self) in key locations to get around anti-debugging code, unbelievably, the sample unpacked itself into allocated memory through a call to RtlDecompressBuffer as a complete binary. No rebuilding of import tables, no entry point searching, and no problem at all to dump the allocated memory to disk and add a ‘.exe’ extension. Analysis could now begin on the unpacked binary.

Strings were now readily available:

Strings from the unpacked TeslaCrypt

Look familiar?  

In reading the analysis from the Talos blog, I noticed that the all-important ‘key.dat’ file necessary to decrypt files using their tool was not dropped in this version. Great, every time the Jedi get a leg up, the dark side has to come along and restore the balance.  Was there any hope? Unlike the versions analyzed by Talos, which dropped the ‘key.dat’ file, and ‘log.html’ (a manifest of your losses), this version was dropping an HTML and text version of your ransom note, a file named ‘Recovery_File_[random].txt’, and a new key in the registry. Looking for some relations between the files was not a disappointment:

Relations between data created from a TeslaCrypt infection

Clicking through the payment links reveal yet another — the string is the bitcoin address for ransom payment:

TeslaCrypt's payment captcha

TeslaCrypt payment page showing Bitcoin payment address

With this many things lining up so far, was it possible that only enough modifications were made to neuter the Talos tool? The bitcoin address was not the only thing in the registry key and a closer look was necessary:

TeslaCrypt registry entry data mapped against the recovery file created

TeslaCrypt registry entry mapped along side the recovery file it creates.

The recovery file that was dropped mapped quite well to the contents of the registry key. According to the Talos blog, the recovery file is what is necessary to get your files back if you were not connected to the internet (or were unable to contact the C&C servers) at the time of infection. If the first string is the bitcoin address, and the last string is the registry key the remaining data can be found at, what purpose would the other two strings have other than somehow generating the decryption key?  

TeslaCrypt decryptor

Looking at the source code from the Talos decryption tool, the components necessary to successfully decrypt a file are as follows:

  • encrypted file
    • contains initialization vector
    • contains original file size
    • contains encrypted file
  • cipher key
    • contained within key.dat

A quick look at the encrypted files pre- and post-encryption showed there was no difference in file size, so the initialization vector was no longer in the encrypted file and the original file size was no longer a necessary detail. If the cipher key was within the registry key or the recovery file, then the Talos decryption tool only requires a slight modification.

OpenDNS Security Labs is already working closely with Talos to update the decryption tool with the required modifications. Look for an update shortly by keeping an eye on the following GitHub repository:

This post is categorized in: