Helpful Navigation Toolbar

Friday, March 20, 2015

Teslacrypt vs open source tools

Hello again readers! Today's blog post is going to cover a new "variant" of ransomware that has been deemed "Teslacrypt", which was highlighted in a fairly detailed post by Vadim Kotov from Bromium Labs.  I was able to acquire two samples of Teslacrypt, which I affectionately labeled "teslacrypt.exe" and "teslacrypt2.exe".  There really isn't anything earth-shattering or groundbreaking that this ransomware does, but this blog post will highlight how you can leverage open source tools such as noriben, PE Studio, and the Live Response Collection to triage a system that has been affected with this ransomware and some tips and techniques that I picked up during my research that may help you in dealing with this (and other) forms of ransomware.

Although teslacrypt.exe and teslacrypt2.exe both performed the ransomware process in similar fashions, there were differences between both of them, primarily in the content of the actual executables themselves and the persistence mechanism that each used. For the purposes of this post, I will highlight the differences, but will refer to traits that the files share as "teslacrypt" with specific details of "teslacrypt.exe" and "teslacrypt2.exe" as needed. Both executables are available on VirusShare if you would like to dig into them on your own!

(md5: 209a288c68207d57e0ce6e60ebf60729)
(sha256: 3372c1edab46837f1e973164fa2d726c5c5e17bcb888828ccd7c4dfcc234a370)

(md5: 81f44c27c1c765890384095fe6f5f8bf)
(sha256: 3129c794296d54606d9f1771672250ee57b798ce6f9ab8335d677f48e552ae80)


First of all, I want to point out that since the last time that I mentioned noriben in a blog post, Brian Baskin has put out an update that adds some cool new features to the noriben tool. While the Malware Box of Evil is a stand-alone machine with no external network connections, I did learn a new way to leverage the awesomeness of noriben when issues arise (as you will soon see).

noriben ran on the system just fine, however this ransomware also encrypts (among many other types of files which I will cover under the "PE Studio" section), files that end with a .py (Python script) extension. Although the malware continues to run after it is started, it only appears to actually survey the system for the files to encrypt one time when it initially runs until the Ransomware windows pops up and, and then again after the system is rebooted (as evidenced by the persistence key in the Registry which I will cover in the Live Response Collection section). What this means is that although noriben itself was running, the actual script was encrypted by the ransomware, so the additional processing of the Process Monitor Log file (.pml) was not able to occur on the system itself.

Python scripts encrypted by Teslacrypt (note .ecc file extension). I saved "" after the ransomware noticed popped up, to test to see if it would be encrypted again (it was not)

Fortunately, noriben can process the .pml file after it is collected, which is what I ended up having to do.

 I copied the .pml file over to my admin laptop and ran it from the command line with the "-p" flag. This processed the pml file and generated the csv, report, and timeline files as was expected on the Malware Box of Evil.

Running noriben from another system to process the .pml file

As noriben demonstrated, running "teslacrypt2.exe" spawns a new executable "ovsbhpa.exe" which is stored in the %AppData% folder, which in this case, the full path is "C:\Documents and Settings\Administrator\Application Data\ovsbhpa.exe". The executable then deletes itself from the original location. The first thing that the new executable does is runs vssadmin to delete all shadow copies on the system, thereby likely eliminating the possibility of restoring from a backup that was contained on the system.

The processes created by Teslacrypt2, as seen with noriben

Teslacrypt creates two additional files in the %AppData% folder, "key.dat" and "log.html". The "log.html" file fairly straightforward, as it is a file that contains the listing of every file that was encrypted by teslacrypt. 

contents of "log.html"

The file "key.dat" is more interesting, as the first portion of the file contains the "Bitcoin address" (a string of characters that is Base-58 encoded) that is supposed to allow access to site in order to decrypt your files. 

teslacrypt popup window on the infected Malware Box of Evil

