33

I've received some strange e-mail recently. The e-mail has different From and Reply-To fields. It has also To set to Undisclosed recipients but it's not crucial.

At first I thought it's fake, but then I've read this post which mentions that Received field can't be faked. It seems that received is proper in case of the e-mail I'm talking about:

Received: (wp-smtpd mx.tlen.pl 14490 invoked from network); 2 Oct 2018 07:19:36 +0200
Received: from mx.beniculturali.it ([194.242.241.200])
          (envelope-sender <pm-pie.aglie@beniculturali.it>)
          by mx.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP
          for <myemail@10g.pl>; 2 Oct 2018 07:19:36 +0200
Received: from sea2.mail.beniculturali.it (localhost.localdomain [127.0.0.1])
    by localhost (Email Security Appliance) with SMTP id 15EE31ECEEA_BB2FFE8B;
    Tue,  2 Oct 2018 05:19:36 +0000 (GMT)
Received: from MB2.mail.beniculturali.it (mb2.mail.beniculturali.it [192.168.123.122])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
    (Client CN "email.beniculturali.it", Issuer "Actalis Authentication CA G3" (not verified))
    by sea2.mail.beniculturali.it (Sophos Email Appliance) with ESMTPS id 1C9BD1E9E28_BB2FFE7F;
    Tue,  2 Oct 2018 05:19:35 +0000 (GMT)
Received: from MB2.mail.beniculturali.it (192.168.123.122) by
 MB2.mail.beniculturali.it (192.168.123.122) with Microsoft SMTP Server (TLS)
 id 15.0.1395.4; Tue, 2 Oct 2018 07:19:30 +0200
Received: from ca4.mail.beniculturali.it (192.168.123.144) by
 MB2.mail.beniculturali.it (192.168.123.122) with Microsoft SMTP Server (TLS)
 id 15.0.1395.4 via Frontend Transport; Tue, 2 Oct 2018 07:19:29 +0200
Received: from MDC.mail.beniculturali.it ([192.168.123.171]) by
 ca4.mail.beniculturali.it ([192.168.123.144]) with mapi; Tue, 2 Oct 2018
 07:19:29 +0200

Is it possible to spoof Received field somehow, perhaps using advanced techniques?

Arkadiusz Kałkus
  • 433
  • 4
  • 6
  • 1
    You could export a email from one inbox (e.g., *.eml format) and import it into another mailbox. Many clients won't complain. An email could be put into your inbox server side, it's just a file. I will let someone else go into more detail about why a server may accept or not accept fake headers when it receives it from a sender. – Eric G Oct 03 '18 at 11:41
  • 45
    _"The e-mail has different From and Reply-To fields."_ That's not strange. After all, there's a reason that they're separate fields! – Lightness Races in Orbit Oct 03 '18 at 14:43
  • 5
    In addition to LRO's comment, a "To:" field of "Undisclosed recipients" is also not necessarily suspicious. It is what I would expect (for example) if the Italian Ministry of Culture were to send out a newsletter to all the people who had signed up for it. The recipients would be BCC (to protect their privacy), and there would be (effectively) no TO: field. – Martin Bonner supports Monica Oct 04 '18 at 07:59

1 Answers1

58

It is possible to add arbitrary fields to the mail and this includes Received headers. But, any proper mail transport server will add a new Received header on top of the mail which means that, depending on the exact delivery infrastructure, the attacker can at most fully fake all but the topmost Received header. In your specific example, the top Received header seems to be some internal server and the next Received header is the one from your mail server at the perimeter which accepts mails from outside. All other Received headers might be faked.

And even the Received header added by the server at the perimeter might contain fake information. It is common that it includes the hostname claimed by the SMTP client within the EHLO or HELO command. Thus, in your specific example mx.beniculturali.it might be faked by the attacker while ([194.242.241.200]) is added by the receiving mail server to show from which source IP the mail was received and cannot be faked.

Toby Speight
  • 1,214
  • 9
  • 17
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 10
    TL:DR: you can trust the chain of `Received:` headers from servers you trust (if they haven't been hacked and this is just regular spam / phishing), until the ones after an IP address you don't trust. – Peter Cordes Oct 04 '18 at 01:43
  • FYI, when there's a name inside the parentheses before `[IP-address]`, it's the result of reverse DNS of the IP. – Barmar Oct 04 '18 at 02:09
  • @PeterCordes: You don't know for sure which server has added a `Received` header. Even if the header looks familiar and you trust the server which usually adds this header it might still have been an attacker which added this header to trick you into trusting a spear-phishing mail. At the end these headers are just text inside a message delivered within the SMTP dialog. You can only trust the topmost headers as long as these are within your own infrastructure. You cannot trust any header after the `Received` header from the perimeter, even if the header looks familiar. – Steffen Ullrich Oct 04 '18 at 04:11
  • 1
    @Barmar: *"...when there's a name inside the parentheses before [IP-address], it's the result of reverse DNS of the IP."* - according to the syntax defined in [RFC 5321](https://tools.ietf.org/html/rfc5321#section-4.4) the `TCP-info` should contain *"...Information derived by server from TCP connection not client EHLO.."*. Thus if there is a domain name given it might be the result of a PTR lookup as you say. But if the attacker controls the DNS for the specific IP he could make it return anything from the PTR lookup and thus one should not trust the domain value given there either. – Steffen Ullrich Oct 04 '18 at 04:26
  • 3
    @SteffenUllrich: Maybe I shortened too much. If you trust the server who's IP address is listed in the last (top) `Received:` header (added by the final hop), you can trust that one previous `Received:` header was added by that trusted server. (It might have a bogus EHLO name, but you can trust that it was added by a trusted server and the IP address is real.) You can follow this chain backwards if you trust the IP address in the last trusted `Received:` header. (Again, this is true only if your threat model doesn't include hacked mail relays.) – Peter Cordes Oct 04 '18 at 07:49
  • 2
    @PeterCordes: I fully agree with this extended description. – Steffen Ullrich Oct 04 '18 at 08:28
  • If the name inside and outside are the same, it's right to be suspicious, since the attacker controls both. But if they're different, the one inside is less suspicous, since controlling reverse DNS requires controlling a chain of delegations (ISPs typically only delegate reverse DNS to enterprise customers, not residential). – Barmar Oct 04 '18 at 15:18