Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online

of 21 | Using sender verification for identifying Spoof mail | SPF, DKIM, DMARC,

Exchange and Exchange Online |Part 8#9

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

Using sender verification for identifying Spoof

mail | SPF, DKIM, DMARC, Exchange and Exchange

Online |Part 8#9

Spoof mail attack is implemented by a hostile element the try to spoof sender identity.

The way for dealing with a Spoof mail attack is, by implementing a procedure, which check and

verify the sender identity (verify of the sender consider as a legitimate sender of a spoofed

sender).

Using SPF, DKIM And DMARC, Exchange And Exchange Online For Verifying

Sender Identity

In the current article, we will review the way that the sender verification process is implemented

by the following infrastructures:

1. Mail sender verification standards – SPF, DKIM and DMARC.

http://o365info.com/using-sender-verification-for-identifying-spoof-mail-spf-dkim-dmarc-exchange-and-exchange-online-part-8-of-9/


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

http://o365info.com/




2. Exchange based environment – by using the sender authentication status.

3. Exchange Online (EOP) based environment – by using the feature of Phish filter

Our main focus in this article is to understand the “identity concept” of the sender, and the

specific mail fields that are used for “storing” the sender identity.

In the next article – our main focus we will review the “flow” of the sender verification process

that is implemented by each of the different methods.

The Major Public Mail Standard For Sender Verification + The Available

Option In Exchange Based Environment.

A general classification of the available sender verification methods that we can use could be:

1. Public mail standard that deals with sender verification.

In this “group,” we can relate to three major popular standards:

SPF (Sender Policy Framework).

DKIM (DomainKeys Identified Mail).

DMARC (Domain-based Message Authentication, Reporting & Conformance).

2. Exchange based environment





http://o365info.com/how-does-sender-verification-work-how-we-identify-spoof-mail-the-five-heros-spf-dkim-dmarc-exchange-and-exchange-online-protection-part-9-of-9

http://www.openspf.org/

http://www.dkim.org/

https://dmarc.org/




In this group, we can relate to a solution that can help us to implement a sender verification

process, by using information about the sender, that includes his authentication status + his

domain name (the domain name that appears on the E-mail address).

The “Exchange method” can be used only for a scenario of incoming mail in which the sender E-

mail address includes our domain name.

In this case, we can verify the sender identity by checking his authentication status.

Internal or anonymous sender

The method which we use for deciding if the sender is “valid” is – by looking at the value that is

“stored” in the X-MS-Exchange-Organization-AuthAs mail field.

Using the above mail field is relevant to any Exchange based environment, including Office 365

that is based on Exchange Online.

The concept behind this method is implemented by looking at the status of the authentication

information about the recipient – the information that is stored in the X-MS-Exchange-

Organization-AuthAs mail field.

The basic assumption is that recipient whom their E-mail address includes our organization

domain name should appear as authenticated recipient, meaning, users who provide their user

credentials.

In case that the status of the recipient whom his E-mail address includes our domain name is

“anonymous.” This is a sign that there is some “problem” with the sender identity.

3. Exchange Online based environment (EOP – Exchange Online protection) | Phish filter

EOP (Exchange Online protection) includes a method, which described as Phish filter.

The mechanism of the EOP Phish filter, is based upon a concept in which the EOP server

verifies the sender information that appears in the MAIL FROM and in the FROM field.

In case that the information is identical, the sender considers as “valid sender”.

In case that the information is not identical the sender considers as “non-valid sender.”

Note – Booth of this method can be implemented only for “incoming mail.”

In other words, we cannot use this method for “protect” our recipient’s identity in a scenario in

which our recipient sends an E-mail message to external recipients.








How exactly we define the “sender”?

1. SPF and DKIM standard

SPF and DKIM standard, define the “sender identity” by relating to the E-mail address of the

sender.

If we want to be more accurate, the SPF standard relates to the “right part” of the E-mail address

meaning, the domain name, and the DKIM standard, relates to the “whole E-mail address.”

The SPF standard relates to the sender E-mail address that appears in the MAIL