Interestingly enough, the "key.dat" file for both teslacrypt.exe and teslacrypt2.exe follow the same structure, but the file created by "teslacrypt2.exe" has an additional twelve bytes of data at the very end of the file. The file size of "key.dat" that was generated by teslacrypt.exe was 636 bytes. The file size of "key.dat" that was generated by teslacrypt2.exe was 648 bytes. The difference between these two versions is something that I hope to explore more in the coming weeks.

Comparing the contents of "key.dat" generated by "teslacrypt.exe" and "teslacrypt2.exe". Note the additional 12 bytes associated with the file generated by teslacrypt2.exe

The original file(s) that Teslacrypt searches for (based on file extension) appear to be encrypted, the file name is created, and then renamed with the .ecc file extension. Although this appears to be fairly benign in nature, the way that this occurs means that there is no way to recover the contents of the actual file(s) through traditional data recovery methods. I have some more digging to do through the disk image that is going to take more time, but my initial take is that there is indeed no "easy" way to recover the data from within the encrypted files.

Teslacrypt (ovsbhpa.exe) in action

PE Studio

Marc Ochsenmeier released a new version of PE Studio, 8.47, earlier this month. I took a look at both the teslacrypt.exe and teslacrypt2.exe executable files in PE Studio. teslacrypt.exe was the more "basic" of the malware, as it contained many strings that were noteworthy during the static analysis phase. It was also a few weeks older than "teslacrypt2.exe".

"teslacrypt.exe" (md5: 209a288c68207d57e0ce6e60ebf60729)
(sha256: 3372c1edab46837f1e973164fa2d726c5c5e17bcb888828ccd7c4dfcc234a370)

teslacrypt.exe file information, as seen in PE Studio 8.47

teslacrypt.exe file header, as seen in PE Studio 8.47

teslacrypt.exe indicators, as seen in PE Studio 8.47

teslacrypt.exe blacklisted strings, as seen in PE Studio 8.47

"teslacrypt2.exe" (md5: 81f44c27c1c765890384095fe6f5f8bf)
(sha256: 3129c794296d54606d9f1771672250ee57b798ce6f9ab8335d677f48e552ae80)

teslacrypt2.exe file information, as seen in PE Studio 8.47

teslacrypt2.exe file header, as seen in PE Studio 8.47

teslacrypt2.exe indicators, as seen in PE Studio 8.47

teslacrypt2.exe blacklisted strings, as seen in PE Studio 8.47

Live Response Collection

I used the "Complete" option of the Live Response Collection so I would have a memory dump, system information, and a full disk image of the system each time it was infected. I was also curious to see exactly "what" persistence mechanism was used for both variants of teslacrypt.exe. The memory dump and disk image portion will be saved for a future post (when I have more time to do some deep dive analysis) and quite honestly, the memory dump itself will probably have it's own blog post. For the purposes of this blog post, we will focus on the persistence mechanism used by each variant.

"teslacrypt.exe" (md5: 209a288c68207d57e0ce6e60ebf60729)
(sha256: 3372c1edab46837f1e973164fa2d726c5c5e17bcb888828ccd7c4dfcc234a370)

A key is created in the NTUSER.dat hive of the currently logged on user, under the path "Software\Microsoft\Windows\CurrentVersion\Run". This is a commonly used key for persistence; however, if another user was to log on the system, teslacrypt would likely not run. The name associated with this entry is "crypto13".

teslacrypt.exe persistence mechanism, as seen in autorusc.txt

"teslacrypt2.exe" (md5: 81f44c27c1c765890384095fe6f5f8bf)
(sha256: 3129c794296d54606d9f1771672250ee57b798ce6f9ab8335d677f48e552ae80)

A key is created in the SOFTWARE hive on the system, under the path "Software\Microsoft\Windows\CurrentVersion\Run". Unlike the "teslacrypt.exe" variant, this persistence mechanism affects the entire machine, not just the currently logged on user, which enables system wide persistence, rather than persistence based on a particular user.. The name associated with this entry is "svcav_module". This is likely an effort by the author(s) to try to make it blend in a little bit more on the system.

