(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

March 26, 2019 8

How to read an Email Header

in Hashing Out Cyber Security

Not sure if an email is legitimate? Check the email header!

Hey friends! There is some unfinished business in my blog series about email security and verification. This topic was considered during that timeframe but seemed to be too technical. However, in recent times, there has been some need to review and explain what and why to some co-workers, so I figure I’ll write an article that all my co-workers will read with vigor and retain the information I’m trying to convey.

The topic? Email headers. The reason? Further identification of spam and phishing attacks. It also is extremely important for one recommendation that I have mentioned on a few different occasions: Scrutinize. Always report. Jump through the hoops. Stop the bad guys. Slay the dragon. Profit (Queue Steve Nash).

Email headers are sort of the paper trail (and more) that is attached to each email and shows the actual source, hops and how it ended. It also has certain things such as ‘Return Path’, Spam Score, DKIM Public signature, and various other tidbits. We’ll go over most of it, but the takeaway should be to have further confidence if email is spam or legitimate and the path it took to get to you. Let us hash this particular topic out.

Components of Email Headers

Email headers contain a lot of information and not just necessarily the logistical audit of who and how the email made it to the end user. Although, that information is very useful and provides insight into origin, path and potential security processes.

Some of the other things one may see in an email header:

• Spam identification scores and thresholds to flag emails as spam which allow client spam filters to easily sort bad emails out of users’ inboxes.
• There are fields that indicate a ‘Return Path’ which is essentially a bounce back address. Often, the return path is the sender’s email but it might make sense to have an email that will collect bounces and do something if there is high volume.
• DKIM public key and results are also found right in the email headers which indicate if there was a pass/fail. What happens to a failed (or soft fail) message depends on the policy action set in the DNS record (See previous post about DKIM).
• Some common information can also be found such as date/timestamps, MIME types, version, email format (HTML, plaintext), etc.

Dissecting a (Phishing) Email Header

Now that we have an idea of what an email header may or may not contain, let us now look at a bad email header and some of the flags that indicate it is, uh, bad.

So, this phishing email was found in my email client’s junk folder as it should be. I have moved it to my inbox to show what it would like in an inbox. By default, any email in my junk box is converted to plain text, so, I wanted to show the ripped off graphic that can be seen with HTML.

I’d also like to point out that not all mail comes from a Microsoft Exchange Server/Environment. Many do and while some of the stuff we’ll look at will be specific, other indicators and header information might come through regardless of the mail processing platform.

Suspicious from the get-go. I didn’t even have to look at the email headers to determine (obviously, because the email got flagged and the spam filter moved it out). But, let’s take a look at the email headers and see what makes this email so bad:

One thing to point out immediately is that we kinda need to read the header information upside down. That is, you start on the upsidedown (shout out to Stranger Things) and work your way to the top.

Much of what we’ll see is mail exchanges (relays) that simply help pass the message along but does no real scrutinization.

Look. The next few pages are arduous. This is kind of the last exit warning sign before a long bridge. But, instead of turning back, you can move forward, skip these next few pages and there is a good summary of which lines of the header to look at that will almost always help you scrutinize accurately.

Each line is numbered for easier reference.

• Line 61: The value for ‘AuthAs’ is listed as ‘Anonymous’. Right here, this is a flag. We should be looking out for a value as ‘Internal’, ‘External’ or ‘Partner’. According to Microsoft, “If X-MS-Exchange-Organization-AuthAs is listed as “anonymous” or if it’s missing, this indicates an incorrect configuration or an incorrect mail route.”
• Line 60: ‘AuthSource’ is the server that checked the authentication of the email for the email domain.  I happen to know that domain = ‘mlsrvr.com’ is of RackSpace which is an email service provider.
• Line 59: ‘Organization-SCL’ is the Spam Confidence Level (hence, SCL) is how that ‘AuthSource’ grades the message as spam. The scale is 0, which is clean, and 9, which is bad. Basically, this is a very computer-y way of saying 1-10. The value here is ‘5’.  Doing the math, er, basic counting, this errs to the side of bad. It is certainly not absolute or nearing absolute, but it is certainly leaning to bad. In my mind, this is a flag. Note: a value of -1 means that it was not analyzed here because the value of ‘AuthAs’ was ‘Internal’. This could certainly be considered a flaw that would be very difficult to exploit.
• Line 57 – 58: This is a combo line that just states the method of the AV scanning on the server side. Standard and nothing indicative here.
• Line 56: The ‘Network-Message-ID’ is a unique hash that sort of serializes the message. Standard and nothing indicative here.
• Line 55: Here’s a flag, alright. Simply labeled ‘To’, the value here is ‘Undisclosed recipients:;’ That means the destination fields, ‘To’, ‘CC’, and ‘BCC’ have been gamed. For example, it can be done through GMail by typing ‘Undisclosed Recipients <emailaddress@emaildomain.com>’. The email was supposedly sent from Rackspace, a legitimate business, and they just don’t do that. This smells bad. If I didn’t already know better, I’m already questioning this.
• Line 54: ‘X-Mailer’ is indicating what method was used to send the email. The value is listed as ‘Webmail/16.2.0-RC’. This is a little phishy in that RackSpace would likely not use WebMail to send the message as they are a mail service and have access to the “cleaner” backend of Exchange. Not a huge indicator typically but considering this is supposedly from RackSpace, it can be rightly scrutinized.
• Line 53: ‘Message-ID’ is some unique hash from RackSpace. Nothing here.
• Line 52: ‘Type’ is the format of the message. Most messages are HTML. This is fine.
• Line 51: ‘Priority’ is just that: priority of message to be processed based on the mail service. Value of ‘3 (Normal)’ is, you guessed it, normal and standard. Nothing to see here. Moving along.
• Line 50: ‘Importance’ is a flag set on the user end. It indicates if an email is of high or low importance. Nothing here detracts from the legitimacy of the message.
• Line 48-49: ‘Content-Type’ specifies the kind of content that can be found in an email message. Many emails have the combination of HTML, Text, Image attachments, etc. Many emails have this combination of things so I would say that this is non-indicative.
• Line 47: ‘MIME-Version’ has a value of ‘1.0’. Basically, indicates that the message was created in compliance with the standardized “email structure”. Also, clean.
• Line 46: The value of the ‘From’ field here is quite indicative. The email address is listed as ‘noreply@mailbox-services.com’. A quick search on MXToolBox shows that RackSpace has no affiliation with that email domain. This is a red flag for me.
• Line 45: ‘Subject’ can certainly be indicative. We’re looking for misspellings and bad grammar that most legitimate companies are very capable of keeping that clean. The subject here is a little wordy for a warning. I’m giving this verbiage, “We noticed an unusual sign in attempt from an unknown location”, a warning going on red flag.
• Line 44: ‘Date’ and timestamp is pretty straightforward. Nothing here.
• Line 43: ‘X-Auth-ID’ is a big one here. This field is stating the authentication ID for the email account. I almost always look for values like this (and/or ‘Return Path’ which is often the same address and/or ‘X-Sender-ID’ which is probably the most telling field) to tell me if this is a legitimate email. The value, ‘mbabauta@ibssguam.com’, screams fake. I took this a step further and looked up the domain of ‘ibssguam.com’. Just so you know, the site seems legit though it is literally a company based in Guam. This tells me that their account was hacked and is being used to send spam (poor Island Business Systems & Supplies of Guam….) In a real-world application, this ends my investigation. That’s about as much proof as I need. Reddest of red flags.
• Line 40-42: ‘Received By’ is where the actual path starts being laid out. All the information before this is basically received/recorded/generated from this first ‘hop’. The value is ‘apps.rackspace.com’ which, as mentioned earlier, is Rackspace’s webmail address. The other values, on line 41, just reiterates the authenticated user and the from user. This also indicated a red flag, so it is telling.
• Line 37-39: ‘Received From’ is kind of the extension of the previous line block. It also shows that ‘user from’ is of poor IBSSGuam email address. We know this is a red flag.
• Line 34-36: ‘Received From’ here indicates a relay in the value field. This does not immediately jump out at me considering we are not sure of the path and it could potentially change depending on many factors of general internet routing.
• Line 33: Much like line 43, this is what I am looking for. This is often the first thing I look for as this is all telling and basically seals the deal for me. The reason why this is more important is because this is the actual sending email address and not just the authentication that is seen on line 43. So, the display name for email might say ‘RackSpace Support’ but this field is hard (not impossible to spoof) and is not done often enough. For instance, it was not done here! Much like the value found in line 43, this is about as much proof as I need. Redder than the reddest of red flags (AKA bad).
• Line 30 – 32: See info for line 34-36. This is for the outbound (SMTP), though. But the same principle can be applied. We don’t know the route. It can be traced but there is a lot of work that would have to go into that.
• Line 27 – 29: See previous. Same thing (SMTP, too).
• Line 23 – 26: See previous which makes you see previous heh. There is some added transport encryption information that doesn’t mean much to anyone at a glance.
• Line 22: ‘Classification-ID’ is a random hash and this is another unsuspecting value. This does nothing for our scrutinization.
• Line 21: ‘Suspicious-Flag’ is set to ‘No’ as the value. I am not sure what causes this flag to be set to ‘Yes’. But, I would have. With all its suspicion just suspicioning around….
• Line 18 – 20: This is a very telling few lines right here. Welcome in our old friends SPF, DKIM, and DMARC. The MailFrom is still from our other friends selling printers in Guam. There are no DKIM signatures, no DMARC and the SPF is ‘Neutral’ which means there is referencing from the same domain as the receiver. In other words, the sending domain is in the same domain as the receiving domain (emailsrvr.com). My street smarts would tell me that if Rackspace were to send an email, they would pass SPF, DKIM and DMARC. Kinda important for them considering they do lots of email hosting. Red Flag.
• Line 17: ‘Originating-IP’ can be telling if you do the research but at a glance, it doesn’t mean much. I’d be more interested in some of the other fields that were mentioned in the previous lines. At a glance, this is a fine. Note: For the record, this IP is from RackSpace so this would favor a “clean” message despite it being a, well, you know.
• Line 16: ‘Orig-To’ is the destination email address. Nothing wrong here.
• Line 15: ‘Virus-Scanned’ is referring to the email server scanning for a virus. The value of the filed is ‘OK’. There was no real virus on the email, per se, but I wouldn’t click on the link. That would seemingly be a digital petri dish of bad.
• Line 14: ‘Spam-Flag’ is set to value ‘YES’. Boom. This field though makes a bit more sense by looking at the next few fields. Seemingly, this section would be best read in a different order. Red flag.
• Line 13: ‘Precedence’ has value ‘junk’. It’s junk, aright. Right on the nose.
• Line 12: ‘Spam-Score’ has a value of ‘100’. That is on a scale of 1 – 100. Guess which end is bad?
• Line 11: ‘Spam-Threshold’ is basically the score that must be met in order for an email to be flagged as Spam. The value is set to ‘95’. I’m no mathematician but I’m 95% sure that 100 > 95. Threshold met. ‘Spam-Flag’ is set to ‘YES’.
• Line 10: ‘Return-Path’ is a big one for me. Maybe one of the biggest flags, in my opinion. The ‘Return-Path’ is an email address that will is also called a ‘Bounce-Address.’ When an email address gets bounced, this is the email address that the bounce goes to. More often than not, this is the same address as the sender email address. So, here, we have that same sender address value which is mbabauta@ibssguam.com. This is telling to me.
• Line 1 – 9: I’m condensing the last 9 lines into this last one which is basically 3 hops. Basically, from Rackspace and back to Rackspace. Nothing weird here.

ZZZZZZZZ…. Huh?! I’m Awake. I’m Awake….

Whew. We made it through. Look at all that red. A clean message will have very, very little if at all red. Let’s examine a clean message’s headers. Kidding.

The main point of this is that someone should be able to look at 1 or 2 things within an email’s headers and have a really good idea if there is shadiness surrounding an email.

The ‘Return-Path’, line 10, as mentioned, is a big one to me. Since it can be spoofed, it is not fool-proof. Often times, it is not spoofed so that is very indicative. In a sense, this can show the true originating email address. There are other fields that may indicate the true email address, such as the authentication, and that can appear different. Certainly, the display name can be spoofed so that should almost never be considered when starting the scrutinizing process.

Also, the results from things like SPF, DKIM and DMARC, line 18 – 20 is very telling. It all depends on the context. Seemingly, a legitimate entity will have their email security and verification processes tuned up so if there is failure or none at all, that is a red flag.

Finally, the spam flag and spam score, lines 14 and 12 respectively, is also a big indicator. This can and has produced false positives so I will often look at the other signs in order to determine an email’s legitimacy.

There a lot of other possible fields that one could find in an email header. So may be indicative and others may just be some metadata-ish type information that just help with organizing/tracing.

Finally, and as I have said over and over, and even wrote a post about it, use your best judgement. Understand your contacts, look for the obvious stuff, question any and all information that anyone is asking for. Businesses WILL NOT ask for certain sensitive information via email. Keep an eye out for other email header fields, try to understand the context and, of course, Happy Scrutinizing!

• #Email Security