FROM mail field (the information that appears on the mail envelope).

The DKIM standard relates to the sender E-mail address that appears in the FROM mail

field (the information that appears in the mail header).








2. DMARC

The DMARC standard relies on the SPF or the DKIM standards, as the mechanism for

implementing sender verification.

The added value to the DMARC standard regarding the subject of verifying sender identity is

implemented by using an additional “layer” of tests that relate to the sender verification. In other

words, the DMARC standard performs more stringent verification tests.

For example, when we use the DMARC standard, the DMARC will check if the E-mail message

passes the SPF check. Even if the SPF check status is “pass,” the DMARC Will performs an

additional test described as “alignment,” in which he checks if the E-mail message that appears

in the MAIL FROM field is equal to the E-mail address that appears in the FROM field

Additional reading

SPF

Sender Policy Framework

Sender Policy Framework

How can I create an SPF record for my domain?

How To use an SPF Record to Prevent Spoofing & Improve E-mail Reliability

An Overview of the Sender Policy Framework

Explaining SPF

About SPF and DKIM

DKIM





http://www.openspf.org/

https://en.wikipedia.org/wiki/Sender_Policy_Framework

https://mediatemple.net/community/products/dv/204404314/how-can-i-create-an-spf-record-for-my-domain

https://www.digitalocean.com/community/tutorials/how-to-use-an-spf-record-to-prevent-spoofing-improve-e-mail-reliability

http://www.msexchange.org/articles-tutorials/exchange-server-2003/security-message-hygiene/Sender-Policy-Framework.html

https://postmarkapp.com/blog/explaining-spf

https://mandrill.zendesk.com/hc/en-us/articles/205582267-About-SPF-and-DKIM




DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail

What is DKIM? Everything You Need to Know About Digital Signatures

DKIM Explained: How to Set Up and Use DomainKeys Identified Mail Effectively

DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#5

DMARC

DMARC – FAQ

What is DMARC?

DMARC Inspector

DMARC: Monitor & secure your email delivery

A brief DMARC primer

3. Exchange based environment | Recipient authentication status.

In Exchange based environment, we can use an additional “peace of information,” that appears

on the E-mail message (mail header) that tells us if the recipient considers as authenticated

recipient or not.

One of the “forms” of Spoof mail attack is realized, is when the attacker, use “our organizational

identity” (an E-mail address that includes our domain name) for attacking our users.

In this case, we can use the information that is stored in the X-MS-Exchange-Organization-

AuthAs mail field for identifying an event of a Spoof mail attack “(spoof sender).

Our basic assumption is that each of our users should provide his user credentials.

In a scenario of Spoof mail attack, the hostile element that uses the identity of one of our

organization users, doesn’t provide ant credentials.

For example – if the sender E-mail address includes our organization domain name + the sender

considers as a non-authenticated user (anonymous), this is a “sign” for a Spoof E-mail.





http://www.dkim.org/

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

https://www.emailonacid.com/blog/article/email-development/what_is_dkim_everything_you_need_to_know_about_digital_signatures

http://www.gettingemaildelivered.com/dkim-explained-how-to-set-up-and-use-domainkeys-identified-mail-effectively

http://o365info.com/dkim-domain-keys-identified-mail-basic-introduction-part-1-of-5/

https://dmarc.org/wiki/FAQ

https://sendgrid.com/blog/what-is-dmarc/

https://dmarcian.com/dmarc-inspector/

https://postmarkapp.com/guides/dmarc

https://wordtothewise.com/2014/04/brief-dmarc-primer/




4. Exchange Online – Phish Filter

The term “Phish Filter,” describe a specific filter that is used by the EOP server for identifying a

possible event of Spoof mail. This is a Spoof E-mail identification mechanism, that exists for

Office 365 customers or for a customer who uses EOP (Exchange Online protection) as a

standalone version.

The Phish Filter mechanism that is implemented by EOP acts similar to the DMARC alignment

concept, that is implemented relating to SPF.

