Page 1 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF

implementation? | introduction | 1#2

How can hostile element execute Spoof E-mail

attack and bypass existing SPF implementation? |
introduction | 1#2

In the current article series, we will learn about a structured vulnerability of the SPF mail
standard, which can be easily exploited by a hostile element that can bypass the existing SPF
wall that was built for protecting our organization recipients from Spoofing or Phishing attacks.
Besides of the part in which we point out the structured vulnerability of the SPF mail standard, I
would like to go into the next level, and demonstrate how to execute a Spoof E-mail attack
that bypass existing SPF implementation.
The current article series include two articles.
The next article is How to simulate Spoof E-mail attack and bypass SPF sender verification? |
2#2

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 2 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Well Know Dilemma Should I Reveal In Public The SPF Vulnerability? |
Blackhat Versus White Hat
Before we continue, I would like to relate to the most basic resistance that can appear in the
mind of the reader: How do you dare to publish such information that can be used by a hostile
entity to hurt and damage my organization?
The simple truth is that the most of the time, this hostile entity is a professional person that
has a wide knowledge and a defined path for the why he should use for executing Spoofing or
Phishing attacks, and how to deal with existing sender identity verification standard such as SPF.
In other words, the hostile entity doesnt need my help and my support in revealing the
structured vulnerability of the SPF mail standard. I can assure you that he already knows about
this SPF blind spot, and the chance is that if he decides to attack your organization, he will use
it!
As a person which was appointed to serve and protect our organizations assets and our users,
we should have the integrity and the courage to admit that there are many threats and risks,
that could hurt us.
Instead of closing our eyes and ignore the vulnerability of our mail infrastructure, it looks to
me that the best state of mind should be move on to the more constructive and mature
question such as given that I am aware of this existential threat to my mail infrastructure, what
can I do to provide better protection to my organization and my users?

SMTP As Innocent Protocol | Spoof E-Mail And SPF As A Partial Solution

I describe the SMTP protocol as Innocent protocol because the main purpose of the SMTP
protocol is to transfer email messages from host A to Host B in the quickest and most effective
way.
When source Host (A) address destination Host (B), and asks to start an SMTP session, the basic
assumption of the destination Host (B) is that Host A is really who he claims to be.
This default assumption is being exploited by hostile elements, which disguise their real identity
by presenting the identity of a seemingly legitimate host \ recipient.
Over time, this identity problem reaches the awareness of organizations, that look for a
solution that will enable them to verify the senders identity, and be sure that the sender is really
who he claims to be.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 3 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
One of the most popular and well-known mail security standards that were invented to address
the need for verifying the sender identity is the SPF (Sender Policy Framework).
The SPF standard is based on a very simple verification test; in which we verify if a specific mail
server is authorized to send or represent specific domain names.
The specific domain name is the domain name that appears in the E-mail address of the
sender who addresses our mail server.
The problem is that the SPF mechanism has an inherent weakness because that the sender
verification procedure, is implemented by verifying the sender identity that appears on the
Mail envelop but, not the sender identity that can appear in the Mail header.
This Inherent weakness is exploited by a hostile element that could easily bypass our existing
SPF wall, and perform Spoof E-mail attack.
Attached a quotation from the SPF organization site:
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent
sender address forgery. More precisely, the current version of SPF called SPF v1 orSPF
Classic protects the envelope sender address, which is used for the delivery of messages.
See the box on the right for a quick explanation of the different types of sender addresses in emails.
(There are other solutions that protect the header sender address or that do not care at all
about who sent the message, only who originally wrote it.)
[Source of information Sender Policy Framework Related Introduction]
I assume that most of us are not aware or, only have partial knowledge about terms such as
Mail envelop , Mail header and the SMTP method in which the sender is using multiple
sender identities.
If you have the required patience, I promise you that after reading the current article, you will
understand better these concepts.
For the sake of full disclosure my opinion is that the SPF stand is a very important and
considers as necessary mail security standard, that must be adopted by every organization that
uses mail infrastructure.
My main purpose is to bring to your attention the blind spot of the SPF standard and make
you understand that you will probably need to use an additional mail security standard and
mechanism, together or side by side with the SPF standard.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 4 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
Additional reading

Sender Policy Framework Related Solutions

How Spammers Get Around SPF

