In recent weeks, we have noticed changes in the TeslaCrypt ransomware malware family’s code base. OpenDNS recently discussed some of these changes regarding the encryption techniques in this newest variant. While reverse engineering the underlying code of these samples we discovered that the author of of TeslaCrypt borrowed code from the Carberp malware family in order to obfuscate strings and dynamically load libraries/functions.
TeslaCrypt was discovered in February 2015, and has been actively developed since its initial release. The TeslaCrypt family is known as ransomware—a type of malware that encrypts a victim’s files then demands a form of payment in exchange for the decryption key. Ransomware has been very lucrative for attackers, and an ongoing challenge for consumers and businesses alike. Malware like TeslaCrypt is often delivered via spam emails or exploit kits. A recenttakedown of multiple domains used by the popular Angler exploit kit estimated that as much as $60 million in revenue was generated annually by ransomware alone.
TeslaCrypt has historically been known to borrow code or other features from various ransomware families. Older variants used a notification screen that looked nearly identical to the one used by the CryptoLocker malware family.
Figure 1. Locker notification for old variants of TeslaCrypt
The latest versions of TeslaCrypt attempt to mimic the popular CryptoWall malware family.
Figure 2. Locker notification for new variants of TeslaCrypt
As we can see from the figures, the author of TeslaCrypt has no reservations about re-using code where possible. Starting in late September, the newest version of TeslaCrypt was introduced and it included multiple updates. One of these updates involved modifications to how the victims’ files were encrypted, which was discussed by OpenDNS in their blog post.
However, when looking at the underlying code, a number of other changes caught our eye, including string obfuscation previously unseen in TelsaCrypt.
Figure 3. TeslaCrypt string obfuscation
Upon further review, we discovered that these strings are encrypted using the RC2 cryptographic algorithm, using a static key of ‘sdflk35jghs’. The initialization vector is generated by removing the first and last 4 characters, not counting the base64 padding characters. This process is shown below.
Figure 4. TeslaCrypt IV and data parsing
While examining the Carberp source code, we discovered this exact code. Carberp was a popular banking Trojan discovered in late 2011. Its main functionality included stealing online banking credentials, keystroke logging, and capturing data from various applications.
In mid-2013, the source code to Carberp was posted for sale on an underground Russian forum. A number of weeks following this posting, the source code was leaked to the general public. This allowed any individual to modify or copy the source code to this banking Trojan, which the author of TeslaCrypt appears to have done.
Figure 5. Carberp string parsing prior to decryption
Looking further into the underlying code of TeslaCrypt, we found that the author has also implemented dynamic library and function loading.
Figure 6. Dynamic function loading in TeslaCrypt
Sure enough, this code was also copied from Carberp’s source code. Hashes used to identify function are generated via the following algorithm:
Figure 7. Hashing algorithm
In order to assist analysts and reverse-engineers working on the latest version of TeslaCrypt, please refer to the script shown in Figure 8 that will attempt to automatically convert API hashes to their actual function names.
Figure 8. Results of running IDAPython script
Overall, it appears that the author of TeslaCrypt has continued their history of re-using code and functionality from other malware families. By using the string obfuscation and dynamic API loading functionality from Carberp, it makes reverse-engineering and simple static analysis slightly more difficult. However, as the Carberp source code is so widely known by the security community, the author may have inadvertently made detection of these samples easier. This is the tradeoff of re-using code from other malware families. It’s certainly quicker and easier to do, but may result in easier detection by security software.
All new variants of the TeslaCrypt malware family samples are properly classified as malicious by Palo Alto Networks WildFire. AutoFocus users can find more information on samples and indicators related to this attack by viewing the TeslaCrypt tag.
[Palo Alto Networks Blog]