The EOP Phish Filter verifies that the E-mail address (sender identity) that appears in the MAIL

FROM field is identical to the sender identity that appears on the FROM field.








Where Is The Sender Identity Being Stored And How Does The Sender

Identity Verification Process Is Implemented?

1. SPF standard

The SPF sender identity verification is implemented in the following way:

The mail server that represents the destination recipient, “fetch” the domain name from the

E-mail address of the sender, who appears in the MAIL FROM field.

The destination mail server verifies the sender identity, by verifying if the source mail server is

authorized to send E-mail on behalf of the specific domain.

The verification process is implemented by using a dedicated SPF record (TXT record) that

includes the IP address of the authorized mail server\s for a specific domain.

2. DKIM standard

The DKIM sender identity verification is implemented in the following way:

The mail server that represents the destination recipient, “fetch” the E-mail address of the

sender, who appears on the FROM field.

The destination mail server verifies the sender identity by verifying the digital signature that

appears in the mail header.








3. DMARC

The DMARC standard relies on the SPF or the DKIM standards as the mechanism for

implementing sender verification.

The purpose of the DMARC standard is to – verify the results that were accepted by performing

the sender verification by the SPF or DKIM.

In case that the results are “OK” (the sender verification status is “pass”), the DMARC sender

verification process “move on” to the next step which describes as “alignment.”

Regarding the SPF result – DMARC verifies if the E-mail address that appears in the MAIL

FROM field is identical to the E-mail address that appears in the FROM field.








Regarding the DKIM result – DMARC verifies if the DKIM selector domain name is identical to

the domain name of the sender.

Note – the DMARC standard includes additional features and components that extend the

management of sender verification tasks.

For example – the DMARC DNS record, include “instruction” to “another mail infrastructure”, in

case that they identify E-mail messages that include our domain name as spoof E-mail.

The “instruction” includes our recommendation regarding “what to do this E-mail message” such

as ignore, quarantine or block.

4. Exchange based environment | recipient authentication status.

The “sender” that addresses Exchange server could be

1. Any sender from any organization that asks to send E-mail message recipient hosted on the

Exchange server

2. An Exchange user whom his mailbox is hosted on an Exchange

In a scenario in which the “sender” use E-mail address, that includes the domain name that is

hosted on the Exchange server, the basic assumption is – that this is an “Exchange user” that has

an Exchange mailbox, and for this reason, this “user” should prove his identity by providing user

credentials.








The information about the authentication process is saved by Exchange in a dedicated mail field

named – X-MS-Exchange-Organization-AuthAs

If the user provides his credentials, the authentication status of the recipient is “internal.”

If the user didn’t provide his credentials, the authentication status of the recipient is

“anonymous.”

In a scenario in which a sender “claim” that he belongs to the Exchange organization, meaning

that he uses the E-mail address, that includes the domain name that is hosted at Exchange but

the sender doesn’t provide his credentials; this is a sign that the sender is probably a spoofed

sender.

In other words, the status of the sender who is saved in the

X-MS-Exchange-Organization-AuthAs field appears as anonymous.

5. Exchange Online – Phish Filter

EOP (Exchange Online protection) includes a built-in filter mechanism (Phish Filter) which was

created to identify an event of an E-mail message that has a high chance of being Spoof mail.

The EOP Phish Filter work in a similar way as the DMARC alignment concept that is implemented

relating to SPF.

The EOP Phish Filter verifies that the E-mail address (sender identity) that appears in

the MAIL FROM is identical to the sender identity that appears on the FROM mail field.

If there is a difference, the E-mail message will be “stamped” using a warning message that will

notify the user, that this E-mail message could be a Spoof mail.








Major Differences Between Sender Verification Mail Standard And Exchange

Based Solutions.

As mentioned, when we go to the “Spoof E-mail attack war,” there is a variety of weapons to

choose from.

Some of these “weapons,” are public mail standards that can be adapted by any mail

infrastructure, and some of them can be used only in the case that the mail infrastructure is

based on Exchange mail server or Exchange Online (Office 365 customers).

