How to simulate Spoof E-mail attack and bypass SPF sender verification? | 2#2 5/5 (2)

15 min read
In the current article, we will demonstrate how to simulate Spoof E-mail attack, that will bypass existing SPF sender verification implementation.

The current article series include two articles.
The former article is – How can hostile element execute Spoof E-mail attack and bypass existing SPF implementation? | introduction | 1#2

Disclaimer

For the avoidance of any doubt, the purpose of this demonstration should not be applied, in any form or manner whatsoever for exploiting and attack organizations.

The only purpose of this article is – to provide you a way to verify the mail security settings of your existing mail infrastructure, so you will be able to be aware of existing vulnerability in your mail infrastructure and find the required solutions for mitigating and blocking the “holes” that can and probably will be exploited by a variety of hostile elements.

THIS CODE AND ANY ASSOCIATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK OF — USE, INABILITY TO — USE, OR RESULTS FROM THE — USE OF THIS CODE REMAINS WITH THE — USER.

How to simulate Spoof E-mail attack and bypass SPF sender verification | Step by Step

Implement the required necessary arrangements

To be able to achieve the two main goals:

  • Succeed in simulated Spoof E-mail attack
  • Succeed on bypass SPF sender verification check

We have made these preliminary preparations:

  1. Purchase a dummy domain name – the purpose of the dummy domain name is to serve as a decoy for the SPF sender verification process that will implement 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.

In the following screenshot, we can see an example for the SPF (a TXT record) that was created for the “dummy domain name” –thankyouforsharing.org

The IP address that appears is the mail server IP address that is used by the hostile element for sending the Spoof E-mail to the destination recipient.

Simulating Spoof E-mail attack and bypassing the SPF verification check -01

Our spoof E-mail attack simulation scenario characters

To be able to demonstrate the way that hostile element can use for implementing Spoof E-mail attack + 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 recipient whom the hostile element seeks to attack is Bob, the company CEO that uses the
    E-mail address bob@o365pilot.com
  • The fake identity that the hostile element will use is the identity of Suzan the company CFO that uses the E-mail address suzan@o365pilot.com
  • 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 will use an E-mail message that includes two sender’s E-mail address:
    • evil@thankyouforsharing.org
    • suzan@o365pilot.com

Using an SMTP Telnet session for executing the Spoof E-mail attack

In the following section, we will review how to run a simulation of Spoof E-mail attack in which we use an SMTP telnet session for executing the attack.

The telnet client that we use

Technically, we can use the built-in Windows telnet client, but this telnet client is a little limited and not so convent.

Personally, I would like to work with a dedicated telnet application. There are a variety of free telnet clients. In our specific scenario, I use a very nice telnet client named – conemu

The two parts of the SMTP telnet session

It’s important to me to emphasize the “two parts” of the SMTP telnet session:

  • The first part (A), is the part in which we sue the SMTP commands that are related to
    the Mail envelope part.
  • The first part (B), is the part in which we sue the SMTP commands that are related to
    the Mail header.

The set of two identities that we use in the SMTP telnet session

To be able to bypass the SPF sender check, we will use a set of two identities:

  • Dummy E-mail address identity – evil@thankyouforsharing.org (the E-mail address that belongs to the Mail envelope).
  • The spoofed E-mail address –bob@o365pilot.com (the E-mail address that belongs to the Mail header).

In the following screenshot, we can see the “complete SMTP telnet session” that simulates the Spoof E-mail attack:

Simulating Spoof E-mail attack and bypassing the SPF verification check -03

  • The purpose of the first part is to “occupy” the destination mail server with “non-useful” information that will help us to present ourselves as a legitimate organization.
  • The purpose of the second part is to send the Spoof E-mail that includes the information about the spoofed sender.

Simulating Spoof E-mail attack and bypassing the SPF verification check -03-B

In the following section we will provide, a “step by step” description of the SMTP telnet commands that we use:

0. Addressing the destination mail server

Using SMTP telnet session for communicating the destination mail server

