Troubleshooting and Identifying Spoofing Attacks

Modified on Thu, 3 Jan, 2019 at 1:54 PM

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

Microsoft blogs

REFERENCE: https://blogs.technet.microsoft.com/eopfieldnotes/2015/12/23/troubleshooting-and-identifying-spoofing-attacks/