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. The hostile element that is aware of this SPF vulnerability, 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 to 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

The well know dilemma – should I reveal in public the SPF vulnerability? | Blackhat vs. 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 broad 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” doesn’t 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 who was appointed to serve and protect our organization’s 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 questions 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 underlying 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, which look for a solution that will enable them to verify the sender’s identity, and be sure that the sender is really who he claims to be.

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 particular 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 directs 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 is 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 or SPF 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 e-mails.
(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.)

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 imperative and considers as necessary mail security standard, that must be adopted by every organization that uses mail infrastructure.

My primary 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.

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 “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 E-mail rules, user awareness program, etc.

The implementation of such combination will allow us to build a robust 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 necessary 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.”
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 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 determine 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 excellent protection for most of the possible scenarios of Spoofing attacks.

To recap – don’t look for any easy and straightforward solution that will that magically will solve all of your problems. Be familiar with the existing risks and the current 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

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 particular 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 target recipient.

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.
• 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.

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 you’re 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 added to the E-mail message by the person who wrote the E-mail.

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 performed by the “destination mail server” meaning, the mail server that represents the target 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.

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, it’s 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:

1. E-mail address
2. IP address
3. User credentials
4. 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 originator 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 on behalf of a particular 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.

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.

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 particular domain (specific recipient), and Introduces herself using a distinct “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 vs. a hostile element that camouflages itself by using the identity of an authorized 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 checking the IP address of the origin mail server IP appear in an “authorized list.”

The different identities in a simple mail flow

To illustrate this “identities” concept, let’s 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. In our scenario, the identity of this user is – angelina@thankyouforsharing.org

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 scene of the assistant and the manager in which the secretary 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 target 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 particular 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.

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” to represent the identity of the sender and the recipient.

Component	Source sender	Destination recipient
Mail envelope (RFC 5321)	FROM	RCPT TO
Mail header (RFC 5322)	MAIL FROM	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).

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, let’s suffice basic answer that this “separation” 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.

The common scenario – the identities in the Mail envelope are identical to the identities in the Mail header.

The most common scenario is a situation 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, let’s 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 John’s 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.

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 server’s 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 mail of origin 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.

As the name implies, the purpose of this mail field is, to include information about a particular
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, which will be utilized 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.

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

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 previous section of the current article, so we will be able to understand better how the different components are operating in a standard SMTP session.

Let’s 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).
• 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, check if the mail of origin 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 doesn’t include values for the mail fields – FROM and TO, the destination mail server will implement the following procedure:

• 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 doesn’t include a specific value (E-mail address), the information will be copied from the Mail envelope mail fields respectively.

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

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, let’s 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.

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.

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 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

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 biggest 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 concrete 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.

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 implemented by the mail server that represents the destination recipient.
2. Configure the required SPF record in the DNS server which 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.

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

The hostile element creates an E-mail 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.

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 recipient destination point of view, the E-mail message was sent by the sender with the “green E-mail address”. The target recipient is not aware that the “first E-mail address” that appears in the Mail envelope was removed.

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, let’s 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 vital 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 sender’s E-mail address:

• evil@thankyouforsharing.org
• suzan@o365pilot.com

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

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 target 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 configured correctly, the SPF sender verification test is completed successfully, and the mail server that represents the target recipient “declares” that the sender can be trusted (that the sender is a legitimate sender).

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

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.