To be able to address the “destination mail server” meaning, the mail server that represents the domain which we want to attack (In our example, the mail server that represents the domain o365pilot.com), we need to know the hostname or the IP address of the destination mail server (the hostname that appears in the MX record for the particular domain name).

The telnet commands that we use for starting a SMTP session with another mail server is:

Telnet <Mail server Hostname \ IP address> 25

Simulating Spoof E-mail attack and bypassing the SPF verification check -02

1. Initialize the SMTP session

The first command that we use is the HELO command which we use for initializing the session with the remote mail server.

Technically speaking, we don’t have to provide any additional info besides the HELO command, but in our scenario, our main purpose is to present ourselves as a legitimate mail server that represents the domain name – thankyouforsharing.org

For this reason, we will specify the domain name after the helo command.

The command syntax that we use is

helo thankyouforsharing.org

2. Provide the sender identity

In this part, we provide the sender identity (the sender E-mail address) by using the
command: MAIL FORM

Note – notice that the sender identity is related to the “dummy domain” that we use. This is not the sender identity that we want to provide to the end user, but instead, just a temporary identity that will mislead the destination mail server that performs the SPF verification test.

The command syntax that we use is

mail from: evil@thankyouforsharing.org

3. Provide the recipient identity

In this part, we provide the recipient identity (the sender E-mail address) by using the command: RCPT TO:

In our scenario, we want to send Spoof E-mail to the destination recipient Bob

The command syntax that we use is

rcpt to: bob@o365pilot.com

Simulating Spoof E-mail attack and bypassing the SPF verification check -04

In this stage, we have “finished” the Mail envelope phase.

Technically speaking, to be able to send the E-mail to the target recipient, we don’t need to provide additional “identity information.”

The purpose of this phase is, to provide the required information for “building” the Mail header part. The meaning is – the sender, and the recipient identities + the information that will appear in the E-mail message that sent to the destination recipient.

Just a quick reminder, in the mail header phase, we use the command FROM for specifying the sender identity, and the command TO specifying the destination recipient identity.

4. Initializing the Mail header section

To be able to “signal” the destination mail server that we want to start the Mail header phase, we use the command –

data

5. Providing the spoofed identity of the sender

In this step, we provide the “apparently identity” of the company CFO – Suzan

To make the spoof identity look like a reliable and trusted identity in the eyes of the destination recipient, we will provide two separated parts of “Susan’s identity” –

Suzan Display name + Suzan E-mail address

  • The display name of the spoofed sender is the string that appears between the quotation marks.
  • The spoofed E-mail address of the sender is the E-mail address between the angle brackets.

The command syntax that we use is

from: “Suzan the CFO” <Suzan@o365pilot.com>

6. Providing the identity of the destination recipient

Technically speaking, there is no mandatory need for providing the E-mail address of the destination recipient. The reason that we provide the E-mail address is that when using telnet session if the TO the field is empty, the information about the recipient displayed as – “Undisclosed recipients

The command syntax that we use is

to: bob@o365pilot.com

In this phase, we will define the E-mail message subject + the mail content

Simulating Spoof E-mail attack and bypassing the SPF verification check -05

7. Providing the E-mail message subject

To be able to define the E-mail content message that will include subject + the text that we want to send, we use the command subject: + the required text.

In our specific scenario, we will use the subject command + the following text

subject: Hello Bob, an important message,

8. Add a space between the subject in the mail body

To be able to add the required mail text that will appear in the E-mail message, we need to add a space between the subject command and the text that we will add.
Use the

ENTER

key for creating the required space.

9. Providing the E-mail message text

In our specific scenario, we will add the following text string

Please transfer to the following bank account – 4589865, the amount of million dollars ASAP!

10. “Ending” the SMTP session with the mail server

To be able to “end” the SMTP session, we use the point character.

.

Simulating Spoof E-mail attack and bypassing the SPF verification check -06

The result of our Spoof E-mail attack

