SPF shortcomings with Return-Path in spoofed emails

First, review the email below which is supposedly from support@microsoft.com, but which really originates from elsewhere, having links to a phishing site (click image to enlarge):

There is nothing legitimate about this email, although the Outlook user interface says it originates from microsoft.com (with a logo) and SPF resolves to "pass".

Sender Policy Framework (SPF) should be a well-known standard to IT professionals who operate email gateways. The RFC 7208 standard for authorizing use of domains in email defines how the owner of a web domain can specify in their DNS records which hostnames and/or IP addresses are allowed to send email on behalf of that domain.

In practice this means that e.g. for the securepractice.co domain, if anyone apart from our own mail servers should be sending emails where the From email header is set to something@securepractice.co, the receiving email gateway will look up securepractice in DNS, find the DNS record for SPF in this domain. Since the sender's email server is not mentioned here, the gateway should then reject the message, or at least filter it as spam.

We are however observing a technique in phishing emails where the receiving gateway is tricked to perform SPF validation address on a completely different address than the one which appears in the email client of end users.

Exploiting the Return-Path header

According to the original RFC 822 standard for Internet Text Messages (aka. email), a header by the name of Return-Path may be set by the final transport system (SMTP) which delivers an email to the recipient's mailbox, to specify definitive information about the route back to the original sender. Its purpose was originally to allow delivery error messages to be returned if needed, for instance if the recipient does not exist.

However, as the RFC 2821 standard on SMTP describes, inferring this header at the correct time may not alway be straightforward, as it may sometimes be difficult for an SMTP server to determine if it is making final delivery due to forwarding which may happen.

The SMTP standard however contains a statement which literally invites to abuse:

   A message-originating SMTP system SHOULD NOT send a message that
   already contains a Return-path header.

Of course this could be harmless enough, had it not been for the fact that SPF validation may be performed on basis of the Return-Path address. Taking the SMTP specification into account, the email should already be within the recipient's trust boundary when this header is present. Unfortunately, due to inconsistencies in email standard implementations, this is not necessarily the case.

To complicate things further, email clients usually only present end-users with the From header while leaving little or no trace of the Return-Path address in the user interface, as can be seen in the screenshot above. In Office 365, the From address is even used as a very helpful basis (for the unauthorized sender) to present the Microsoft logo in the message heading.

In email clients, a small note may in some situations be appended to the sender address stating it was sent "via" or "on behalf of" the domain specified in Return-Path. This is however just one more place for end-users to parse sender information, and it may not be intuitive and apparent for everyone to know which value to trust:

In some cases, Outlook includes a subtle note above the email that this sender appears to be sending emails from a new origin, with a link to Microsoft's support page on the matter. We have however observed that the Return-Path header is specified as <> (a blank address), which appears to suppress this notice from Outlook.

SPF is insufficient on its own

Seeing how SPF may be evaluated based on Return-Path, additional controls are necessary to properly detect and handle sender address spoofing.

One such control is DMARC (Domain-based Message Authentication, Reporting & Conformance), which does not only take SPF into account, but also DKIM (domain based message signing) and the sender domain's specific DMARC entry in the DNS into account. Although DMARC simply states a policy for how receiving parties shall process the results of SPF and DKIM, validation here appears to be based on the From address rather than Return-Path, at least in Microsoft Exchange.

The availability of DMARC therefore makes it possible to defeat such messages, at least for the abuse of sender domains which have defined a DMARC record in their DNS with action "reject" or "quarantine". In practice, this is however more often the exception rather than the rule, although many large brands have adopted DMARC over the last couple of years.

For any other cases, SPF may pass based on Return-Path, and the email is delivered to the end user unless some other processing rule is implemented at the gateway level.

As in many other cases, one can hardly expect people in general to be able to understand the intricate ways of how emails can be exploited. It is however possible to technically detect such exploitation attemts, like we do with our MailRisk add-in for Outlook, which allows any end-user to get immediate help with suspicious emails, regardless of attack vector.

Contact us today to learn how we also make it clear to your security team how and when techniques like these are used to trick your colleagues, and give you the necessary data to efficiently mitigate such threats.