Troubleshooting and Identifying Spoofing Attacks

Even with technologies like SPF, DMARC, and DKIM, spoofing and phishing attacks are still extremely prevalent. Some of these attacks can be stopped with properly configured SPF, DMARC, and DKIM, where as others need to be targeted with end user education.

This isn’t so much of a how to article, but more of a document to help identify various types of spoofing and phishing attacks, and what technologies you can use to stop them.

 

Header Terminology

The following excerpt from a message header will be used to identify the various headers that are important when dealing with a spoofing attack.

  Authentication-Results: spf=none (sender IP is 167.220.24.220)
 smtp.mailfrom=contoso.com; microsoft.com; dkim=none (message not signed)
 header.d=none;microsoft.com; dmarc=none action=none
 header.from=tailspintoys.com;
 From: From header FromHeader@tailspintoys.com    <-- 5322.From header
 To: Andrew Stobart andrew.stobart@microsoft.com
 Subject: Different MailFrom and From headers
 Return-Path: MailFromHeader@contoso.com    <-- 5321.MailFrom
 Reply-To: replyto@adventure-works.com   <-- Reply-To address

 

5321.MailFrom header

The MailFrom address represents the address that was sent in the envelope of the message. The domain used in this address is what the SPF check will be done against. In an SMTP conversation, this will be specified as MailFrom. In a message header, this will be identified as the Return-Path.

 

5322.From

This is the From address that you see in your mail client.

 

In the message header, this address will be the From header.

 

In most scenarios, the From and MailFrom headers will match, however these will typically be different in messages where spoofing is used (they also tend to be different for bulk mail). Typical spoofing attacks will only spoof the From header because SPF will not check the domain specified in this header, therefore bypassing SPF).

 

Authentication-Results header

This header will provide the results of the SPF/DKIM and DMARC checks. It also contains the following.

Smtp.mailfrom = Specifies the domain used in the 5321.MailFrom address.
Header.from = Specifies the domain used in the 5322.From address.
SPF = Results of the SPF check.
DKIM = Results of the DKIM check.
DMARC = Results of the DMARC check.

 

Reply-To header

If this header is set, when a mail client replies to the message, the reply will be directed to this address, regardless of what the original From or MailFrom addresses were.

 

Spoofing methods

The following are examples of the most common type of spoofing attacks.

 

5322.From header is spoofed, but the 5321.MailFrom is for a domain controlled by the attacker

Consider the following SMTP commands for a sent message:

  S: Helo woodgrovebank.com
 S: Mail from: phish@phishing.contoso.com  <-- 5321.MailFrom
 S: Rcpt to: astobes@tailspintoys.com
 S: data
 S: To: "Andrew Stobes" <astobes@tailspintoys.com>
 S: From: "Woodgrove Bank Security" security@woodgrovebank.com  <-- 5322.From

 

The recipient would see the message being sent from security@woodgrovebank.com.

 

The SPF check will be done against phishing.contoso.com, which will pass (or be none) because the attacker will own this domain. This is why this type of attack is so highly used.
This type of spoof can be identified when you see a Return-Path header that is different from the From header. Here’s an excerpt of the message header for the above message.

  From: Woodgrove Bank Security  <security@woodgrovebank.com> 
 To: Andrew Stobart <andrew.stobart@microsoft.com>
 Subject: Different MailFrom and From headers
 Return-Path: phish@phishing.contoso.com    <-- SPF only checks this domain

 

In these types of messages, the attacker will usually not expect the user to reply back to them (as the message would go to the spoofed address which the attacker will not control). These types of messages typically contain a URL to a phishing site which the attacker is hoping the recipient will click on.

SPF combined with DMARC would detect this type of spoof. SPF on it’s own would not as SPF only checks the domain in the 5321.MailFrom address.

 

5322.From header spoofed, and 5321.MailFrom = 5322.From

Similar to the above attack, but in the headers you will see the From header and Return-Path header match. These attacks typically contain phishing links that the attacker hopes will be clicked on.

SPF will detect this attack; however, it is strongly recommended to implement DMARC along with SPF.

 

Homoglyph Attacks (attacker owns a domain that is similar to the customers)

These types of attacks are similar again to the above, except the domain being spoofed is owned by the attacker and is very similar to the company that they are attacking. Consider the following:

 

