Helpful Navigation Toolbar

Friday, March 20, 2015

Telsacrypt 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 Telsacrypt, 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!


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


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


FIGHT!

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 Telsacrypt (note .ecc file extension). I saved "Noriben-1.6.1.py" 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

Telsacrypt 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. telsacrypt.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






EXTRA BONUS!!

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.



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







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 "systemexplorer.net" 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".


systemexplorer.net 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 "fbi.gov" (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).



Thursday, February 26, 2015

Gone Phishing


Hello again readers! Today's blog post deals with a phishing email that was sent to my Yahoo! email address that I received two days ago, allegedly from DHL. Interestingly enough the Symantec web filtering that Yahoo! uses did not block the attachment. As you can see, it is purposefully misnamed a few times. I cannot speak to the implementation of Symantec that Yahoo! uses, but I would love to know more about how it works if anyone has a contact at Yahoo!


The email came from the Display Name "sales company", and was titled "from DHL customer service". The file contained an attachment "[DHL Express tracking] (1).pdf-3.zip" (md5: 86915fae2dd82e039aab70c64ff1f5ef) (SHA256: 109f10822f89acf1a70665d7628173bc9c58c6f4d327bdbd0ca368e675f965c9). Maybe you were expecting a shipment from DHL, so maybe this email would not seem out of the ordinary to you. Hopefully the fact that the file has both a .PDF and .ZIP file extension raised a flag of caution and you recognized this as phishing, but let's proceed as if nothing odd was noticed. 


Original email, purportedly from "DHL". I believe the Norton/Symantec logo means the attachment was checked and passed a test, but not exactly sure what that test entails


Looking at the full header, we see that the email was sent from the email address "sales.pyarra89@hotmail.com". I am pretty sure that an organization such as DHL would not use a Hotmail account to send tracking information, but once again, let us continue down the analysis path.



Email header of the DHL email


When we download the file, we can see that it is indeed not a PDF, but it is actually a .zip file. It also looks like it will create an .html file when we unzip it, which is exactly what happens.



Hex Workshop view of [DHL Express tracking] (1).pdf-3.zip


Unzipped file, now named "[DHL Express tracking] (1).pdf.html"


When opening the web page, we are presented with yet another classic sign of attempted phishing, a "DHL" webpage that requests your email address and password. Hopefully this is alarming enough and you do not put in any information.



This is the web page that is displayed when you open the html file 

Now that we have a web page, let's explore the formatting of it a bit. The icons for various email providers at the bottom are odd (why is "eBay" there?), especially on what is supposed to be a legitimate DHL page. Additionally, does any legitimate web page use Comic Sans MS font? 


When we look at the file in a text editor, we can see that the email address and password are required. We can also see that the page has an ironic meta tag, and the actual domain where your email address and password will be sent to.



Viewing "[DHL Express tracking] (1).pdf.html" in Notepad++


Just for fun, I entered the email address example777@domain.com and the password "password" into the text box. 

Fake email address and password


Unfortunately after entering my "email address" and "password", I was redirected to the DHL home page. I had hoped the creators of this phishing email would have at least displayed a message stating "We are sorry, we cannot find your package in our database" or something similar, but all that happened was a basic redirect to the real, legitimate DHL home page. 


After all that, a simple redirect to DHL. Darn!


The moral of this blog post is to be wary of phishing email attempts. Most companies will never ask for your email address or password with regards to looking up information, especially in an unsolicited like this. Be sure to watch out for things like misspellings, odd looking icons, mismatched file extensions, and files with multiple extensions ("shipping.exe.doc.pdf.zip.scr"). If you feel that you are unsure about an email, ask a member of your IT or information security staff. Also do not hesitate to reach out to the "sender" of the email directly with a phone call, to make sure that it is legitimate. 


If you would like to look at the file, I just uploaded it to virusshare.com (might take a little while to process) as well as submitting it to VirusTotal (5/57 detections).




Wednesday, February 11, 2015

A (new) way to consider getting data from mobile phones



Hello again readers! Today's post is possible as the result of a joint collaboration with Berla (https://berla.co/) in an effort not only to give some exposure to the very interesting and exciting world of vehicle forensics, but also to show how data stored on a vehicle can be an additional medium from which you can recover information, especially when you encounter devices for which no method exists. In fact, you can recover mobile phone data from vehicles that the device has synced to in the past, even if the device is not currently synced with the car! This post covers only a very, very small subset of the amount of data that can be recovered using the tools and techniques employed by Berla.


The subject of this post is a typical user, who employs pretty good overall security practices and owns a Samsung Galaxy Note II. This particular device is password protected, the encryption option for both the phone and the SD card are turned on, and USB debugging mode is turned off. Using a standard mobile device forensic solution, such as Cellebrite UFED, and trying a variety of different methods of extraction yields no results. This means that the data that is stored on this phone is not accessible through traditional methods. 



Galaxy Note II - Physical Extraction Attempt


Downloading... (or at least that is what it says!)


Extraction in progress...(or at least that is what it says)

First Extraction Error


Logical extraction attempt


Extraction in progress. Part II


Another extraction error. Foiled again!!



I verified that USB debugging is not on


It is passcode protected too. Curses!!