In the following screenshot, we can see the Spoof E-mail that was sent to our
destination recipient – Bob. Notice that the E-mail message looks like a legitimate E-mail message.

Simulating Spoof E-mail attack and bypassing the SPF verification check -07

To only “hint” to the fact that the particular E-mail message is not a “standard E-mail message” (Spoof E-mail in our scenario) is that way that Outlook client use for displaying the information about the sender identity.

When we look in depth at the “top part” of the E-mail message, we can notice that the information about the sender includes the E-mail message of the sender.

Simulating Spoof E-mail attack and bypassing the SPF verification check -08

This behavior doesn’t consider as a “normal behavior” of a legitimate recipient.

In the following screenshot, we can see an example of an E-mail that sent from the “real user.” When the E-mail is a legitimate E-mail message, the mail client such as Outlook or OWA will display only the display name of the sender.

Simulating Spoof E-mail attack and bypassing the SPF verification check -09

If you are wondering how did Outlook “notice” that the E-mail message was sent by a “standard organization recipient,” the answer is that when we use the telnet session, we provide the spoofed E-mail address, but we didn’t provide any user credentials.

For this reason, the recipient is identified as Anonymous (the information is saved in a mail field named – X-MS-Exchange-Organization-AuthAs).

When Outlook or OWA mail client recognized a scenario in which the sender considers as Anonymous, the information about the sender will include the E-mail address of the source sender.

Analyzing the information of the Spoof E-mail by using email analyzer

In the following section, we will review that way that we can use for analyzing the information that saved in the Mail header of the Spoof E-mail that sent to Bob.

The process in which we examine the “evidence” that saved in the Mail header could consider as a reverse engineering process of a forensic process in which we use the existing evidence for draw conclusions about the events that happened in the past

The information that saved in the Mail header includes many important details and “hints” that we can use for understanding better the events that occurred during processing of the Spoof
E-mail attack simulation.

Technically, we can analyze the information in the E-mail message header by using a simple text editor such as notepad, but the most preferred option is to use a mail analyzer.

In our specific example, we will use the Microsoft web tool the ExRCA (Exchange remote connectivity analyzer) for analyzing the information that was saved in the mail header.

How to “extract” the mail header information from the E-mail message?

They get the information this is “stored” in the E-mail message (the Spoof E-mail that was sent to the recipient Bob), we need to choose the specific E-mail message, choose the File menu
and then the option – Properties.

Simulating Spoof E-mail attack and bypassing the SPF verification check -10

  • Select the information that appears in the – internet header
  • Copy the information (we can use the key combination COPY + C).

Simulating Spoof E-mail attack and bypassing the SPF verification check -11

We will access the ExRCA (Exchange remote connectivity analyzer) website by using the following URL address: https://testconnectivity.microsoft.com/

  • Select the tab – Message Analyzer
  • In the empty text box, paste the information that was copied in the former step (we can use the key combination COPY + V).
  • Click on the Analyze headers button

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -01

At the top of the screen, we can see the information about the identity of the sender and the recipient.

In the summary section (A), notice that the information about this “identities” is the information that we have provided in the second phase of the telnet session, which we described as the “Mail Header phase”.

As mentioned, the mail server removes the Mail envelope that includes information about the sender identity that stored in the MAIL FORM field.

In our specific scenario, the E-mail address that we use in the MAIL FORM field was – evil@thankyouforsharing.org.

The information about this E-mail address was removed in the mail header will include information about the sender E-mail address that appears in the TO mail field.

The “sender information” that appears, is the information that is seen by the destination recipient (Bob). In other words, from Bob’s perspective, the E-mail address was sent by Suzan the company CFO.

In the received header section (B), we can see information about the mail server that was involved in the mail flow.

The information about each of the mail servers includes the IP address of the mail server and in case that the mail server provides his “name” (the term “name” could translated to hostname, the domain name of the FQDN).

In our specific scenario, the mail server that we use for simulating the Spoof E-mail attack provides his name – thankyouforsharing.org

