Using Sender Verification For Identifying Spoof Mail SPF, DKIM, DMARC, Exchange and Exchange Online Part 8#9 PDF

Page 1 of 21 | Using sender verification for identifying Spoof mail | SPF, DKIM, DMARC,
Exchange and Exchange Online |Part 8#9
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.
Written by Eyal Doron | o365info.com | Copyright 2012-2016
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
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 Email 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-ExchangeOrganization-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 recipients 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
DKIM
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
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-OrganizationAuthAs 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, doesnt 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.
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 didnt 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 doesnt 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 solutions 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 didnt send from an authorized mail server.
The Exchange and the Exchange Online options dont 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, Im 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
Its 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, its 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 doesnt 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
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 beQ1: 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, its 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 senders 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.
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 heros SPF,
DKIM DMARC, Exchange and Exchange Online protection | Part 9#9

Using Sender Verification For Identifying Spoof Mail SPF, DKIM, DMARC, Exchange and Exchange Online Part 8#9 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Using Sender Verification For Identifying Spoof Mail SPF, DKIM, DMARC, Exchange and Exchange Online Part 8#9 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

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

Exchange and Exchange Online |Part 8#9

Using sender verification for identifying Spoof

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

SPF (Sender Policy Framework).

2. Exchange based environment

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

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

How exactly we define the sender?

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

Sender Policy Framework

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

DomainKeys Identified Mail (DKIM)

3. Exchange based environment | Recipient authentication status.

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

4. Exchange Online Phish Filter

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

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

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

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

5. Exchange Online Phish Filter

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

Major Differences Between Sender Verification Mail Standard And Exchange

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

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

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

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

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

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

The Secret Location Of The Sender E-Mail Address

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

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

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

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

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

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

S-ar putea să vă placă și