How can Spammers and Hackers Send Forged Email?
Everyone has seen spam messages arrive with a “From” address that is your own address, a colleague’s, a friends, or that of some company that you work with or use. These From addresses are forged to help the messages (a) get by your spam filters, and (b) get by your “eyeball filters”.
But how are these folks “allowed” to do that?
When email was first developed, there was no concept of the need for security; protections against identity theft and forgery were not part of the plan. As a result, it is actually trivial for one to send an email with a forged “From” address and even some forged “Received” tracking lines by just connecting to your target’s email server and telling it whatever you want.
Let’s try to send an email to the address “firstname.lastname@example.org” pretending to be from “Bank of America”. The purpose of this exercise is not to teach you how to send forged email so much (this is not a new technique) as to set the stage for understanding how to detect and combat these kinds of messages.
Step 1: Get an example message from Bank of America
In order to send a compelling forged email message, we need an example of a message that came from the source that you are trying to forge … so you can make your message “look like” a typical message that they send (e.g. in terms of the subject, content, wording and grammar, images, etc.). We are not going to consider the message subject or content in this article. Instead, we are concerned with the headers … the part of the message that identifies who sent it, who it is to, and what path it took over the Internet.
Taking an example message from Bank of America, and looking at the headers, I see (this excerpt of interesting headers):
Return-Path: <email@example.com> Received: from unknown [22.214.171.124] (EHLO mta5.ealerts.bankofamerica.com) by p02c12m115.mxlogic.net(mxl_mta-8.2.0-3) over TLS secured channel with ESMTP id 9e853d45.0.105970.00-2374.168431.p02c12m115.mxlogic.net (envelope-from <firstname.lastname@example.org>); Thu, 05 Feb 2015 04:50:03 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=200608; d=ealerts.bankofamerica.com; h=From:To:Subject:Date:MIME-Version:Reply-To:Message-ID:Content-Type; email@example.com; bh=YhJz6l84RyMXW/utiX0auH/xtTQ=; b=Dzp0SVPypvq8X0VHConCJLSIYwL23EbgP8VxN4qK765Y57++HbhTQDjaXWc0sFjV7BV6/Np3DD3E dYHiIoxpzSy1GHvwvIDaG0+md1ijOmDwsBgFpE70upc+9WVHaNOYXjWxkO1tsgdfjEeJprcK93Wx Oc5xp60eg3MRnIvLC3A= Received: by mta5.ealerts.bankofamerica.com id hqdcek163hsp for <recipient@actual_domain>; Thu, 5 Feb 2015 05:49:51 -0600 (envelope-from <firstname.lastname@example.org>) From: "Bank of America" <email@example.com> Reply-To: "Bank of America" <firstname.lastname@example.org> Message-ID: <email@example.com>
We see from this example, typical From addresses, Reply-to addresses, “Return Path” addresses (for bounces), Message-ID formats, that they use DKIM, and an example of a server at Bank of America that talked to our server to deliver the message.
For items that look like unique IDs (e.g. the Message-ID, Return-Path), the Hacker would use a slightly altered but similar one. S/he would use the same from address, omit the DKIM signature, and possibly use some fake “Received” lines to make the message appear to come from Bank of America’s servers.
Step 2: The Forged Message
Using this information, the Hacker would construct a forged message to be similar to this one. I highlighted in RED things I changed and in BLUE, things I added new:
Return-Path: <firstname.lastname@example.org> Received: by mta5.ealerts.bankofamerica.com id hqdcek163bnq for <email@example.com>; Thu, 5 Feb 2015 10:25:15 -0600 (envelope-from <firstname.lastname@example.org>) From: "Bank of America" <email@example.com> Reply-To: "Bank of America" <firstname.lastname@example.org>Message-ID: <email@example.com> Subject: Alert! You Bank of America account has been compromised To: firstname.lastname@example.org (Add the actual body of the message, next)
Step 3: Where to send the message?
Next, the hacker would determine the servers that handle inbound email for the target’s domain — luxsci.net. This could be easily done using the “dig” command at the Linux/Unix/Mac command line:
#>dig +short luxsci.net mx
This informs the hacker that s/he can use “inbound10.luxsci.com” as the server to connect to to send the message.
Step 4: Sending the forged email message
Next, the hacker fires up the standard “telnet” program and connects to inbound10.luxsci.com on port 25 (the standard port for inbound email delivery) and “talks SMTP” to that server… specifying who the message is from and to and what the message contains. The server accepts that (hopefully) and then filters it and (maybe) delivers it to the unsuspecting recipient.
The BLUE indicates content entered by the hacker; the black, responses of the mail server.
#>telnet inbound10.luxsci.com 25
Connected to inbound10.luxsci.com.
Escape character is ‘^]’.
220 rs302.luxsci.com ESMTP Sendmail 8.14.4/8.13.8; Thu, 5 Feb 2015 15:31:49 GMT
250-rs302.luxsci.com Hello static-71-174-64-40.bstnma.fios.verizon.net [126.96.36.199], pleased to meet you
250 2.1.0 email@example.com… Sender ok
250 2.1.5 firstname.lastname@example.org… Recipient ok
354 Enter mail, end with “.” on a line by itself
Received: by mta5.ealerts.bankofamerica.com id hqdcek163bnq for <email@example.com>; …
From: “Bank of America” <firstname.lastname@example.org>
Reply-To: “Bank of America” <email@example.com>
Subject: Alert! You Bank of America account has been compromised
250 2.0.0 t15FVnRD023664 Message accepted for delivery
221 2.0.0 rs302.luxsci.com closing connection
Connection closed by foreign host.
You can see in this dialog, that:
- The hacker pretended to be coming from one of Bank of America’s servers (ehlo ealerts.bankofamerica.com)
- The hacker set the “envelope” from and to addresses to match that in the fake message (the “rcpt to” and “mail from” SMTP commands)
- The hacker send the full fake message
- The server was “ok” with it.
You can also see in this dialog, that there does not appear to be anywhere that the sender identity is validated or checked. This is not actually the case.
The Received Forged Email
The unsuspecting recipient may soon find a message from “Bank of America” in his/her INBOX.
The recipient may believe it, click on it, and be sucked into some phishing scheme!
What are Your Defenses?
Since forged email has been around time, email has evolved and there are defenses against this that work to varying degrees.
Some of these include:
- SPF to verify that the server used to send email is authorized to do so
- DKIM to sign messages and prove that the sender is authorized to construct messages from this sender
- Filters to block wide-spread/common phishing attacks (doesn’t help with spear phishing — messages targeted at you, specifically)
- Allow and Deny lists that permit messages from specific IP addresses
- Common Sense
In our next post on this topic, we will analyze the message received by firstname.lastname@example.org and see what tell-tale signs exist indicating that it is fraud and start to examine how messages such as this can be and are stopped every day by properly configured email systems.
We will see that there is a large burden on the owner of the sending domain to put measures in place to ensure that recipients of messages “from” them can properly differentiate good messages from forged messages. We shall see, for example, how Bank of America does this.
Read Followup Post: Analyzing a Forged Email Message: How to Tell it was Forged?