The information about the mail server hostname was provided by us in the SMTP telnet session, in the begging of the session when we use the HELO command.

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -02

Phishing Confidence Level

The value of the PCL (Phishing Confidence Level) is – 0.
The meaning is that the E-mail message not recognized as phishing or spoof E-mail.

Authentication-Results

In the section named – Authentication-Results, we can see the following information:

spf=pass (sender IP is 212.25.80.239) smtp.mailfrom=thankyouforsharing.org

The meaning of this information is that, from the point of view of the destination mail server that performs the SPF sender verification test, the check completes successfully (spf=pass).

Just to remind you, one of our primary goals in this “Spoof E-mail attacks simulation” was to prove that we can bypass existing SPF protection implementation.

The mail server (the mail server that hosts the recipient whom we want to attack) “inform” us, that he checks the E-mail address that appears in the MAIL FORM field that in our scenario was – evil@thankyouforsharing.org

(smtp.mailfrom=thankyouforsharing.org)

Notice that when using the SPF sender check, the verification is regarding the “domain name”, and not for the “hole E-mail address.”

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -03

Received-SPF

In the section named – Received-SPF, we can see an additional information:

We can see that the destination mail server (the mail server that host Bob) informs us that the mail server that represents the domain name thankyouforsharing.org, consider is a legitimate mail server – thankyouforsharing.org designates 212.25.80.239 as permitted sender.

Pass (protection.outlook.com: domain of thankyouforsharing.org designates 212.25.80.239 as permitted sender) receiver=protection.outlook.com; client-ip=212.25.80.239; helo=thankyouforsharing.org;

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -04

As we have already learned, the destination mail server removes the Mail envelope after he finishes the required procedure for accepting the E-mail message.

So theoretically, there is no information about the sender who was mentioned in the Mail envelope (the MAIL FROM field).

This assumption is correct, apart from one exception: the RETURN-PATH field.

The SMTP standard definition that the responsibility of the destination mail server is – to “fetch” the E-mail address that appears in the MAIL FORM field and copies this E-mail address to the RETURN-PATH field.

The destination mail server “wipe out” information that appears in the Mail envelope, but one thing that the destination mail server does before he removes the Mail envelope is – copy the information that appears in the MAIL FORM field to an additional mail field named – RETURN-PATH.

The purpose of this mail field is to hold the E-mail address that will used in case that the
E-mail message could not sent to the destination recipient.

In case that the destination mail server will need to notify the “source sender” about some problem, the NDR message will be sent to this E-mail address (the E-mail address that was registered as the RETURN-PATH).

In our scenario, the E-mail address (the “dummy E-mail address”) that appear in the mail envelope was evil@thankyouforsharing.org

The destination mail server copied this E-mail address, and the result is that this E-mail message populates the field RETURN-PATH.

In other words – the only “evidence” that we have for the “trick” that was implemented by the hostile element is the information that is stored in the RETURN-PATH field.

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -05

X-MS-Exchange-Organization-AuthAs – authentication versus non-authenticated sender

The last detail that I would like to review is the part in which we classify the source sender as “know recipient” or anonymous sender.

In our scenario, the hostile element spoofs the identity of a legitimate organization user by presenting himself as suzan@o365pilot.com

Despite the fact that we manage to “bypass” the SPF sender verification mechanism, and manage to send the E-mail message to the target recipient mailbox, the sender didn’t provide user credentials.

For this reason, the sender was classified as Anonymous.

This information about this “observation”, can help us to identify and detect E-mail message that manages to bypass our “SPF wall.”

Simulating Spoof E-mail attack and bypassing the SPF verification check –analyzing the result by using EXRCA -06

Now it’s Your Turn!
It is important for us to know your opinion on this article

Summary
Article Name
How to simulate Spoof E-mail attack and bypass SPF sender verification? | 2#2
Description
In the current article, we will demonstrate how to simulate Spoof E-mail attack, that will bypass existing SPF sender verification implementation.
Author
Publisher Name
o365info.com
Publisher Logo
Print Friendly

