16

My friend recently received a suspicious email for an iTunes gift card purchase from "Apple Store" with a header that displayed a fake "To:" address for orders@apple-store.com.

Fake "to" header

Unsurprisingly, this turned out to be a phishing email with a suspicious "From:" address.

From: Apple Store <mystorepaysbills767wf08t7q86tpj1@unpaidpurchaseneedconfirmtocontinue.com>

I couldn't find any reference to my friend's real email address in the message itself. I've heard of headers having a fake sender address, but I've never seen an email list a fake recipient.

How could my friend have received this email if it was sent to a fake email address?

  • 14
    While you ask about bad recipient the explanation can still be found in Why is it even possible to forge sender header in e-mail?. Watch out for the difference between SMTP envelope (RFC 2821) and Message header (RFC 2822) - the first is relevant for sending, the second is relevant for displaying the mail. – Steffen Ullrich Jul 27 '18 at 14:44
  • 11
    I can write a letter that claims to be from Santa Claus to the Easter Bunny, put it in an envelope addressed to you, and the post office will happily deliver it to you. – David Schwartz Jul 27 '18 at 15:34
  • 4
    @DavidSchwartz Well, maybe not happily. – mbomb007 Jul 27 '18 at 18:16
27

When mail is sent via SMTP, there are two separate places this sort of information goes, the Envelope (things that are set with SMTP commands) and the Header (the first block of text under the SMTP Data command, ending with a blank line). So, for example, here is an SMTP transaction where the Envelope disagrees with the Headers. The message will get delivered per the Envelope, but the recipient will see the headers.

mail from: <evil@evil.com>
250 2.1.0 Ok
rcpt to: <victim@example.com>
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
From: "Apple Store" <apple@apple.com>
To: orders@apple-store.com
Subject: We just received your purchase...

Mail body goes here.
.
250 2.0.0 Ok: queued as C5E251FFE2
quit
221 2.0.0 Bye
Connection closed by foreign host.

The fake recipient goes in the header "To:" line, but the mail is delivered according to the value set in the SMTP "RCPT TO" command. And indeed, the recipient sees the Header that the attacker wanted them to see:

Mail client view of forged email

Now, there is some protection against this. If you tell your mail client you want to view the full mail headers, you'll note that the mail server injected an several headers that tell the true story:

From evil@evil.com Fri Jul 27 14:45:21 2018
Return-Path: <evil@evil.com>
X-Original-To: victim@example.com
Delivered-To: victim@example.com

But, of course, mail clients always hide this level of detail by default, and interpreting headers correctly can be difficult. The key to remember is that they are prepended by servers as they go along, so the ones that the top are put in by your server; if you see "Return-Path" at the bottom of the headers it's likely forged by the attacker to try and misdirect you... Since the original message 'data' contains headers crafted by the sending client, they can put whatever they want in there before the servers start prepending.


As per how to do it -

The first rule of email recipient forgery is, expect it to fail miserably.

The second rule is, use Bcc: for the recipients you want to get it, and To: for recipients you want to be seen getting it. This is the standard way of doing this with a mail client, and generally works with everything from mailx to gmail.

But mileage may vary unpredictably. For example, if you leave To: blank, many mail servers will stuff the contents of Bcc: into To: to make up for it. 20 years ago I spammed thousands of "hidden recipients" with each other's addresses that way, sending out a contest update to the list of applicants. OOPS.

  • 1
    How do you tell your mail client to do this? For example, in Gmail? – Jimenemex Jul 27 '18 at 19:42
  • @Jimenemex: If you mean spoofing the sender, the easiest way is to write your own mail client. It's just a TCP connection with ASCII text, nothing difficult. – Ben Voigt Jul 27 '18 at 20:31
  • @Jimenemex, I appended an answer to your comment at the end of the question. – gowenfawr Jul 27 '18 at 20:48
  • 1
    If your example is correct, all I need to do is blacklist evil.com, right? – corsiKa Jul 27 '18 at 22:22
3

This looks like use of the standard Bcc header. The message quite likely was sent to the displayed To address, but also to your friend (and, quite likely, to many other people) using the Bcc header.

Bcc headers are only in the SMTP envelope, so your mail client will not show them by default. (And, under the hood, if there are multiple Bcc headers, it’s split out by the sending server into multiple separate emails, so even if you do view the envelope, you’ll see only your own address, not anyone else’s.)

  • 3
    -1. The mail client doesn't get BCC information. That'd be a huge issue with BCC itself if Blind-Carbon-Copy was simply "Well, it's not technically blind, but we're going to hope mail clients don't show the information by default." If you send a BCC to an email address, the account receives the email, but it doesn't have BCC headers listing the BCC addresses. So the whole thing about "mail client will not show them by default" is wrong. It can't display them. – Kevin Jul 27 '18 at 17:38
  • @Kevin. I edited to address your comment. – TRiG Jul 27 '18 at 18:01
  • 2
    @Michael: There are no "headers" in the "SMTP envelope". Headers are part of the MIME message format. There is no header sent for BCC. BCC recipients are specified through SMTP commands (which are called the envelope as if they had meaning on their own -- they don't because they are part of a two-way query/response protocol) which doesn't use "headers" in any shape or form. The only place that a BCC header might exist is in the sender's copy of the e-mail. It's not a matter of "not shown", it just does not exist. – Ben Voigt Jul 27 '18 at 20:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.