In this case, the attacker hopes that when the recipient replies back to the message, they will not notice that the domain they are replying to isn’t actually their own. We also see a similar type of attack used where the attacker spoofs the customers’ domain exactly, but then sets a Reply-To header which is set to a domain that is similar to the customers, but owned by the attacker.

 

Attacks that use the Reply-To header

When a Reply-To header is present, when a recipient replies back to a message, the reply will be directed to the address specified in the Reply-To header.

Example. Consider the following spoofed message. Notice how even the profile pictures appears.

 

Here’s what happens when I hit the Reply button.

Notice that the reply is being sent to a domain that the attacker will own. The attacker hopes that the recipient won’t notice that the reply to address is different from the sending address.

Here’s what the header looks like for this type of attack.

 From: <name redacted>@microsoft.com
To: <name redacted>@microsoft.com
Reply-To: joe.someone@contoso.com
Subject: Wire transfer request
Return-Path: <name redacted>@microsoft.com

SPF and DMARC will detect these types of attacks. In addition, end user education is also highly recommended.

 

Anti-spoofing Technologies

Sender Policy Framework (SPF)

Sender Policy Framework or SPF is a technology for sender authentication. SPF uses a DNS TXT record to store a list of authorized sending IP addresses for a given domain. A receiving mail server performs an SPF check by confirming that the connecting IP address is in the SPF record for the 5321.MailFrom domain. In Exchange Online the results of the SPF check is recorded in the Authentication-Results header and Received-SPF header.

Because SPF only checks the domain in the 5321.MailFrom address, SPF cannot detect spoofing attacks where the 5322.From address is spoofed, and the 5321.MailFrom address is set to a domain that the attack owns, and can therefore ensure SPF passes. This is where DMARC comes in.

 

Domain-based Message Authentication, Reporting an Conformance (DMARC)

DMARC uses Sender Policy Framework (SPF) and/or DomainKeys Identified Mail (DKIM) to authenticate the 5322.From address. DMARC will pass if an SPF or DKIM check passes and the domain in the 5321.MailFrom and 5322.From addresses match. This means that DMARC will always fail if the domain of the 5321.MailFrom does not match the domain of the 5322.From.

 

DomainKeys Identified Mail

With SPF records, you can only add up to ten DNS lookups in the record. If you have many third parties that can send on your behalf, you will quickly hit this wall. This is where DKIM comes in.
DKIM allows you to sign outbound mail with a signing certificate. The public key for the certificate is present in your Public DNS, which will allow recipients to verify the sender is authorized.

 

User education

End user education is an extremely important piece of preventing spoofing attacks. End users should be educated on the following.

• Hover over URLs in your email client to verify they are going to a known location
• Don’t click on URLs from people you aren’t familiar with
• When replying back to a message, always verify the expected address is present on the TO line

 

Resources

Specifications

• SPF
• DMARC
• DKIM

 

Microsoft blogs

• Using DMARC to prevent Spoofing
• Using DMARC in Office 365
• Best Practices for Exchange Online Protection customers to align with DMARC
• Enhanced email protection with DKIM and DMARC in Office 365
• Manually hooking up DKIM signing in Office 365
• Exchange Online is rolling out default DKIM-singing to everyone

 

YouTube video by Microsoft Support Escalation Engineers

[embed]https://www.youtube.com/watch?v=0sXhMUJ3Scs[/embed]

Comments

• Anonymous
  December 23, 2015
  always interestingThanks
• Anonymous
  February 22, 2016
  Very interesting article, how is possible to test if DMARC auth is taking place correctly without using anonymous mailer that already blocked by most common Antispam services. I've tried telnet without success. Bye.
  • Anonymous
    May 18, 2016
    Using telnet from an IP address that is not in your SPF list is the easiest way to test DMARC. Telnet allows you to spoof your own domain, and as long as you come from an IP not in your SPF, you'll be able to see if DMARC passes or fails.
• Anonymous
  January 11, 2019
  Good article. I think I've received a spoofing email from 'my account' on hotmail- I looked in the header and it seems to indicate that authentication passed. Yet the email was filed into spam which suggests there is something that has been flagged. Am I right in saying that this could still be a spoofing email despite the passing of the authentication? I did see some rather curious things in the header including a different 'reply to' - is this a sure sign of spoofing or not?