how to simulate spoof e mail attack and bypass spf sender verification 2#2

of 19 | How to simulate Spoof E-mail attack and bypass SPF sender verification? | 2#2

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

How to simulate Spoof E-mail attack and bypass

SPF sender verification? | 2#2

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 that could be used, for verifying 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.

http://o365info.com/how-to-simulate-spoof-e-mail-attack-and-bypass-spf-sender-verification-part2-of-2/

https://il.linkedin.com/in/eyaldoron1

http://o365info.com/

http://o365info.com/how-can-hostile-element-execute-spoof-e-mail-attack-and-bypass-existing-spf-implementation-introduction-part-1-of-2/

http://o365info.com/how-can-hostile-element-execute-spoof-e-mail-attack-and-bypass-existing-spf-implementation-introduction-part-1-of-2/



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

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.






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 [email protected]

The fake identity that the hostile element will use is the identity of Suzan the company

CFO that uses the E-mail address [email protected]

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:

o [email protected]

o [email protected]




mailto:[email protected]



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 – [email protected] (the E-mail address that

belongs to the Mail envelope).

The spoofed E-mail address –[email protected] (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:




https://conemu.github.io/



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.

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

domaino365pilot.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 specific domain name).

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

Telnet <Mail server Hostname \ IP address> 25

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.


mail from: [email protected]

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 specific scenario, we want to send Spoof E-mail to the destination recipient Bob


rcpt to: [email protected]

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

Technically speaking, to be able to send the E-mail message to the destination 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 meaning, the sender and the recipient identities + the information that will appear

in the E-mail message that will be 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.


from: “Suzan the CFO” <[email protected]>

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”


to: [email protected]

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






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 AS

AP!

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






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

.

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.

To only “hint” to the fact that the specific 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.

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 message that was sent from the

“real user”. When the E-mail message is a legitimate E-mail message, the mail client such as

Outlook or OWA will display only the display name of the sender.






If you are wondering how did Outlook “notice” that he 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 was saved in the Mail header of the Spoof E-mail that was sent to Bob.

The process in which we analyze the “evidence” that was saved in the Mail header could be

considered 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 is 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.

Select the information that appears in the – internet header

Copy the information (we can use the key combination COPY + C).




https://testconnectivity.microsoft.com/



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








At the top of the screen, we can see the basic 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 –

[email protected].

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

Phishing Confidence Level

The value of the PCL (Phishing Confidence Level) is – 0.

The meaning is that the E-mail message was 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 main 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

–[email protected]

(smtp.mailfrom=thankyouforsharing.org)






Notice that when using the SPF sender check, the verification is regarding the “domain name”,

andnot for the “hole E-mail address”.

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;

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 with an additional mail field named

– RETURN-PATH.

The purpose of this mail field is to hold the E-mail address that will be used in case that the

E-mail message could not be 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 [email protected]

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.

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 [email protected]

Despite the fact that we manage to “bypass” the SPF sender verification mechanism, and

manage to send the E-mail message to the destination 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”




how to simulate spoof e mail attack and bypass spf sender verification 2#2

Documents