Helpful Navigation Toolbar

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.