Friday, October 19, 2012

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
http://www.ip2location.com/images/flags/us.png 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
http://www.ip2location.com/images/flags/us.png 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!

7 comments:

  1. Hi Girl, Unallocated!

    Wow. I just reallized and was humbled to see my blog added to your sidebar list. How cool is that! I hope you enjoy some of the posts!

    Anyway, I'm also quite interested in finding how additional information can be gathered out of emails in foresic investigations; e-mail headers, hidden tags and code components when folks copy/paste content in one word-processing document into an HTML-supporting email client, etc. Google Gmail is a real pain in not providing as much tansparently-helpful header info as some other email providers do.

    This post and the linked PDF report reminded me of another fantastic email-related forenesic report I saw and took a lot away from back in a January 2010 Grand Stream Dreams blog post.

    You might find it supplements the content in this post very nicely...if you haven't already found it.

    I've posted the relevant snippet from my orignal post below.

    A recent Digital Forensics Case Leads post has mention of a super-fantastic investigation/forensic report involving anonymous emails. This is must-read material, not just in terms of the investigative methodology but also the way the report was composed and presented. Very clearly done! I’m keeping a saved copy of the report for future reference; both technically and as a report template. From the post via the link above:

    University of Illinois recently released a detailed investigation report (PDF) regarding anonymous emails allegedly sent by its Chief of Staff to the University's Senates Conference. The report is an interesting read, and also serves as a potentially useful model for those looking for report samples and templates.

    Cheers!

    --Claus V.

    ReplyDelete
    Replies
    1. Claus,

      Sheesh, I'm thrilled you read my blog! The investigation report is definitely interesting. I hadn't read that specific post before (I started reading your stuff a bit after that one went live... lesson to me to go back and read older posts on good blogs!), and it has tons of good stuff.

      Readers: if you are interested in e-mail headers, I highly, highly recommend reading Claus' work. Very, very useful.

      GU

      Delete
  2. Great post, Melia! I'm going to make this post a reading assignment for a class I'm teaching this semester.
    Also, Claus and Melia, you both have excellent blogs. I greatly enjoy and learn from both.

    Ken

    ReplyDelete
    Replies
    1. You mean my writing will be foisted upon young minds? You, my friend, have a devious streak. :)

      Always good to hear from you!

      Delete
  3. Nice one, GU! I've been using email header information quite a bit in recent investigations.

    Forensic examiners should be cautioned that email headers are easily forged. You can't necessarily trust that chain of "Received:" headers to be giving you accurate information (at least prior to that email reaching infrastructure that you control and can validate). This is especially true for malicious emails like phishing campaigns.

    That being said, one of the things that I find valuable in email headers (other than the good stuff mentioned in the blog posting) is historical DNS resolution information. Mail servers generally do reverse DNS lookups to get the host name of the remote sending server based on its IP address and stick that information into the header. This data will tell you what name that IP address was resolving to at the time the email was received, which can be historical gold if the mail message is more than a few months old.

    For more details on how to read email headers (and detect forged emails), you might want to check out my "Demystifying Sendmail" book (http://www.deer-run.com/~hal/dns-sendmail/Demystifying-Sendmail.pdf), particularly pages 127-133.

    ReplyDelete
    Replies
    1. Hal,

      Thanks... I haven't ready that book yet! I will definitely go check it out.

      It is a good point to mention that headers, like any artifact, are only good as far as they are trusted to be accurate. Thanks for the reminder.

      Delete