teslacrypt2.exe persistence mechanism, as seen in autorusc.txt


This blog post is already very long, but I wanted to include a plain-text listing of all of the file extensions that teslacrypt seems to target. This was taken directly from the original version; however, my initial research is that both files target the exact same file extensions. I put the file extension in descending order, for ease of browsing convenience.


Wednesday, March 4, 2015

And you get a POS malware name...and you get a POS malware name....and you get a POS malware name....

This morning I woke up to find Trend Micro/Trend Labs had a new post on an "old undetected PoS malware" which they have called "PwnPOS". I was interested at first, but this looks like just another case of randomly assigning names to malware and/or threat actors. Unfortunately for the folks at Trend, who usually put out pretty good work, the scraper in question (which is an executable file that I have personally seen with many names, but we will refer to it as "wnhelp.exe") is old. Very, very old. In fact, the date/time stamp embedded into the file itself is from 2010.

wnhelp as seen in PEStudio 8.46

The scraper is very basic, it looks through memory looking for Track data, and when it finds matching data, it saves it to a file "perfb419.dat" which is under the Windows/System32 folder. There are sometimes legitimate files with similar names under this path, no doubt it was an effort for the attackers to try to make the data blend in. 

Example of "track" data collected in perfb419.dat. 

The scraper itself does not have an active exfiltration mechanism, so either an additional file(s) is needed to exfil the collected data or the attacker(s) can remotely access the system and send the file out (email, ftp, file sharing site, etc). wnhelp uses a "service" persistence mechanism in order to stay running on the machine, so looking at just CurrentVersion/Run in the Registry will not allow you to detect the file. The service is named "Windows Media Help", and the information that is collected from the Live Response Collection using SysInternals autorunsc is listed below:

wnhelp embedded under the "Windows Media Help" service

The exfiltration methods listed in the Trend article "might" be new, but I cannot be certain as I personally do not have access to those files (yet, I am working on that). I am leery of how new these files may be though, simply based on the liberties that Trend appears to have taken with the original wnhelp file. Additionally, of all the files listed in the Trend post, the most recent compile time is listed as 2012, with most of the compile times dating back to 2010. None of these files appear to be "new" at all. 

Not "new" or "under the radar"

Back in 2013, the wnhelp sample was uploaded to malwr, among other sites, to use their automated malware analysis tool

malwr results from 2013

Additionally, a Google search for the md5 hash (c86327222d873fb4e12900a5cadcb849) shows that, at the very least, a user of the domain "" posed a question about wnhelp back in 2012. I did not dig through all of the results, but 83 search results, with several entries on the first page relating to "malware" in one form or another, is hardly flying "under the radar". query of wnhelp from 2012

UPDATE (March 6, 2015): As @maldr0id pointed out, the wnhelp file was submitted to virustotal back on October 2, 2012, with a 3/42 detection ratio. Interestingly enough, Trend Micro was one of the three that detected the file as malicious.  The same file was uploaded to virustotal on February 16, 2011. At that time it had a 0/43 detection ratio. 

virustotal results of scraper file, performed on October 2, 2012

virustotal results of scraper file, performed on February 16, 2011

In the Trend post, the author stated "PwnPOS is one of those perfect examples of malware that’s able to fly under the radar all these years". As you can see from just the examples that are listed above, that statement is simply not true. It does highlight the importance of understanding "what" is running within your POS environment. It also highlights the fact of regularly checking systems within your POS environment to make sure that they are running properly and there is nothing "else" (malicious or otherwise) running on those systems.

Several month ago I came across a domain that was hosting this (and other) samples of POS malware. I collected all of the samples and files on the domain. The owners of the domain let the registration lapse a few months ago, at which time I purchased it and re-directed it to "" (my own way of "getting back" at bad actors). If you are interested please feel free to contact me, I will share some of the files with you (I cannot share them all, as some of the files contained information that I legally cannot share).