Related Post

Please rate this

Eyal Doron on EmailEyal Doron on FacebookEyal Doron on GoogleEyal Doron on LinkedinEyal Doron on PinterestEyal Doron on RssEyal Doron on TwitterEyal Doron on WordpressEyal Doron on Youtube
Eyal Doron
Share your knowledge.
It’s a way to achieve immortality.
Dalai Lama

8 Responses to “How to simulate Spoof E-mail attack and bypass SPF sender verification? | 2#2”

  1. Gaurav Sukhdeve Reply

    Lovely article series, very impressive with the content. Less typos would be even better 🙂

  2. This is the best article that is available on internet for now. Excellent Job…. now, how do i stop this from happening to me ?
    Any reference to an article is much appreciated.

  3. There is a way to combat this but it requires a “intelligent” mail gateway in front of your exchange server, one that allows you to write inbound processing rules. I can’t speak for every gateway out there, so please do not ask me specifics on yours, ask the vendor.

    Essentially you have to write a rule that says check all of the following:

    Checks
    1. The from field contains your domain
    2. The x-sender field does NOT contain your domain

    Action: drop, quarantine or forward (I personally choose forward just in case it is a legit external campaign)
    Make sure it is at the top of your rule processing hierarchy.

    Now theoretically, if you enable SPF checking as well, it will become nearly impossible to bypass this. Because a spammer will never use a traceable server back to them. I say nearly, only because if they take over a valid smtp server and start relaying email thru it using that servers domain published in SPF, then of course it can bypass the rule…. well almost

    THEY would have to realize that you have a rule in place and would have to create a x-sender email that looks like this: you=yourdomain.com@TheirLegitSPFDomain.com

    Given that most spammers are using canned programs and rogue open relays, this will significantly reduce it.

    Tip though: if you don’t have SPF checks enabled and want to do it willy nilly, DON’T. If you run a gateway for a business, spend a little time to check who you do regular business and see if they not only have a SPF record, but make sure it is configured properly. (technically there should be 2 records published, one for SPF and the other for SenderID)… too many times I have seen someone enable SPF and then all of a sudden their C-level folks are screaming because business email stops. Since somehow in this day an age, people still can’t figure out how to write SPF/SenderID records. But you can be a hero if you help them!

    Cheers and good luck

  4. UPDATE: Managed to get it to work, so once again great tutorial!

    However it is simply impossible to spoof a gmail address while bypassing the spf sender verification.

    Any idea why?

  5. How do I send a spoofed email to a google email address? I have seen free online tools that can make it work, but those tools do not bypass spf sender verification, and therefore the email ends up in the spam folder.

    Ive used every single google/gmail mx hostname, but I just cant manage to find out a way how to send a spoofed email to a gmail account.

  6. Hello EYAL DORON, I need some help in regards to the very first step in your method.

    “Purchase a dummy domain name – the purpose of the dummy domain name is to serve as a decoy for the SPF sender verification process that will implement by the mail server that represents the destination recipient.
    Configure the required SPF record in the DNS server which hosts the dummy domain name.
    Add the required information meaning the IP address of the mail server that he uses for performing Spoofing or Phishing attack.”

    How do I configure the required SPF record in the DNS server, and how do I add the IP address of the mail server that the person uses?

    This seems to be the issue as to why I cannot manage to send an email to a Gmail address. As of now, I can currently only manage to get your tutorial to work for sending a spoofed email to a Hotmail/Outlook email.

    Thank you.

  7. can anyone provide me with a list of domains that get the SPF pass ?
    thank you

  8. Hexamail Guard can help you prevent such spoof attacks before they reach Exchange or Office 365 – it intercepts the email and compares the SMTP envelope Sender (MAIL FROM) to the MIME From: field and can optionally block email if they do not match for all domains or specific domains. This is just one of many antispoofing measures we employ!

Leave a Reply

Your email address will not be published. Required fields are marked *