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: <0LkRJt-1f0gbO2qeR-00cNDF@mrelay.perfora.net>
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
mythofechelon
  • 217
  • 1
  • 11
  • *"...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: sender@to.spoof`. This is `header.from` while the part in the SMTP dialog `mail from: sender@to.spoof` is `smtp.mailfrom`. Also, the `authentication-results` you show suggest that there is no DMARC policy for the domain in `header.from` setup. – Steffen Ullrich Dec 27 '17 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]>`. – mythofechelon Dec 27 '17 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. – Steffen Ullrich Dec 27 '17 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. – mythofechelon Dec 27 '17 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. – Steffen Ullrich Dec 27 '17 at 14:41
  • @SteffenUllrich Yes, I thought it was odd that those headers were at the bottom. Other than the domain names, I don't have any more information than those headers which is why I'm trying to figure out how I can recreate this problem. – mythofechelon Dec 27 '17 at 14:47
  • I've recently learned how easy it is to inject forged headers which would explain why `authentication-results` is towards the bottom but I think that doesn't explain why the MTA itself didn't add its own results into the headers. Unless it doesn't perform any checks if it sees that results are already present. These days, ARC is supposed to solve that but not sure about back then. – mythofechelon Apr 02 '21 at 11:45
  • *"ARC is supposed to solve that"* - there is huge gap between what is proposed as standard and what is actually used in practice. And ARC is not even a standard, RFC 8617 from 2019 is clearly declared as experimental. – Steffen Ullrich Apr 02 '21 at 13:25

0 Answers0