3

A client recently received an email that was spoofed in a way that I'd never seen before. The following are the anonymised, relevant details from the email's headers:

  1. authentication-results: spf=none (sender IP is 74.208.4.197) smtp.mailfrom=[hacked domain name]; [client's old domain name]; dkim=none (message not signed) header.d=none;[client's old domain name]; dmarc=none action=none header.from=[client's old domain name];
  2. Reply-To: [Director] <[director's old email address on client's old domain]-l.in>
  3. From: [Director] <[director's new email address on client's new domain]> To: [accounts' distribution group] <[accounts' new email address on client's new domain]>

What's different and interesting about this is that the attacker was able to bypass the DMARC policy of the client's new domain. I think I know how the attacker was able to do this:

  1. A domain with no SPF, DKIM, or DMARC policy (hacked domain name) was used for the SMTP / 5321 / smtp.mailfrom level.
  2. A domain with an SPF policy but no DKIM or DMARC policy (client's old domain name) was used for the MIME / 5322 / header.from level.

I read that MTAs obtain the DMARC policy of the domain specified in the header value header.from. So, my question is this: to confirm my theory, how can I send an email with a "custom" header value header.from? I'm used to using CLIs such as telnet, etc.

I've asked a very similar question previously but that answer doesn't answer this question.

 

The full (but anonymised) email headers:

Received: from HE1PR0502MB3002.eurprd05.prod.outlook.com (10.175.30.147) by
 AM5PR0502MB2994.eurprd05.prod.outlook.com (10.175.40.20) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
 15.20.302.9 via Mailbox Transport; Thu, 14 Dec 2017 09:34:42 +0000
Received: from AM3PR05CA0056.eurprd05.prod.outlook.com
 (2a01:111:e400:52b7::24) by HE1PR0502MB3002.eurprd05.prod.outlook.com
 (2603:10a6:3:d7::19) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Thu, 14
 Dec 2017 09:34:41 +0000
Received: from DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com
 (2a01:111:f400:7e0a::200) by AM3PR05CA0056.outlook.office365.com
 (2a01:111:e400:52b7::24) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.302.9 via Frontend
 Transport; Thu, 14 Dec 2017 09:34:40 +0000
Received: from mout.perfora.net (74.208.4.197) by
 DB5EUR03FT048.mail.protection.outlook.com (10.152.21.28) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
 15.20.302.6 via Frontend Transport; Thu, 14 Dec 2017 09:34:39 +0000
Received: from box.backup ([93.158.216.105]) by mrelay.perfora.net (mreueus002
 [74.208.5.2]) with ESMTPA (Nemesis) id 0MFrWa-1eCoig3ce6-00EttU for
 <[accounts' old email address on client's old domain]>; Thu, 14 Dec 2017 10:34:37 +0100
From: [Director] <[director's new email address on client's new domain]>
To: [accounts' distribution group] <[accounts' new email address on client's new domain]>
Subject: Handle this asap
Thread-Topic: Handle this asap
Thread-Index: AQHTdL7FI+cnKCIw4k+addTBVGYrjQ==
Date: Thu, 14 Dec 2017 09:34:37 +0000
Message-ID: <[email protected]>
Reply-To: [Director] <[director's old email address on client's old domain]-l.in>
Content-Language: en-US
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-Network-Message-Id: 31f5cd96-3a15-44e2-9b9e-08d542d5e661
X-Message-Flag: Follow up
X-MS-TNEF-Correlator:
received-spf: None (protection.outlook.com: mylesstandish.net does not
 designate permitted sender hosts)
x-forefront-antispam-report: CIP:74.208.4.197;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(8156002)(2980300002)(428003)(199004)(189003)(8676002)(9686003)(305945005)(7596002)(105586002)(16003)(106466001)(6862004)(5660300001)(16586007)(7116003)(568964002)(22720200003)(84326002)(567704001)(63106013)(9886003)(3480700004)(564344004)(1096003)(7636002)(50126003)(6636002)(246002)(21480400003)(5003630100001)(104016004)(356003)(42882006)(5000100001)(512874002)(4610100001)(43066004)(89386003)(33896004)(59450400001)(5890100001)(33964004)(2476003)(2351001)(362424002)(24616003)(79866001);DIR:INB;SFP:;SCL:1;SRVR:HE1PR0502MB3002;H:mout.perfora.net;FPR:;SPF:None;PTR:mout.perfora.net;A:1;MX:1;LANG:en;
authentication-results: spf=none (sender IP is 74.208.4.197)
 smtp.mailfrom=mylesstandish.net; [client's old domain name]; dkim=none
 (message not signed) header.d=none;[client's old domain name]; dmarc=none
 action=none header.from=[client's old domain name];
x-provags-id: V03:K0:+bX50qyGpYWG3nl2KR5LrxNR5QAuHerD/Ci0f15XSi0PrkdhYn7
 +asr62VMEJkFiChjE1rpF24A9/b1VQ4nq4V8xll8uJfrCxXKQFtioq5I3UUXzzIzsmoKlBz
 c8zcN90wq7PruWyApRfkG93yISwROTLUDhZAYhqn0DByTKPp8Ptj/h4ZVWFkXx+j2BfrGnl
 GRtxBbN6NAonCIMyPfftg==
x-ms-publictraffictype: Email
X-Microsoft-Exchange-Diagnostics: 1;AM5PR0502MB2994;27:PiEq5e2siU4JRO2TOrf1wEQY8e6CKGY0XpuGPTv1fAFH0U+X/mtVoF0DxL6/hHUuOK471Zu3M4iWfglkgAeZ9eoeyHp1ANXSL162vYFQaKRRjLwewNhY6osSswalTYkk
X-Microsoft-Antispam-Message-Info: jzBEPkz1MG4wSRW5IeNhdiFkN52T1FtBma8q4n/g2yIjDgQHGfmm8feWpuoG6UZX
Content-Type: multipart/mixed;
    boundary="_002_0LkRJt1f0gbO2qeR00cNDFmrelayperforanet_"
MIME-Version: 1.0
8
  • "...but that answer doesn't answer this question." - actually it does. The relevant part from the answer is in the header of the mail data: From: [email protected]. This is header.from while the part in the SMTP dialog mail from: [email protected] is smtp.mailfrom. Also, the authentication-results you show suggest that there is no DMARC policy for the domain in header.from setup. Dec 27, 2017 at 10:06
  • @SteffenUllrich That's what I thought but the MTA used the DMARC policy of header.from=[client's old domain name], not From: [Director] <[director's new email address]>. Dec 27, 2017 at 10:22
  • header.from is the From: ... header from the mail. There might be different interpretations done by the DMARC verification and the way you see the header, for example if multiple From: .. headers are used or if encoding tricks are done or similar. I doubt that it is possible to get into more detail without being able to reproduce what you have, which means having access to the full, original and unredacted mail header. Dec 27, 2017 at 10:44
  • @SteffenUllrich I can't provide the domain names or email addresses but I've added the headers which may be sufficient. Thanks. Dec 27, 2017 at 14:30
  • Both the Received-SPF and the Authentication-Results header should be above the Received header from the MTA which added these headers. But they are not in your question. Either something messed up the headers or they don't belong to the current delivery, for example if the mail got forwarded. Dec 27, 2017 at 14:41

0

You must log in to answer this question.

Browse other questions tagged .