So What Is The Solution For This SPF Blind Spot?

I would like to expand this question to wider range questions:
Q: Is there or, what is the perfect solution that I can use for providing complete protection for
my organization from Spoofing or Phishing attacks?
A: The good news is that there is such a thing as a perfect solution and when this solution is
applied, we can be sure that your organization has a very good protection from Spoofing
attacks.
The less good news is that there is no magic formula or a simple red button that we can use
for creating a transparent dome of energy that will protect our organization from any type of
bad guy and at the same time, enable our user to do their thing regularly and transparently
without any interference.
The solution of our distress is a combination or a cocktail of different mail security standard
that enables us to verify the sender identity, such as DKIM, DMARC, Exchange Online Spoof Email rules, user awareness program, etc.
The implementation of such combination will enable us to build a strong and thick protection
wall, that will protect our mail infrastructure and our users from most of the risks and the
hostile elements that are outside the wall and looking for a way to enter.
Our main tasks are:

Acknowledged the risk of Spoofing or Phishing attacks and the fact that while one way or
another, we experienced the danger of the above.
To be familiar with each of the possible solutions and the characters of each of the
possible solutions (advantages, disadvantages, etc.).
Decide what is the best combination of solutions that will best feet our organizational
DNA and our organization-specific business need.
Implement the existing protection mechanism, and have the required patience for the
required time that is needed to adopt and assimilate this solution (learning mode phase,
test phase, dealing with a false-positive scenario, etc.).

In the following diagram, we can see an example of the concept which I describe as a security
cocktail.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 5 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
The meaning of this term is a scenario, in which we use a combination of two or more mail
standard or another mechanism such as Exchange rule that will complement each other.
For example, in case that your mail infrastructure is based on Exchange architecture, we can use
an Exchange rule that will identify the
a un-authenticated recipient who uses an E-mail address with our domain name +
implementing the SPF sender verification standard, that will identify a scenario in which recipient
who uses an E-mail address with our domain name sends E-mail via an unauthorized mail server.
Another option could be using the DMARC mail standard that relies on the DKIM + SPF
standard, and provides a very good protection for most of the possible scenarios of Spoofing
attacks.
To recap dont look for any easy and simple solution that will that magically will solve all of
your problems. Be familiar with the existing risks and the existing solutions for this risk.

If you want to learn more about how to implement Exchange rule that will identify and will
respond in accordance, I have written article series of 12 articles that review the possible
options that you can use Dealing with an E-mail Spoof Attack in Office 365 based
environment | Introduction | Part 1#12

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 6 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

