Helpful Navigation Toolbar

Tuesday, June 16, 2015

How to Have that Awkward Conversation

Hello again readers!! Today's post is the first (but most certainly not the last) "guest post" in which friends and colleagues can share their experiences and insights and give alternate perspectives on digital forensics, incident response, and information security. 

Today's post is authored by my friend "Jack" who has much more experience (and an MBA) on the "business" side of forensics and incident response than I ever will (and let's be honest, I also will never have an MBA). "Jack" may or may not also be in the Witness Protection Program, but the OPM data breach might change that.....

(PS: Apparently cat memes are the number one attraction to blog posts, according to 87 out of 100 business professionals. The other 13 were no doubt scouring the internet for other pictures of cats.)

How to Have that Awkward Conversation

By: "Jack"

NO, not the “It’s not you; it’s me!” one.  The one where you tell your employees (or clients!) that you’ve been hacked, their information is who-knows-where, and oh by the way, you’ve got no idea how the bad guys even got in.  You know. THAT one.  

I’m not going to sugarcoat this.  It’s going to be painful.  It’s going to be embarrassing.  But just like adults always tell kids, it is better to hear it directly from you.   If the news media or banking institutions are notifying victims instead… oh boy; it’s a public relations nightmare.  

First rule of Data Breach Club: Talk first and say it loud.  No one likes being indoctrinated into Data Breach Club, but I’ll let you in on a little secret:  It’s not an exclusive membership.  You’re either in the club, or you don’t know you’re already in the club.    


If you are upfront and honest, chances are better that you might maintain the relationships your organization has with its employees, partners, and clients.  Further, you may not have a choice about public disclosure, or private disclosure, depending on contracts you have with clients.  Depending on the laws where you operate, you may be obligated to provide full disclosure within a certain time period.  Most state breach notification laws don’t specify what your notification should include; however there are some minimum guidelines which we attempt to cover in our samples below.   

In the State of Maryland for example, the Attorney General’s website says the following about data breach notifications:

