Analyzing a Forged Email Message: How to Tell It Was Forged?
In our previous posting, we looked at exactly how Spammers and hackers can send forged email — how its is possible and how it is done. Therein, we gave an example how one could send an email forged to be from Bank of America.
In this post, we will look at that forged Bank of America email to see technically what it looks like and how it differs from legitimate email from Bank of America.
What can we learn that allows us to detect forged email in the future?
The Forgery: Received.
The forged email from Bank of America was based on a legitimate email message, so that the forgery could look as close as possible to actual email from them.
In truth, the majority of forged email simply changes the “From” address and does not bother with anything else. These forged messages are used for Spam and hope the forgery fools enough people to be worth it, through numbers. What we are looking at here is a more carefully crafted message designed to fool filters and a careful eye. These kinds of fakes might be used in spear phishing attacks on an individual or in more sophisticated Spam campaigns.
The the forged Bank of America email that arrived in the recipient’s mail box looked like this (the raw headers):
Received: via dmail-2010.19 for +INBOX; Thu, 5 Feb 2015 10:33:28 -0500 (EST) Received: from rs302.luxsci.com ([10.208.101.210]) by rs145.luxsci.com (8.14.4/8.13.8) with ESMTP id t15FXRxh018470 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=128 verify=NOT) for <xxxxx@rs145.luxsci.com>; Thu, 5 Feb 2015 10:33:27 -0500 Received: from rs302.luxsci.com (localhost.localdomain [127.0.0.1]) by rs302.luxsci.com (8.14.4/8.13.8) with ESMTP id t15FXRrH031568 for <xxxxx@rs145.luxsci.com>; Thu, 5 Feb 2015 15:33:27 GMT Received: (from mail@localhost) by rs302.luxsci.com (8.14.4/8.13.8/Submit) id t15FXRUB031563 for XXXXX@rs145.luxsci.com; Thu, 5 Feb 2015 15:33:27 GMT Return-Path: <onlinebanking@ealerts.bankofamerica.com> Received: from ealerts.bankofamerica.com (static-71-174-64-40.bstnma.fios.verizon.net [71.174.64.40]) by rs302.luxsci.com (8.14.4/8.13.8) with ESMTP id t15FVnRD023664 for testuser@luxsci.net; Thu, 5 Feb 2015 15:32:39 GMT Date: Thu, 5 Feb 2015 15:31:49 GMT Received: by mta5.ealerts.bankofamerica.com id hqdcek163bnq for <testuser@luxsci.net>; Thu, 5 Feb 2015 05:49:51 -0600 (envelope-from <bounce-73720-2685168@bounce.ealerts.bankofamerica.com>) From: "Bank of America" <onlinebanking@ealerts.bankofamerica.com> Reply-To: "Bank of America" <reply-73720-8976789@ealerts.bankofamerica.com> Message-ID: <af68828a-6c81-5896-b43d-8583607bdf99@xtnvs5mta406.xt.local> Subject: Alert! You Bank of America account has been compromised To: testuser@luxsci.net X-Lux-Processed-For: <testuser@luxsci.net> X-Lux-Ruleset: #YYYYY on rs302.luxsci.com X-Lux-Envelope-Recipient: testuser@luxsci.net X-Lux-SAHITS: DKIM_ADSP_DISCARD,SPF_HELO_FAIL X-Lux-Rule: Deliver X-Lux-Delivered-To: "INBOX"Body
Analyzing the Forgery
We have color coded the headers from the received forgery to help us visually see where the parts came from:
- The BLACK lines were provided by the hacker. These could contain anything and cannot be trusted. E.g. headers like “From”, “Reply-To”, “Subject”, “Message-ID”, “date”, “Return-Path” and even all “Received” headers added before the message arrived at your inbound email servers are completely suspect.
- The BLUE lines were added by the LuxSci inbound email processing servers (and are analogous to lines that would be added by any other email processing system). These include: additional “Received” lines, tracking lines, Spam filtering results lines, etc. A clever hacker may try to inject additional header lines that look like ones that your mailing system would normally add (e.g. Spam Filtering success headers, etc.)
- The RED lines are more subtle efforts at forgery; we will look at these next.
Subtle Forgery: Trying to Fake the Mail Delivery Path
First, you must understand that the “Received” lines are added by all servers and interactions in the path sending, processing, and delivering a message. They are important for identifying what servers touched the message when and how (e.g. was TLS used? Who was it for? etc.) As each new server in the mail delivery pathway “does its thing,” it adds more Received headers on (to the top of the message), leaving any existing ones “as is”.
There is no way to know if any “Received” headers already present in the message are legitimate or not.
In this example, the hacker added a FAKE received line that was poached from a real message from Bank of America (with slight tweaks to make it not identical).
Received: by mta5.ealerts.bankofamerica.com id hqdcek163bnq for <testuser@luxsci.net>;
Thu, 5 Feb 2015 05:49:51 -0600 (envelope-from
<bounce-73720-2685168@bounce.ealerts.bankofamerica.com>)
The purpose of this FAKE Received line is to make everyone believe that the message originated from the real Bank of America server “mta5.ealerts.bankofamerica.com“. Indeed, this header looks exactly like a legitimate one — there is no way for the recipient to differentiate.
The next header that has red is the one that records the receipt of this message by the recipient’s server from the hacker. E.g. the first Received header the recipient’s servers added themselves and the first one that we can be sure is not lying. It says:
Received: from ealerts.bankofamerica.com (static-71-174-64-40.bstnma.fios.verizon.net [71.174.64.40])
by rs302.luxsci.com (8.14.4/8.13.8) with ESMTP id t15FVnRD023664
for testuser@luxsci.net; Thu, 5 Feb 2015 15:32:39 GMT
To break this apart:
- The message was received by the server “rs302.luxsci.com” at LuxSci
- The message was for testuser@luxsci.net (based on the “envelope to” … the recipient address specified in the SMTP dialog — which could be different from the “To” and “Cc” addresses in the headers).
- The ID code t15FVnRD023664 was assigned to the message for tracking on LuxSci
- The message was received on: Thu, 5 Feb 2015 15:32:39 GMT
- A computer at IP Address 71.174.64.40 (which appears to have the name (based on reverse DNS) static-71-174-64-40.bstnma.fios.verizon.net delivered the message TO rs302.luxsci.com
- That computer said its name was ealerts.bankofamerica.com
Everything here is real and verifiable except for the name that the hacker’s computer was pretending to be (in the HELO or EHLO SMTP command). In this case, s/he was still pretending to be Bank of America — the same server as that in the FAKE Received header.
However, the hacker cannot forge the IP address that s/he is coming from. In this case that IP address, 71.174.64.40, appears to be used by a Verizon FIOS customer (it was mime at the time, actually, because I did that test). This is clearly NOT this IP address of ealerts.bankofamerica.com.
In fact, this is the only part of the headers in the received, forged email message that one can point to to say: “That looks wrong“. That doesn’t really give us a lot to work with!
You Can’t Forge The Sender’s IP Address
Unless the hacker has infiltrated Bank of America’s servers, s/he cannot send a forged email message that actually comes from any of Bank of America’s server’s IP Addresses. We can always identify the IP Address of the server delivering an email message. Everything else in the headers can be fabricated, replayed, and look completely legitimate (at least to the degree that the hacker did his/her homework).
What are Your Defenses?
In the next article, we will look at SPF (Sender Policy Framework) to see how it is used to combat forged email by allowing domain owners to specify what servers are allowed to send email on their behalf. We’ll also look at the limitations of SPF and how those can allow forged email to slip through anyway. We’ll follow that with an analysis of further escalations to the war against forged email (e.g. DKIM, DMARC, other encryption methods, and closed systems).
Read Next: Stopping Forged Email 1: SPF to the Rescue