The steps that this user took to protect their device are fairly standard and easy to accomplish, especially if the user follows some basic mobile device security best practices. However, this particular user also has a lot of music stored on their device (for long commutes, subway rides, and general time passing) and, on a regular basis, syncs the device to their automobile (in this case, a uConnect system from a 2014 Fiat 500L). This is where Berla and the iVe Vehicle System Forensics can come into play and, quite honestly, may be the only source of mobile device data that you can collect.


The folks at Berla were nice enough to set up the uConnect as well as give me a quick run through of the iVe program. If you've had any experience dealing with mobile devices, the steps are going to be kind of similar, with helpful techniques and procedures (and even videos!) built-in to the iVe program to help make your vehicle data extraction go as smoothly as possible. For ease of convenience, in this case we used a uConnect 6.5/RA3 and I connected my phone over Bluetooth. (NOTE: There will be a future post about the data pulled after a USB connection, as well as posts regarding different vehicle systems and the amount of data that can be extracted from them). The Chrysler brand uses various versions of the uConnect in their family of vehicles.



First we powered on the uConnect and turned on Bluetooth on the Galaxy Note II and started the sync processes.


uConnect

Bluetooth syncing with uConnect

Successful sync!


uConnect prompt requesting access to contacts and call history

Not only can you now see my contacts and call history, you can also see up to the last 16 text messages visible on the device that were received prior to syncing with the uConnect (it is a feature, not a bug!) plus all additional messages that are received while the device is synced and connected via Bluetooth. I included a couple of screenshots from the uConnect showing this data (personal contact information removed, with the exception of a telemarketer call)


uConnect recent calls

SMS (not MMS, and only the last 16)

All contacts
(NOTE: I would like to stress again that it may very well be possible to get more data from a USB sync. Since it requires some more setup that is planned for a future post)


Once that was done, it was time to fire up iVe and extract the data from the uConnect. I cannot stress how easy Berla has made this process. It's very simple, just point, click, fill in the fields, and run the tool.


iVe Forensics GUI

Choosing the vehicle and target systems. Guides and videos are included to help you through this process if needed.

I always want as much data as possible, but partial (user data only) is also an option and is much faster.

Everything looks good, ready to rock!

Case information entered just before acquisition, just in case something in the setup process goes wrong!

And it begins!



One of the many great things about iVe is, on top of extracting data from a vehicle, is it also presents the data in a nice, simple format. Thus far it seems like a majority of the files have been SQLite databases. iVe goes a step farther and does some parsing of the data and puts it in a nice, easy to read format so even if your SQLite skills are not up to the challenge, the program can show you data such as Address Book entries, SMS, and Call History. 


Overview of data gathered by iVe (look at all of the synced devices!)



iVe parsed SMS (including panda emoticons!)


Call logs from device

Address book from device

You can export the data, if you so desire!

I also included a screenshot showing the SQLite database file "pm7000033.dbf" which, in this case, contains the SMS messages. I believe the name of the file and the path that it is under may vary, depending on the vehicle (more testing is needed for that, I didn't think to ask the question today during our extractions)



Hex Workshop and Windows Explorer view of "pm7000033.dbf", which is a SQLite database containing the SMS data from the uConnect


(NOTE: The uConnect seems to have a built-in feature that automatically powers off if running from a battery alone for more than 15 minutes. This should only happen if the uConnect has been removed from a vehicle and is set up in a lab/workbench environment. This may come into play if the vehicle has been in an accident and you must remove the uConnect from the vehicle in order to extract data from it. It took four tries (thus the name Try4) to get the full acquisition, as it took about 23 minutes. Fortunately on the last attempt I was able to hit the power button in time and keep it on before it powered off. If you are doing performing a uConnect data extraction from inside a vehicle, you should not encounter this because the uConnect will be in auxiliary mode.)


If it were not for iVe, we would have not gotten any data associated with this particular mobile device. Thanks to iVe, we managed to get a total of 1521 Address Book entries, 18 SMS, 86 call events that were associated with the device. It is definitely something to keep in mind if you are faced with a mobile device that you cannot extract data from!



There is one more key area that I would like to address, which is the protection of data that is important to you and your company. Let's imagine a scenario where you are a C-level executive working for Galactic Empire, Inc. and you fly from New York to Los Angeles in order to meet with some business representatives regarding very sensitive plans for a new Death Star you are building. There have been many text messages between you and other senior level executives with details on your secretive project. Since you have been with Galactic Empire, Inc. for many years, you have a lot of music (like the Imperial March) on your company-owned mobile device that you want to play during your drive from LAX to your hotel, so you sync your device with your rental vehicle for easier playback. Simply playing music seems innocuous, and despite prompts saying the device wants to access your information, you choose to anyway because it is "just a car". However, there is a very good probability that you also just synced your address book, call history, and (at least some) SMS messages with the vehicle. All a competitor (or security researcher, hacker, or other malicious actor) has to do is gain access to the data stored within the vehicle and they will be able to potentially gain access to much more information than just the music that you thought you synced, even if your mobile device is no longer present in the vehicle. Mobile device syncing with vehicles is yet another factor that businesses should consider in their risk analysis assessments of cyber security.