This article describes my issues with Microsoft’s SPF implementation uncovered during a Thanksgiving phishing attack.

Thanksgiving morning, our Azure AD monitor picked up unusual increase in failed overseas log-in attempts. By itself it’s nothing new, but this time it was correlated with a massive phishing attack targeting one of our Office 365 domains (let’s call it foo.com).

What’s interesting is that it was that very domain name (foo.com) which the attackers used to impersonate legitimate business employees.

Sounds like a text-book case for SPF, doesn’t it? So I thought, until my work colleagues reported receiving some of those emails in their mailboxes.

How come?

Let’s have a look at the email that Microsoft’s SPF considered legit:

Received: from BN3NAM04FT063.eop-NAM04.prod.protection.outlook.com (2a01:111:f400:7e4e::205) by CY4PR13CA0046.outlook.office365.com (2603:10b6:903:99::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1361.11 via Frontend Transport; Wed, 21 Nov 2018 17:30:26 +0000
Received: from iospa.com (186.70.214.34) by BN3NAM04FT063.mail.protection.outlook.com (10.152.93.170) with Microsoft SMTP Server id 15.20.1339.10 via Frontend Transport; Wed, 21 Nov 2018 17:30:25 +0000
Received: from 10.15.47.102 (unknown [162.222.110.146]) by iospa.com (Postfix) with ESMTP id 9820A1FD0A30 for <[email protected]>; Wed, 21 Nov 2018 11:32:30 -0500 (ECT)
From: Kate <[email protected]>
To: Susan <[email protected]>
received-spf: Pass (protection.outlook.com: domain of iospa.com designates 186.70.214.34 as permitted sender) receiver=protection.outlook.com; client-ip=186.70.214.34; helo=iospa.com;

Clearly, the message was sent from outside O365. In this case it looks like remote infected machines in Puerto Rico and Ecuador were used.

These are the SPF records for foo.com:

➜ ~ host -t TXT foo.com
foo.com descriptive text "v=spf1 include:spf.protection.outlook.com -all"

That’s pretty explicit: only emails that originate from within Microsoft’s infrastructure (spf.protection.outlook.com is a catch-all) should be allowed when using the domain “foo.com”.

Devil’s in the details

SPF is defined by RFC7208. It describes two identities which can be used during the determination process:

• the “HELO” identity,
• the “MAIL FROM” identity.

While the former is being used by sender’s email server (it could be shared across thousands of domains and in most cases is not related to sender’s address), the latter is based on sender’s email address domain name.

In other words, if an email is sent from [email protected] and delivered by a mailerA.com server, then the “HELO” identity would be associated with domainA.com, while the “MAIL FROM” identity would be mailerA.com.

At this point, the question is – which of these should be subject to SPF’s scrutiny? Unfortunately, the RFC is pretty ambiguous in that regard. In paragraph 2.3 it says:

It is RECOMMENDED that SPF verifiers not only check the “MAIL FROM” identity but also separately check the “HELO” identity […]

Then, in 2.4:

SPF verifiers MUST check the “MAIL FROM” identity if a “HELO” check either has not been performed or has not reached a definitive policy result […]

They also suggest the following order:

Checking “HELO” before “MAIL FROM” is the RECOMMENDED sequence if both are checked.

Where I disagree with the RFC is to allow the “MAIL FROM” checks to be skipped if “HELO”-based analysis is conclusive enough.

Microsoft vs Logic

What Microsoft decided to do is to implement their SPF so that it takes advantage of this opportunity left by the authors of RFC7208 and only check HELO/EHLO domain name compliance.

While it might be considered technically valid from the RFC perspective, it has devastating consequences: in our case it allows anyone to send a phishing email to an O365 tenant by forging their “From:” address to someone from the victim’s organization. Then, as long as the MTA’s hostname / ip / ehlo are SPF valid, Microsoft will attempt to deliver that email (subject to additional policies).

I find it difficult to justify Microsoft’s decision. Especially when it’s applied to domain names hosted in Azure/O365. But even outside of this context, “MAIL FROM” checks should be performed, as this is the domain name that the recipient will see (in sender’s email address) in their mail client. It’s the “MAIL FROM” domain domain which usually is forged during phishing attacks, not the HELO/EHLO one, which 99.99% of Outlook users have no exposure to whatsoever.

I reached out to Microsoft’s anti-phishing department with Request for Comments (pun intended).