Once a security breach is detected, a business must conduct in good-faith a reasonable and prompt investigation to determine whether the information that has been compromised has been or is likely to be misused, i.e. for identity theft. If the investigation shows that there is a reasonable chance that the data will be misused, that business must notify the affected consumers. 
In the event of a security breach, notice must be given to consumers as soon as reasonably practicable following the investigation. A business may delay notification if requested by a law enforcement agency or to determine the scope of the breach, identify all the affected individuals or restore the integrity of the system. Notice to affected consumer must be given in writing and sent to the most recent address of the individual, or by telephone to the most recent phone number. Notice may be sent via e-mail if an individual has already consented to receive electronic notice or the business primarily conducts its business via the Internet. The law also contains a provision for substitute notice, allowing a business to provide notice of a security breach by e-mail, posting on its website and notice to statewide media if the cost of notice would exceed $100,000 or the number of consumers to be notified exceeds 175,000 individuals.  (

Searching online for “data breach disclosure laws AND [your location]” should net you some relevant results.  When in doubt, call a lawyer that specializes in data breaches.  If the Google can’t find one, your local Bar Association should be able to assist you.  

So how do you begin that notification email?  Your letter should contain some version of the following:
[ ] denote areas where you should fill in the blank

Part I—Introduce the Problem and Accept Responsibility:  You need to be upfront and honest; if you have a lawyer advising differently, find a new lawyer (Preferably one you suspect has a secret identity and fights crime at night using heightened senses resultant from a hazardous chemical spill; but I suppose if you can’t find one, any ethical data breach lawyer will do.)  If you don’t know something, say so.  Trying to hide the fact that you don’t know something just makes you look like you are hiding something, which is usually assumed to be more sinister.  Also, please don’t place blame on nation-states for a mess of your own creation; you’ll end up looking ridiculous and becoming the Poster Child of “What NOT to do”.        

“We are contacting you because on [insert discovery date] we discovered a serious cyber-security incident that occurred between [Start Date] and [End Date] that involved a breach of your [personal information, such as medical records, credit card numbers, passwords, etc…].  At this time we do not believe that [other personal information] was accessed.  We know you have trusted us with your information and we take that trust seriously. We take full responsibility for this incident and we will work tirelessly to resolve it quickly and completely.”

And if you delayed in sending notifications to victims, say why:

“In accordance with applicable laws, we delayed notification of affected parties by 30 days, due to an official request by law enforcement.”

Part II—Here’s What Is Happening Now:  This is where you tell them what you are doing do fix this problem.  (Not diverting attention, not doing just enough to get regulators off your back, not putting on a show to restore stock prices, not doing the minimum for regulatory compliance or limiting your liability.  Actually fixing the problem.  Let me say it again for dramatic effect:  Actually.Fixing.The.Problem.)  

You’ll want to (or be required to) at least cover what you did to stop the attackers, what you are doing to clean-up the breach, and what changes you will make in the future.  Your notification should say some version of the following, pick and choose based on your circumstances:  

“Upon discovery we immediately blocked the offending IPs and shut down all out-bound traffic.  We have begun the process of finding compromised machines.”

“We brought in cyber-security experts to investigate and fix this problem entirely and to ensure that we are more secure in the future.”  

“We advised the credit reporting bureaus and banks of this incident. We are offering a free credit report to every affected party, and here’s how to do that. [Instructions here.]”  

“We are cooperating fully with law enforcement and an investigation is on-going.  There will be full participation and transparency during the investigation.  Employees will be contacted in person if their assistance is required.  Do not provide any personal information, account numbers or passwords to any unverified person via email or on the phone, now or ever.”

“We are currently dedicating money to invest in our IT infrastructure, our security personnel, and monitoring tools so that attacks in the future are thwarted.”

Part III—Here’s What the User Has to Do:  This is where you tell your employees, clients, customers, and/or Partners what they need to do.  You must be exceedingly firm about password changes and policy enforcement while at the same time making this VERY easy for them.  It’s a huge component of rebuilding trust and being transparent throughout the process.  You’ll want to take note of the inclusion of an attachment, which should detail cyber-security best practices that they can use at work or at home.      

“You will be required to choose a new password before you can log into your account.  Everyone must do this, from the newest employee to the CEO of the company—even every member of the IT team to include admin accounts.  It may NOT be the same password as last time.  Your password will be required to have upper and lower case letters, a number, and a symbol.  You cannot use dictionary words.  It must also be at least 8 characters in length.  We apologize for the inconvenience, but this is a very important part of information security.  It removes the attacker’s access to our network.  Thoroughness of this step is paramount. 

“You may wish to place a fraud alert or freeze on your credit report, which you can do by contacting the three major credit reporting bureaus, Equifax, Experian, and TransUnion [insert contact info here].  Be aware that you will not be able to borrow money or open a new credit card until you lift the freeze.”

“If your bank has not contacted you about replacing your cards, you may wish to proactively call them and ask for a replacement card.”

“We recommend following industry standards and best practices when it comes to cyber security.  The attached document details steps you can take to better protect yourself from online threats, both professionally and personally.  There is even a section included that focuses on online safety for kids and teens.”  

Part IV—We are Here to Help You:  This is where you point people to your public relations team, who in turn can run point between the employees/clients/partners and the legal team, technical team, management team, etc…  

What?  You don’t have a public relations team/person?  Didn’t anyone tell you that this is a key part of a data breach incident? This is one of those indirect costs of data breaches that no one ever considers during the risk management process.  Yes, it will cost money; you didn’t think data breaches were cheap did you?  Please note the inclusion of a toll-free number and the promise of regular updates.  We define “regular” as at least every two weeks.    

“If you have any questions or concerns, you may contact our offices at: [1-800-555-5555] or email us at [].  Our website: [] will be updated with the latest information as our investigation continues.”

“Again, we apologize for this incident and any inconvenience this causes.  We value your trust and we are committing all resources to resolving this incident quickly and completely, so we can get back to [insert mission statement or “what you do” here].

[Highest ranking person in your company]

No, I’m not kidding.  Your lawyer should not sign this for you.  Nor should your 3rd party data breach management company.  Not your PR firm, not the head of IT, and definitely not something cutesy like your mascot (even if your mascot is one of the cats in this blog post).  And for crying out loud, I don’t care how big and high profile you are, don’t have the President of the United States address the nation for you either.   

Before you send out this letter, run it by your public relations team/person, your general counsel/lawyer, your data breach response team, and your CEO, who as we discussed above will be signing the letter.    

Friday, June 5, 2015

Post OPM Breach...let the phishing begin!!

Hello again readers! As you may already know, last evening the Office of Personnel Management (OPM) admitted they sustained a data breach where they "lost 4 million records". In reality the number is probably much higher than that and the attack probably did not actually possess a "never before seen level of sophistication" or use a "previously unknown zero day attack" or any of the other "it is not our fault" mumbo jumbo that is usually seen after a data breach is admitted publicly. 

However, this blog post is not going to cover any of that, instead it is going to focus on two phishing emails I received last night that were possibly related to my own information being compromised in the breach, as my personal information is held by OPM as I was in the DoD (as a member of the US Air Force) and still currently hold a security clearance. (NOTE: I have not been notified that any of my information was compromised, and it could be completely unrelated. But...I mean....come on)

The phishing starts....

Last night I received two phishing emails that were related to "my Navy Federal Credit Union account". This is interesting because although I have indeed served in the military, I do not have any accounts with Navy Federal Credit Union at all. 

Two emails received from "Navy Federal"

The first email was received at 19:05:07 and the second was received at 19:53:17, so in less than an hour I had two phishing attempts. Once again, I cannot definitively say that it is related to the OPM breach, but the timing is suspect, to say the least.

Email 1: Your Account Statements is Now Avaliable

This was the first email that I received, with typical spelling errors and grammatical mistakes. As I have stated many times in the past, a "sophisticated" phishing email is one with no misspelled words or grammatical errors. This is clearly NOT in the sophisticated category. The link redirects to the domain "http://rudivervoort[.]be/SP/", which clearly does not seem to be legitimate for the Navy Federal Credit Union website. The email address is listed as "", which is also NOT the domain of Navy Federal Credit Union. UPDATE: The url in the email is now listed on virustotal as well!

Original email

Email with some grammar and spelling issues highlighted

Email header information

VirusTotal results from link in email

Email 2: Account Review Notice!

This email was sent later and is crafted a little bit better than the first. There are no spelling errors, although there are quite a few grammatical errors. Analysis of the email header shows it "originated" in the same Canadian IP addresses as the first phishing email, which may suggest they were related. The redirect link is a shortened URL, which should not happen in a legitimate email from your banking institution. In fact, the URL is shown on VirusTotal as malicious (already!). The email address this time around is listed as "". The first email address, in my opinion, was better.

Original email

Grammar highlighted

Email header information

VirusTotal results on link in email

Regardless of whether these emails are actually related to the OPM breach or not, it does highlight the importance of taking some safety precautions to avoid falling for phishing emails: 

  • Always ensure you read an email thoroughly. Look out for spelling and grammar issues; if it seems strange, it probably is
  • Hover over links before clicking on them
  • Better yet, do not click on ANY link from your bank, credit card company, shipping company, etc. Log into the website of your service provider directly if you get an "important message" from them

A very timely Dilbert comic strip. Retrieved June 5, 2015 from

Monday, April 13, 2015

Live Response Collection slides from Bsides Charm

Hello again readers! I had the pleasure of speaking about the Live Response Collection at the inaugural Bsides Charm event held this past weekend. I am working on getting some new features and functionality added to the next release which I hope to have available in the near future. As always, if you have any suggestions or comments to help improve the functionality or additional data that you would like to see collected, please do not hesitate to contact me!

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).

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)" (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 "". 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)

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 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 (""). 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 (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 ( 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.


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.