The major differences between the Exchange based solutions versus the “public mail standard”

are:

1. DNS configuration settings

When we use the Exchange based mechanism for identifying an event of Spoof E-mail, there is

no need for using additional configurations such as DNS records.

2. Incoming mail flow

The Exchange based solution’s mechanism for identifying an event of Spoof mail can be

implemented only regarding scenarios of – incoming mail.

The meaning is – events in which hostile element try to “attack” the Exchange recipient.

Using the SPF, DKIM and DMARC for protecting ourselves from a scenario in which hostile

element uses our identity.

Just as short reminder, the problem of “Spoof mail” can be realized in two main flavors:








Case 1 – a scenario in which hostile element attacks our user by sending them

Spoof mail.

Case 2 – a scenario in which hostile element, uses our organizational identity (E-mail address

that includes our domain name) for attacking other organizations.

When using a public mail standard such as SPF and DKIM, we have the ability to “announce”

other organizations, if a specific E-mail message in which the sender uses our domain name, is a

legitimate E-mail message or not.

For example, when using SPF, we can inform other organizations, which are the authorized mail

server that can send an E-mail message on behalf of our domain name.

In addition, some mail stand such as SPF and DMARC enables us to instruct another mail

infrastructure “what to do” in case that the E-mail message that sent seemingly by one of our

recipients didn’t send from an authorized mail server.

The Exchange and the Exchange Online options don’t include a mechanism that can be used in

such scenarios of outbound mail.

What Is The Best Option For Identifying Of Spoof E-Mail?

Without knowing you personally, I’m pretty sure that after reading all the above information, the

following question could appear in your mind:

Q: What is the bottom line? Which is the “right tool” for my organization?

A: The answer that I have included a couple of parts:








Better something than nothing

It’s better to start with the implementation of at least one mail sender verification standard

versus “not doing anything,” and leave your organization mail infrastructure exposed to a variety

of risk and dangers.

Using a specific sender verification mechanism versus a combination of more than one

mechanism

Theoretically, we can be satisfied with only one ” chosen” mail standard or mechanism

such as – SPF, DKIM or one the Exchange option.

In reality, the “true” solution, will need to be based on more than one standard because, the

different standard completes each other, and each of them covers other or different type Spoof

mail scenarios.

Baby step | Step by step

The best practice is to start with a simple sender verification standard, and only after we feel

comfortable, “move on” to the next step in which we implement an additional standard.

My opinion is that the simplest option is – to start with the implementation of the SPF standard

because the SPF standard can be described as a relatively easy standard to implement.

In case that your mail infrastructure is based on Exchange infrastructure, it’s recommended also

to add the “additional layer,” in which we use Exchange rule, that identifies an event in which

incoming mail includes the sender who has our E-mail address but doesn’t provide user

credentials.

Note – if you want to read more information about the way for how to implement

the “Exchange option” using a Spoof E-mail rule, you can read the article – Detect

spoof E-mail and send an incident report using Exchange Online rule (Learning

mode) |Part 2#12





http://o365info.com/detect-spoof-e-mail-and-send-an-incident-report-using-exchange-online-rule-learning-mode-part-2-of-12/






So, what is the best combination of sender identification standard \options?

The answer is – that there is no specific “cocktail” that can be described as the “best cocktail”.

For example – a reasonable question could be-

Q1: Why not to use all the available options?

Q2: Can we use the concept of more the better?

A: The answer is “Yes,” and “No.”

Theoretically, it’s better to use all the available options that we can use for identifying events of

Spoof E-mail, but we should not forget that each of these “standard” or “mechanism” requires

its own resources.

The resource that will need to be allocated to:

Learning and implementing the required configuration settings for each of the “sender

verification solutions”








The ongoing tasks such as – monitoring the events of a Spoof mail that were “captured”

by the specific standard – the need to review and examine the E-mail items that was

identified as Spoof mail and the need to decide what to do with this E-mail item.

The Secret Location Of The Sender E-Mail Address

As mentioned, the mail standard that verifies the sender identity verifies the information about

