Be Very Quiet... I'm Tracking Emails Through Headers

That's right... I'm on the e-mail header hunt.  Or, more specifically, on the hunt for the juicy information e-mail headers can contain.

It all started when I was looking for digital forensics reports that I could direct attendees to in my upcoming PFIC lab on report writing.  While trolling the interwebs, I came across this little gem of a report from Stroz Friedberg.  One particularly interesting portion of the report deals specifically with e-mail headers.

E-mail headers and the information they contain have been covered pretty well by other writers, but I wanted to throw in my two cents because:  1) e-mail headers are artifacts of great value, 2) getting the information from headers does not require spending money on any additional software or equipment and 3) I think that, while the information they contain may sometimes be used, they do not always get the attention they deserve.

If there is one downside to e-mail headers, it is that they do require a bit of analysis to really get to the good stuff.  So, let's take a look at some actual e-mail headers to see what we can find. 

Tracing Digital Path Using IP Addresses

Below is an e-mail header from an e-mail I received from Mike Wilkinson.  Let's say that for this e-mail we wanted to track where it originated.  As e-mails pass through servers on the way to their destination, the servers stamp the e-mail with their IP.  We can then trace the location of the IPs and get an idea of the digital path taken.

(Emphasis Added, Parts Removed for Ease of Reading)

Delivered-To: girlunallocated@gmail.com

Received: by 10.76.87.135 with SMTP id ay7csp131395oab;

        Tue, 31 Jul 2012 17:20:49 -0700 (PDT)

Received: by 10.68.231.39 with SMTP id td7mr47731514pbc.3.1343780448825;

        Tue, 31 Jul 2012 17:20:48 -0700 (PDT)

Return-Path: <mike@writeblocked.org>

Received: from outbound-ss-1034.hostmonster.com (soproxy2.bluehost.com. [2605:dc00:100:2::c2])

        by mx.google.com with SMTP id ic1si3163202pbc.349.2012.07.31.17.20.46;

        Tue, 31 Jul 2012 17:20:47 -0700 (PDT)

Received: from unknown (HELO box371.bluehost.com) (69.89.31.171)

  by soproxy2.bluehost.com with SMTP; 31 Jul 2012 23:20:37 -0000

Received: from [76.19.81.128] (port=49558 helo=[192.168.1.2])

 by box371.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256)

 (Exim 4.76)

 (envelope-from <mike@writeblocked.org>)

 id 1SwMg2-0001Vs-EB

 for girlunallocated@gmail.com; Tue, 31 Jul 2012 18:20:45 -0600

Message-ID: <50187655.6090101@writeblocked.org>

Date: Tue, 31 Jul 2012 20:20:37 -0400

From: Mike Wilkinson <mike@writeblocked.org>

Organization: Champlain College

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

MIME-Version: 1.0

To: girlunallocated <girlunallocated@gmail.com>

Subject: Re: case experience

There is a lot of information to go through here, so let's narrow it down to just what we need to trace the locations.  First, find the "Received" lines.  These lines should be read from bottom to top, meaning that in this case, the IP address 76.19.81.128 was the first server IP the e-mail passed through.  So, according to  the header, this e-mail traveled here:

IP Address	76.19.81.128
Location	UNITED STATES, CONNECTICUT, DANBURY
Latitude, Longitude	41.39482, -73.45401 (41°23'41"W   -73°27'14"N)
Connection through	COMCAST CABLE COMMUNICATIONS INC.
Local Time	19 Oct, 2012 11:11 PM (UTC -04:00)
Net Speed	DSL
Area Code	203
IDD Code	1
ZIP Code	06810
Weather Station	DANBURY (USCT0046)
Mobile Country Code (MCC)	-
Mobile Network Code (MNC)	-
Carrier Name	-

IP Address	69.89.31.171
Location	UNITED STATES, CALIFORNIA, TEMECULA
Latitude, Longitude	33.49364, -117.14836 (33°29'37"W   -117°8'54"N)
Connection through	BLUEHOST INC.
Local Time	20 Oct, 2012 02:11 AM (UTC -07:00)
Net Speed	COMP
Area Code	909/951
IDD Code	1
ZIP Code	92589
Weather Station	TEMECULA (USCA1136)
Mobile Country Code (MCC)	-
Mobile Network Code (MNC)	-
Carrier Name	-

So, this e-mail went from Connecticut to California. (Mike, you check out.  I'm still watching you, though...)  This is a good way to verify that an e-mail is coming from where you expect it to come from, or to track down the origin of an unknown e-mail.  

Verifying Date and Time Stamps

Altering date and time stamps is a frequently used tactic in Fraud, not to mention many other circumstances that we may come across as DFIR examiners.  Interestingly enough, though it is fairly easy for someone with a bit of understanding to backdate an e-mail, e-mail headers once again can come to the rescue.  Remember the servers that so kindly added their IP addresses to the e-mail as it travels?  Turns out they will also add a timestamp - DFIR artifact gold.  

One of the common ways to backdate an e-mail is to simply change your computer date and time settings, and then send the e-mail on.  (Note that this only works if you are using a local e-mail client.  If you are using webmail or a server client, the date and time will be set to the date/time associated with that server, and not with the local machine.)  However, once the e-mail has been sent, the servers it passes through will stamp their own specific date and time to the e-mail - a process that is out of the end user's control.  

So, let's look at yet another header example:

(Emphasis Added, Parts Removed for Ease of Reading)

Delivered-To: girlunallocated@gmail.com

Received: by 10.76.120.77 with SMTP id la13csp206236oab;

        Fri, 19 Oct 2012 12:20:49 -0700 (PDT)

Received: by 10.68.189.233 with SMTP id gl9mr8451507pbc.166.1350674448698;

        Fri, 19 Oct 2012 12:20:48 -0700 (PDT)

Return-Path: <melia.kelley@fadv.com>

From: Melia Kelley <melia.kelley@fadv.com>

To: "Girl, Unallocated (girlunallocated@gmail.com)"

        <girlunallocated@gmail.com>

Subject: Important Information... Open Immediately

Thread-Topic: Important Information... Open Immediately

Thread-Index: Ac2gO44geRKB7e0RTXCl1+IiUD7jHA==

Date: Mon, 1 Oct 2012 19:20:38 +0000

As you can see, even though the "Date" of the e-mail has been changed, we can see see when it passed through servers - or at least the date and time those servers were set to when the e-mail passed through.  (Note that when dealing with multiple servers, you will need to take time zones into account, as it is entirely likely that there will be multiple time zones involved.)

Other Gems

There are many other nuggets of information that can be gleaned from e-mail headers.  For example, spoofed e-mails (i.e. e-mails appearing to be from somewhere they are not) can be identified by viewing the header.  If you can, take a look at different headers.  The information contained can vary widely, depending on the mail clients in question.  You may be surprised what you find.  Happy hunting!

EDIT - Disclaimer:  Thanks to those who pointed out that we should take certain information with a grain of salt.  Just like any DFIR artifact, the data is only good as long as it can be trusted.  It is possible to falsify information in e-mail headers.  As always, make sure you look at the full picture!

Some Thoughts on "Secret Sauce"

There was a lot of interesting information exchanged at the SANS DFIR Summit, but one of the phrases that I keep returning to in my mind was one used by Chris Pogue during a question posed in his "Sniper Forensics" class.  Chris posited, quite rightly, that companies are loathe to share their "secret sauce".  As much as we as individuals are a community, we can't overlook the fact that many of us are employed by competitive businesses.  And for those of us that have worked IP Theft cases, it is obvious that Intellectual Property is a Big Deal.

That's quite some Catch-22.  The community as a whole needs people who willing to share, but people in the community by virtue of being employed in the field, can't share the "secret sauce".  What to do?


I think that at least part of the answer is easier than we are making it out to be.  Many people recognize the necessity of a company holding on to its own intellectual property.  But what actually constitutes "secret sauce"?  Could there be information to be shared that benefits the community while not harming, or perhaps even helping, DFIR employers?  I would argue that the items discussed below fall into this category:


Testing Results of Industry Tools
Tools are an important part of any examination.  While examiners should be aware of how data is stored natively, parsing vast amounts information without an automated process would be patently silly.  Simply stated, we need tools.  And sticking with just one tool can be detrimental since I know of no single tool that does everything needed for a complete exam.  The answer is to have a robust toolkit.  
Testing of your tools should be par for the course for an examiner, but with such a wide range tools and data sets, the chances are high that testing cannot be done on every scenario.  This is where having a community all testing and running tools can be a great benefit.  A group of people running tests in different environments and with different data sets will cover far more ground than any one individual.  The trick here is that it needs to be shared in order for us all to reap the rewards.
But how does an employer benefit in this scenario?  Beyond getting a more robust toolkit for their DFIR teams, having tools well known and accepted in the community can help with testifying experts on the stand.  And most companies I know like the idea of getting a good, respected product especially if it is easier on the wallet.

Industry Research

It isn't news that our field changes rapidly.  And staying up on the newest artifacts, data repositories, and gadgets is quite a daunting task, even for a whole community.  Some of the biggest DFIR advancements made in recent years came from people down in the trenches who starting looking into something, and then shared their results.  I honestly believe that the sharing of individual research is vital to keep our field moving forward.
But how does this sharing benefit an employer?  One way, is that by having employees share knowledge, they can establish themselves as subject matter experts.  The value of a name (either personal or company) attached to research can be invaluable.

Okay, so now that I've detailed what I think isn't "secret sauce", is there anything left over that is?  Certainly there is.  The steps of a highly planned, orchestrated team approach could be one example.  Even a template could be considered another.  But even if these are examples of "secret sauce", it's the details that make them so, not the fact that they exist.  Recommending to the community that they create their own versions, without necessarily giving out yours, is yet another way of sharing.  (A perfect example of this is the "Sniper Forensics" presentation by Chris Pogue I mentioned earlier.)

But this is just the ramblings of one person out of many.  What are your thoughts on "secret sauce" and what it is or isn't?  Please share the ingredients to make our own community non-classified sauce.

Austin and DFIRSummit and 408, Oh My!

It's been a while since posting, but that is because I have been through a whirlwind of Digital Forensic goodness down in the furiously hot, furiously fun Austin, TX.  My time in Austin was lengthened because I was lucky enough to be a part of both a class and the Summit itself.  This post is extra long in an attempt to catch up with all the DFIR experiences down in Austin...

SANS FOR408

SANS classes have long been the holy grail of DFIR training in my mind, so I was immensely excited to be chosen to be a facilitator for the FOR408 class.  When approaching my boss about going, he did raise some concerns that the 408 class could be a bit elementary.  As he pointed out, perhaps rightly, I already have multiple certifications under my belt and am not new to the field.  (Training is highly valued, as long as the training constitutes new material.)  To his credit, my protestations that it would be of value were listened to and I signed up for the epic 10 day journey to the SANS FOR408 and DFIR Summit.

The SANS FOR408 class consists of six days in which everything from the basics of imaging to gleaning data out of important artifacts are covered.  Hands-on experience is a large portion of the class, and each day had the participants actually trying out equipment or software.  The experience level of the participants varied from those almost brand new to the field to those that had years of experience.  And as the class moved forward each day, it was clear that people of all experience and skill levels were getting information of immense value.  While I was glad I had the knowledge that allowed me to step up as the facilitator to answer some questions, I was amazed at how much I did learn.  Yes, I would like to think of myself as someone who stays up on much of the new tools available to the DFIR community, and who tries to stay abreast of new artifacts.  But each day I came away with multiple new tools or tracks of analysis.  Honestly, the Windows SIFT Workstation itself is worth its weight in gold.

Yep, I have one of these!
I've wanted one for so long -
it's still a huge thrill.

Our instructor mentioned a few times that the goal of this class was to train people beyond "push button forensics."  This idea was brought home on the final day when we did the Challenge.  For those who are not familiar with the Challenge, it involves an image, a scenario, and the trial of performing a digital forensic exam in few precious hours.  The digital evidence in the Challenge is well put together, and does a fantastic job of demonstrating how much evidence of potential value is found outside of the larger forensics suites.  I was lucky enough to be able to not only participate in the challenge, but to have a fantastic group working with me.  After performing the exam and putting together a (kick-a$#!) presentation, my group was voted as the winners of the challenge.

Recommendations:  Okay, coming up with recommendations is awfully hard for a class of this caliber.  But in an effort to show people that I really am trying to approach this objectively*, I thought I'd include a few recommendations.  Tell your instructors to boss around the facilitators.  Seriously, Chad, I wanted to give you water and cookies**!  The first day was one where those who had more experience in the field had less to learn.  I'm not even sure if this is possible, but having a bunch of different laptops/desktops, etc with different ways of getting to the drives could be a fun way of having people get that coveted "hands on" experience.  If I've learned anything from collections, it's that no two are the same.  And the problem solving we use on pulling digital evidence could work as well toward the problem solving of getting to a hard drive***.

*Note:  You can still be objective and still ABSOLUTELY love something.
**  Okay, kidding.  Chad was wonderful.  He shouldn't have changed anything.  He's just so nice, at one point I think he asked if he could get me cookies.  Sheesh!  There goes my chance at pretending this was "Devil-Forensicator Wears Prada."
*** To be fair, it was mentioned multiple times that this step should be done at home, so it probably shouldn't even be included in my recommendations.  I'm trying to find something here!  It really was fabulous.

OMG!  It's Hal and Cindy!

SANS Summit

The Summit.  Where should I even begin?  I well remember just last year watching the live feed and following Twitter with envy, and then this year I got to experience it for myself.  There have already been many a blog post here, here, here and here about what it was like and some of the content shared.  (And even now I know I am missing many.)  I have been to a couple of DF/IR conferences before, but this was far and away the one where I felt the biggest sense of community.  From book authors to blog writers, many of the people who have helped me on the path to becoming a better analyst were there.  It was a pleasure to not only learn from, but meet and mingle with these great minds.  (Note:  my reaction is captured to the right)  

A huge thanks goes out to Rob Lee and SANS for putting together such a great event.  As a facilitator, I was able to glimpse just a portion of the work that goes into an event like this, and I am overwhelmed by the dedication and exertion necessary.  Here's to an event just a good, if not better (if that is even possible!), next year!

An Open Source Testing Guide for My SANS360 Talk

This is it... the final sneak peek before my debut in the SANS360 at the DFIR Summit in Austin.  Last week, I shared the Report Writing Guidelines included in the talk, and today I am happy to share a quick graphic relating to the testing of Open Source tools.

As investigators in the DFIR field, FOSS tools can become a very important part of our analysis tool kits.  But perhaps just as essential as learning and utilizing new tools is the ability and time investment to really understand what it is that they do.  Not only will this allow us to increase the efficiency of our exams, it also can help with the never-ending journey of discovery that we, and all of the DFIR community, are on.

I am planning to extend various parts of this graphic in future.  If you have any suggestions for improvements (and I know there are a lot that could be made!) please feel free to e-mail me.

Also, for your viewing pleasure, here is a sneak peek at FE as she gears up for her journey to The Wonderful World of FOSS:

Summer is Coming...

Like the Starks, my new motto revolves around the coming season:  Summer is Coming.  In fact, tomorrow marks the beginning of one of my most anticipated months of the year.  In mere weeks, I will be journeying to Austin for none other than the legendary DFIR Summit.  I get to facilitate FOR408, practice my camera face for the 4Cast Awards (What do you mean E! won't be there?), and even participate in the SANS 360.

Gleeda the Good Owl -
One of the helpful guides

You would think that talking for six minutes would be fairly easy for someone who enjoys talking as much as I do, but it is actually turning out to be quite the challenge.  Inspired by Jesse Kornblum's excellent DFIROnline presentation on storytelling, I've decided to attempt to tell a story - complete with illustrations (drawn by my amazing sister, Noelle Pettit Martin).  A few industry personalities may be making an appearance (see Gleeda the Good Owl left) to help the protagonist on her way to deeper DFIR understanding.  But before I go making people wonder why on earth I was invited to speak in the first place, let me reassure you that, somewhere in the parables and powerpoint, I will include what I hope are some useful tips and thoughts.

One such tip is that an examination isn't complete until it is communicated.  Below is a basic workflow to show how I break out my reports.  As always, this doesn't cover every eventuality, and merely shows what I myself do.

This can be used in conjunction with an article I wrote for the upcoming DFI News edition called "Report Writing"... check it out!

Let me know if you are coming to Austin.  I look forward to meeting many of the people I have gotten to know online.  Prepare yourselves... Summer DFIR is Coming!