If you want to learn more about how to implemented DKIM in Office 365 (Exchange Online
based environment, I have written article series of 5 articles that review subject DKIM
Domain Keys Identified Mail | Basic introduction | Part 1#5
The structure of the current article series
The article series How can hostile element execute Spoof E-mail attack and bypass existing
SPF implementation includes two articles.
The current article our main focus will be:

1. The data structure of SMTP session and E-mail message.

2. The way that the SPF verification process is implemented.
3. The theoretical way that hostile element can use for bypassing existing SPF implementation.

In the next article, we will review the how to part in which we simulate a scenario of a hostile
element, that executes a Spoof E-mail attack and manages to bypass our existing SPF
infrastructure.

The Data Structure Of SMTP Session And E-Mail Message

Meta Data and E-mail message
Most of the time, when we use the term E-mail message, we relate to the E-mail message
content such as the text that is included in the E-mail message or the attachment in the E-mail
message.
In reality, each E-mail message includes an additional layer of information, which can be
described as metadata or as the data about the data.
The metadata that considers as part of the E-mail message, includes many details and
information about the specific E-mail message and a documentation of the journey that the
E-mail message undergoing begging with the source mail server, and ending with the
destination mail server that hosts the destination recipient.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 7 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Mail envelop & Mail header as a logical container for E -mail message metadata
The SMTP protocol defines two types of logical containers that will hold the metadata that
relates to a specific E-mail message:
The Mail envelope and the Mail header.

The Mail envelope is used by the mail servers who represent the sender and the recipient.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 8 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Mail header is used by the mail client (by the user).

The information that is saved in the Mail Envelope

The Mail envelope includes the following type of information:
1. Hold Information about the source mail server that represents the sender for example,
the IP address of the mail server that Initializes the SMTP session or information about a
specific security standard that the source mail server support such as DKIM.
2. Hold Information about all the mail servers who were involved in the mail flow.
3. Hold Information about the sender + recipient identity the E-mail address of the sender
and the E-mail address of the destination recipient\s.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 9 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Mail structure Mail Header & Mail Body

The mail component of E-mail message includes two parts:
1. Mail header this is an additional container that holds metadata information. If youre
wondering, why do we need to use an additional logical container for the metadata in addition
to the Mail envelope component, the simple answer is that very similar to the real-life scenario,
the
Mail envelope considers as a temporary vehicles, which is used for transporting the E-mail
message from point A to Point B.
After the E-mail, the message is accepted by the destination mail server that represents the
recipient, the mail server reads the information that appears in the Mail envelope copy most of
the information in the Mail header part and then, tearing apart the Mail envelope.
2. Mail Body the mail body is that part which includes the text and the attachment\s that was
added to the E-mail message by the person who wrote the E-mail message.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 10 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Mail header includes the following type of information:

1. Hold Information about the characters of the specific E-mail message for example, the
character set of the specific E-mail message, MIME type etc.
2. Hold Information that was copied from the Mail envelope. As mentioned, the Mail
envelope is removed by the mail server before the E-mail message is delivered to the
destination recipient.
3. Hold Information about different security checks that was performed by the destination mail
server meaning, the mail server that represents the destination recipient.
Most of the time, the mail servers who represent the destination recipient perform a security
check that designed to identify problematic mail such as Spoof E-mail, E-mail that includes
malware, spam mail and so on.
The information about the security check results, such as the SCL (spam confidence level)
value is saved to the Mail header.
Another example is a scenario in which the mail server is configured to perform validation of the
sender identity using a standard such as SPF, DKIM, DMARC and so on. The results of this
sender identity test will also be written to the Mail header.
4. Hold Information about the sender + recipient identity the information about the sender
E-mail address and the destination recipient E-mail address.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 11 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Note in a common scenario, the sender \ recipient identities (E-mail address) of the Mail
header, will be copied from the Mail envelope.
The other optional scenario is a scenario in which the Mail envelope will include the sender \
recipient identities that the sender \ recipient identities that are specified in the Mail header.

The major type of identities in mail based infrastructure

Along this article, we mention the term identity many times.
Without going into depth technical discussion, its important to define the meaning of this term
when relating to mailing infrastructure.
When relating to mail infrastructure, the simple definition of the term identity could be
translated into:

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 12 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
1.
2.
3.
4.

E-mail address
IP address
User credentials
Certificate

Regarding the subject of mail infrastructure and the SPF standard, the main identities that we
will relate to being mostly the E-mail address identity and the IP address identity.
When we say that senders want to send E-mail to a destination recipient, we relate to the E-mail
address of the sender and the E-mail address of the destination recipient.
Another type of identity is the identity of the mail server that sends the E-mail message on
behalf of a specific recipient. In this case, we relate to the identity of the mail server by as the IP
address that is used by the mail server.
Note if we want to be more accurate, there is an additional type of identity that is derivative of
E-mail address identity, which is the domain name identity. The domain name identity is
taken from the right part of the E-mail address.
Note relating to mailing infrastructure, there are other types of identities such as user
credentials and certificate. In the current article, we will not relate to this type of identities
because this subject is beyond the scope of our article.

The need to verify the identity of the sender

One of the most basic security needs in mail infrastructure is the need to verify beyond doubt
or verify with certainty, the identity of the involved parties in the mail flow session.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 13 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Note Its important to emphasize that many mail infrastructures dont support, security mail
standard for verifying the identity of external host (sender or mail server) that address their
organization.
If we want to be more accurate, when we say that we need to verify a specific identity, most of
the time, the side that has had the interest to implement this procedure is the receiving side
meaning the mail infrastructure of the destination recipient.
When external entity address the mail server that represents a specific domain (specific
recipient), and Introduces herself using a specific identity (specific E-mail address or specific IP
address), the mail infrastructure that represents the destination recipient needs to know that the
sender Is really who he claims.
For example, the basic of a Spoof E-mail or a spoofing and Phishing attacks is based on the
concept in which a hostile element address the mail server of a specific organization, and
claims that he is a legitimate organization recipient.
The be able to know if this entity is a real, legitimate recipient versus a hostile element that
camouflages itself by using the identity of a legitimate user, the mail server will need to
implement some kind of identity check for verifying the identity of the sender.
One of the most popular methods for verifying the sender identity is the SPF standard. When
using the SPF standard, the mail server that represents the destination recipient will verify the
identity of the source mail server meaning, the mail server that represents the sender by
verifying of the IP address of the source mail server IP appear in an authorized list.
Note the authorized list is implemented by an SPF record (a TXT record), that is published on
the public DNS infrastructure, and include a list of IP address for the mail servers that are
authorized to send E-mail on behalf a specific domain name.
The different identities in a simple mail flow
To illustrate this identities concept, lets use the following diagram.
In our scenario, side A wants to deliver an email message to side B.
1. The first identity (number 1) is the E-mail address that represents the user\ recipient who
wants to send the E-mail message. In our scenario, the identity of this user is
angelina@thankyouforsharing.org

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 14 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
2. The second type of identity (number 2), is implemented in a scenario in which the original
sender wants to send the E-mail message on behalf of other senders.
A classic scenario is a scenario of the assistant and the manager in which the assistant wants to
send E-mail to an external recipient on behalf of her manager.
In our specific example, the manager identity is Brad@thankyouforsharing.org
3. The third identity (number 3) is the identity of the mail server that represents the sender.
We relate to the source mail server identity by specifying the mail server IP address.
4. The fourth identity (number 4) is the identity of the mail server that represents the destination
recipient.
We relate to the destination mail server identity by specifying the mail server IP address.
In case that the destination mail server supports SPF, the verification process of the sender
identity is implemented by a verifying that the source mail server IP address is registered as an
authorized IP for a specific domain name (the domain name that appears in the E-mail address
of the sender).
In our specific scenario, the SPF verification process will check if the specific mail server is
authorized to send E-mail for the domain name thankyouforsharing.org
5. The fifth identity (number 5) is the E-mail address that represents the destination recipient. In
our example, the destination recipient is represented by the E-mail address
Bob@o365pilot.com.
Note in a real-life scenario, the mail flow could be more complicated and include additional
mail servers.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 15 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Mail Fields That Contain The Values Of Sender And Recipient Identities
In the current section, I would like to review that specific mail fields that is used by the SMTP
protocol for representing the identities of the sender and the recipient E-mail address.
As mentioned, a standard E-mail message includes two parts the Mail envelope and
the Mail header.
Each of these components uses different mail fields for representing the identity of the sender
and the recipient.
Mail envelope
(RFC 5321 | https://tools.ietf.org/html/rfc5321)
Source sender

MAIL FROM

Destination recipient

RCPT TO

Mail header
(RFC 5322 | http://www.rfc-base.org/txt/rfc-5322.txt)
Source sender

FROM

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 16 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Destination recipient

TO

Mail envelope the mail fields that hold the value of the sender and the recipient
1. The sender identity the Mail envelope uses a mail field named MAIL FROM for
holding the information about the sender identity (the sender E-mail address).
2. The recipient identity the Mail envelope uses a mail field named RCPT TO for
holding the information about the recipient identity (the destination recipient E-mail
address).

Mail header the mail fields that hold the value of the sender and the recipient
Regarding the mail component, the part which holds the information about the sender and
recipient identities is the Mail header.
1. The sender identity the Mail header uses a mail field named FROM for holding the
information about the sender identity (the sender E-mail address).
2. The recipient identity the Mail header uses a mail field named TO for holding the
information about the recipient identity (the destination recipient E-mail address).

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 17 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Relationship Between The Mail Envelope Infrastructure And The Mail
Header Infrastructure
The method in which we use two sets of different identities (Mail envelope identities and Mail
header identities) can be regarded as confusing.
For now, lets suffice basic answer that this separation was created by the SMTP protocol for
answering the needs of various business scenarios.
In some scenario, the information about the sender and recipient identities in the Mail
envelope will be identical to the information in the Mail header and in some scenario, not.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 18 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
The common scenario the identities in the Mail envelope are identical to the identities in
the Mail header.
The most common scenario is a scenario in which we use only one set of the sender and the
destination recipient identities.
For example, when a user writes a new E-mail address, his E-mail address configured
automatically in the MAIL FROM mail field, and the E-mail address of the destination recipient
is configured in the RCPT TO mail field.
Given that the destination mail server complete all the security checks and he is willing to accept
the E-mail message, the information about the sender and the recipient identities will be copied
from the Mail envelope to the Mail header.

The information from the MAIL FROM field will be copied to the Mail header field named
FROM.
The information from the RCPT TO field will be copied to the Mail header field named TO.

Another scenario the identities in the Mail envelope is not identical to the identities in
the Mail header.
In this scenario, there are different set of identities that represent the source, sender and
different identities that represent the destination recipient.
To be able to demonstrate such case, lets use the following scenario:

Suzan is the personal assistant of John.

Suzan was asked by John to send an E-mail message to one of his customers.
When Suzan creates a new E-mail message, the information about Suzan identity will be saved
in the Mail envelope in the MAIL FROM field.
The information about Johns identity will be defined in the FROM field.
In this scenario, the information stored in the MAIL FROM field in the Mail envelope, will not
be copied to the Mail header because the FROM field is already populated with the E-mail
address of John.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 19 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Additional Identities That Involved In The SMTP Mail Flow

In the current section, I would like to briefly review three additional identities, that are involved
in the SMTP mail flow.
The source mail servers identity | The HELO \EHLO command
As mentioned, the main identity of the source mail server is the server IP address.
Additional types of identity that the source mail server can provide when he Initializes SMTP
session with another mail server is the hostname + domain name which the mail server
represents.
The information that the source mail server can provide is not a mandatory requirement but
instead optional.
In case that the source mail server wants to provide this type of identity (his HOST name, the
domain name that he represents or a combination of a hostname + domain name which
described as FQDN), the mail server can provide this information after the SMTP
command HELO (or EHLO).

The Reply-to identity

The second type of identity that can be included in E-mail message is the mail field
named REPLY-TO.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 20 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
As the name implies, the purpose of this mail field is, to include information about a specific
The E-mail address that we want that the destination recipient will use if he hit the reply
button.
By default, this mail field is empty and the default value (E-mail address) that will be used in the
case that the destination recipient uses the reply option is the E-mail address that appears
in TO mail field.

The RETURN-PATH identity

The third type of identity that can be included in E-mail message is the mail field
named RETURN-PATH.
The purpose of this mail field is to contain the E-mail address, that will be used by the
destination mail server to inform the sender about a problem such as non-existing recipient,
etc.
By default, the value (the E-mail address) of the mail field RETURN-PATH is not determined by
the source sender or by the source mail server but instead, by the destination mail server.
When the destination mail server gets the E-mail message, he will extract the E-mail address
from the MAIL FROM field, and copy this E-mail address to the RETURN-PATH mail field that
will be saved as part of the Mail header.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 21 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
Most of the time, even if the source sender specifically states the value of the E-mail address of
the RETURN-PATH mail field, the destination mail server will ignore this information, and will
use the E-mail address that appears in the Mail envelope section in the MAIL FROM

Additional reading

Bounce address
What is the behavior difference between return-path, reply-to and from?

A Description Of A Standard SMTP Mail Flow And The Use Of Mail Envelope
And Mail Header
In the current section, I would like to wrap the information that we have reviewed in the
former section of the current article, so we will be able to understand better how the different
components are operating in a standard SMTP session.
Lets describe a standard SMTP session in which sender A want to send an E-mail message to
the recipient B.

The source mail server addresses the destination recipient mail server and asks his
permission to start an SMTP session (by using the SMTP command HELO or EHLO).
The destination mail server is willing to accept the request for the SMTP session.
The source mail server delivers the information that is kept in the Mail envelope.
The destination mail server looks at the information and finds the required information
about the sender identity (E-mail address) and the recipient identity (E-mail address).

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 22 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Based on the information that appears on the Mail envelope , the destination mail server
can perform a variety of security check and sender identification checks.
For example, verify if the source mail server IP address appears as blacklisted, verify if the
source mail server is authorized to represent the specific domain name and so on.
The destination mail server adds to the Mail header information about all the security
test and their result.
The destination mail server copies most of the information that appears Mail envelope to
the Mail header

Regarding the mail fields that contain the information about the identity of the sender and the
recipient, one of the two possible scenarios can occur:
Case 1
In case that the information that was sent from the source mail server doesnt include values for
the mail fields FROM and TO, the destination mail server will implement the following
procedure:

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 23 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Copy the E-mail address in the MAIL FROM field to the Mail header FROM
Copy the E-mail address in the RCPT TO field to the Mail header TO
Copy the E-mail address in the MAIL FROM field to the Mail header RETURN-PATH

Case 2
In case that the information that was sent from the source mail server includes values for one or
for all of the following mail fields FROM or TO, the destination mail server will implement the
following procedure:
In case that one of the mail fields that belong to the Mail header (FROM or TO) include a
specific value (E-mail address), the information will not be copied or in other words, will not be
overwritten by the value that appears in the Mail envelope.
Reading the mail fields that belong to the Mail header (FROM or TO) and doesnt include a
specific value (E-mail address), the information will be copied from the Mail envelope mail
fields respectively.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 24 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The end of the process will include the following task that will be implemented by the
destination mail server:

The destination mail server will remove the Mail envelope (the Mail envelope is not part
of the E-mail message that is sent to the recipient).
The destination mail server will deliver the E-mail message to the destination recipient

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 25 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

SPF Verification Process Common Scenario

In the following section, I would like to briefly review the SPF verification process that is
implemented by the destination mail server will.
To demonstrate the SPF verification process, lets use the following scenario:

Suzan is the source sender who uses the E-mail address Suzan@thankyouforsharing.org
Bob the destination recipient who uses the E-mail address Bob@thankyouforsharing.org

The source mail server that represents Suzan, addresses the mail server that represents the
destination recipient Bob.
In our scenario, the Mail envelope includes information about the sender (MAIL FROM), and
about the destination recipient (RCPT TO) but the Mail header fields (FROM and TO) are
empty.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 26 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

Given that the destination mail is configured to use SPF for verifying the sender identity, the
mail server will perform the following tasks:
1. Fetch from the sender address (MAIL FROM) the part which represents the sender domain
name. In our scenario the domain name thankyouforsharing.org
2. Write down the IP address of the source mail server.
3. Addresses DNS server and check if the domain thankyouforsharing.org have an SPF record (a
TXT record). In case that such record exists read the content of the SPF record.
4. Verify if the IP address of the source mail server appears as one of the IP addresses in the
SPF record.
5. In case that the IP address of the source mail server appears in the list, the SPF verification
test considers as successful. The meaning is that the source mail server is authorized to
send an E-mail message to thankyouforsharing.org recipients.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 27 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The More Complicated Scenario, And The Vulnerability Of SPF Verification

Method
In the following section, I would like to review the way that a hostile element can use for
implementing a spoofing or Phishing attacks to attack our organization + bypass the SPF
verification check that is implemented by our mail server.
The attack is based on the following building blocks:
1. The SMTP standard | using multiple sender identities
The SMTP protocol includes an option in which the source meaning the element that sends
the E-mail message to the destination recipient can provide two different identities:

The identity of sender A will appear on the MAIL FROM mail field (the mail field that
appears in the Mail envelope).
The identity of sender B will appear in the FROM mail field (the mail field that appears in
the Mail header).

2. SPF sender verification process | The MAIL FROM mail field and the FROM mail field

The SPF sender verification process is implemented only for the identity (the E-mail
address) of the sender who appears on the MAIL FROM
The SPF sender verification process is NOT implemented only for the identity (the E-mail
address) of the sender who appears on the FROM

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 28 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The meaning is that the SPF standard has a blind spot because the FROM identity is not
checked or verified by the SPF verification test.
The major problem is that hostile element that knows about this Deadly Cocktail, can very
easily exploit this blind spot that the SPF standard have.
The DNA of Spoof E-mail attack that exploits the SPF blind spot
The exploits of the SPF blind spot is implemented by the hostile element in the following way:
When executing a Spoofing or Phishing attacks, the main purpose of the hostile element is to
Cause the other party to perform and do something for him (to transfer money to a bank
account, click on a web link and so on).
To convince the destination recipient whom he wants to attack to do the specific action, the
hostile element needs to conceal his true identity and present himself as a legitimate user \
recipient. In other words, provide an E-mail address which the destination recipient can trust.
To succeed in executing spoofing or Phishing attack, even when the mail infrastructure that
represents the destination recipient uses sender verification procedures that are implemented
by the SPF standard.

In order to actualize this SPF bypass mechanism, the hostile element performs the following
steps:
1. Purchase a dummy domain name I use the term dummy domain because there is no real
meaning of the domain name. The purpose of the dummy domain name is to serve as a
decoy for the SPF sender verification process that will be implemented by the mail server
that represents the destination recipient.
2. Configure the required SPF record in the DNS server who hosts the dummy domain name.
3. Add the required information meaning the IP address of the mail server that he uses for
performing spoofing or Phishing attack.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 29 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Spoof E-mail attack is implemented in the following way:

The hostile element creates an E-mail message, that includes two senders E-mail addresses.

The first E-mail address (MAIL FROM) uses the legitimate domain name (the dummy
domain name). In our specific example, the MAIL FROM E-mail address is the red
domain E-mail address.
The second E-mail address (FROM) uses the domain name of the recipient, whom he
wants to attack. In our specific example, the FROM E-mail address is the green domain
E-mail address.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 30 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
Given that the mail server that represents the destination recipient support SPF, the sender
verification process will be implemented by verifying the red E-mail address (the E-mail
address that uses the dummy domain name).
Given that the hostile element

Create the required SPF record

Uses mail server that is IP address appears in the SPF record (the mail server that sends
the E-mail message using the dummy domain name)

The SPF sender dainty verification will complete successfully.

The destination mail server removes the Mail envelope , including the MAIL FORM address
and leaves the green E-mail address (the FROM E-mail address).
From the destination recipient point of view, the E-mail message was sent by the sender with
the green E-mail address. The destination recipient is not aware that the first E-mail address
that appears in the Mail envelope was removed.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 31 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The Demonstration Of How The Hostile Element Bypasses The SPF

Verification Check
To be able to demonstrate the way that hostile element can use for bypassing the SPF sender
verification check, lets use the following scenario:
A hostile element plans to attack (execute Spoofing \ spear Phishing attack) company named
o365pilot.com
The hostile element did the homework, and finds the required information about the persons
who hold a key role in the organization:

The company CIO is Bob that uses the E-mail address Bob@o365pilot.com
The company CFO is Suzan that uses the E-mail address Suzan@o365pilot.com

The hostile element is planning to send Spoof E-mail to Bob that apparently delivered from
Suzan.
The hostile element knows that the mail infrastructure of o365pilot.com implements an SPF
sender verification check for each incoming mail.
To be able to bypass the SPF sender verification check, the hostile element uses a dummy
domain name named thankyouforsharing.org
The hostile element creates the required SPF record that will use for publishing information
about the authorized mail server of the domain name thankyouforsharing.org
The hostile element creates a new email message that includes two senders E-mail address:

evil@thankyouforsharing.org
suzan@o365pilot.com

The destination recipient whom the hostile element wants to attack is Bob the company CEO.

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 32 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The hostile element mail server will address the mail server that represents the destination
recipient by starting an SMTP session, and ask him to deliver the E-mail message to the
destination recipient.
The destination mail server will perform the SPF sender verification test for the E-mail address
that appears in the MAIL FROM.
In our scenario, the mail server will try to verify the SPF record of the domain
thankyouforsharing.org
Given that the SPF record was configured correctly, the SPF sender verification test is completed
successfully, and the mail server that represents the destination recipient declares that the
sender can be trusted (that the sender is a legitimate sender).

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 33 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The destination mail server will copy the E-mail address that appears in the MAIL FROM
(evil@thankyouforsharing.org) to the mail field RETURN-PATH.
The destination mail server will remove the Mail envelope that includes the information about
the E-mail address evil@thankyouforsharing.org
The mail server will forward the E-mail message to the destination recipient (Bob).
Bob sees the E-mail message as E-mail message that was sent from suzan@o365pilot.com

Written by Eyal Doron | o365info.com | Copyright 2012-2016

Page 34 of 34 | How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2

The next article in the current article series

In the next article How to simulate Spoof E-mail attack and bypass SPF sender
verification? | 2#2, we will learn how to simulate Spoof E-mail attack and bypass SPF sender
verification.

Written by Eyal Doron | o365info.com | Copyright 2012-2016