the E-mail address of the sender.

The SMTP protocol defines two mail fields, that were created for storing information about the

identity of the sender’s meaning, the E-mail address of the sender.

One type of “information” about the sender, is kept in a mail field named – MAIL

FROM that is “located” in the mail envelope.

One type of “information” about the sender, is kept in a mail field named – FROM that is

“located” in the mail header.

The mail envelope considers as a “temporary data store” that serves as a “logical container” for

data, in the phase of the SMTP session in which two mail servers communicate.








The mail envelope concept is very similar to a “psychical mail envelope.”

After the E-mail, the message is accepted by the destination mail server that represents the

destination recipient, and after the destination mail server reads all the required information that

is stored in the mail envelope, the mail envelope is “destroyed.”

In this phase, two optional questions can appear in our mind:

Q1: Why do we need to use two different mail field for storing the information about the sender

identity (the sender E-mail address)?

Q2: Why are you telling me all of this information? How this information related to the topic in

question?

A1:

The main purpose of the “sender information” that appears in the mail envelope

(MAIL FROM) is to serve as a “return mail” address.

“Return mail” address used by the destination mail server, in a scenario in which the E-mail

message could not be sent to the destination recipient, and the mail server will need to “return

the mail” to his original sender.

The main purpose of the “sender information” that appears in the mail header

(FROM) is to inform the destination recipient, who is the sender that “wrote” the E-mail

message.

In some scenarios, the sender who appears in the MAIL FROM (the mail envelope) can

be different from the sender identity that appears in the FROM field (the mail header).

A2: The reason that I tell you this “boring information” is, because the mail standard – SPF and

DKIM use this the information stored in this field (MAIL FROM and FROM) for getting the

information about the sender identity, and implementing the sender verification procedure.








Note- the SPF standard process is configured to verify the sender information that is stored in

the MAIL FROM field only.

In other words, the SPF sender verification process, will not relate to sender information stored

in the FROM field. This is a built-in weakness that can be exploited by hostile elements.

If you want to read more information about this vulnerability, you can read the article – How can

hostile element execute Spoof E-mail attack and bypass existing SPF implementation? |

introduction | 1#2

The E-mail message components – mail envelope, the mail and the mail header

In the following diagram, we can see the structure of a standard E-mail message that includes

the two parts: mail envelope and the mail.

In the next diagram, we can see the structure of “mail component”, which includes also two

parts: the “mail part” that includes the mail body, and the mail header.





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






Mail envelope – the “mail fields” that hold the value of the sender and the

recipient

The mail envelope uses the following fields for storing information about the sender identity

and the destination recipient identity:

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.

The mail header, uses the following fields for storing information about the sender identity and

the destination recipient identity:

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








Additional reading

How to review and mitigate the impact of phishing attacks in Office 365

The common types of spear phish we see today

How antispoofing protection works in Office 365

Email authentication should work out of the box and we should not rely upon domain owners

to do it themselves

The next article in the current article series is

How does sender verification work? (How we identify Spoof mail) | The five hero’s SPF,

DKIM DMARC, Exchange and Exchange Online protection | Part 9#9





https://blogs.technet.microsoft.com/office365security/how-to-review-and-mitigate-the-impact-of-phishing-attacks-in-office-365/

http://blogs.msdn.com/b/tzink/archive/2015/12/28/the-common-types-of-spear-phish-we-see-today.aspx

http://blogs.msdn.com/b/tzink/archive/2016/02/23/how-antispoofing-protection-works-in-office-365.aspx

http://blogs.msdn.com/b/tzink/archive/2016/01/22/email-authentication-should-work-out-of-the-box-and-we-should-not-rely-upon-domain-owners-to-do-it-themselves.aspx

http://blogs.msdn.com/b/tzink/archive/2016/01/22/email-authentication-should-work-out-of-the-box-and-we-should-not-rely-upon-domain-owners-to-do-it-themselves.aspx



Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online

Documents

Transcript of Using sender verification for identifying spoof mail spf, dkim, dmarc, exchange and exchange online