How Does Sender Verification Work - How We Identify Spoof Mail) SPF, DKIM DMARC, Exchange - Part 9#9 PDF

Page 1 of 26 | How does sender verification work?
(How we identify Spoof mail) | The five

heros SPF, DKIM DMARC, Exchange and Exchange Online protection | Part 9#9
How does sender verification work? (How we

identify Spoof mail) | The five heros SPF, DKIM
DMARC, Exchange and Exchange Online protection |
Part 9#9
The process of sender verification, enables us to distinguish between a legitimate sender

versus an attacker who spoof his identity.
In the current article, we will review in details the five available methods that we can use for
fighting the phenomena of Spoof mail attack.
Written by Eyal Doron | o365info.com | Copyright 2012-2016
Page 2 of 26 | How does sender verification work? (How we identify Spoof mail) | The five
The Five Heros SPF, DKIM DMARC, Exchange And Exchange Online
Protection
SPF, DKIM and DMARC are public mail standard that was created for the purpose of verifying
sender identity.
Additional options that are available for us:
Using Exchange server rule that will identify an event in which hostile element uses the
organization Identity to attack organization users hosted by the Exchange.
Using the Exchange Online protection option of Phish filter.
How Does The SPF Standard Protect Us From Spoof E-Mail Scenario?
The SPF standard is based on a concept in which we draw a conclusion about the sender, by
verifying information about his mail server.
If we want to be accurate, when using SPF, we relate to the right part of the E-mail address
meaning the domain name.
The mail server that represents the sender should be considered as an authorized mail server
for a specific domain name (the domain name that appears in the E-mail address of the sender).
The sender verification process that is implemented by the destination mail server
(the mail server that represents the destination recipient) is performed by verifying the
integrity of the sender mail server.
The mail server that represents the sender should be considered as an authorized mail server
for the specific domain name.
The information about the authorized mail server that can send E-mail on behalf of the domain
is published in the SPF record (a TXT record), which include a list of IP address or host names of
the mail server that are authorized to send E-mail on behalf of the domain.
The sender identity store

When using SPF, the sender identity that is checked, is the E-mail address that appears in the
mail envelope in the MAIL FROM field.
SPF sender verification processes flow
The SPF sender verification protocol, uses the following mechanism for verifying the identity of
the sender:
When the E-mail message reaches to the destination mail server, the mail server fetch from the
mail envelope (MAIL FROM field) the information on the sender E-mail address.
The destination mail server relates to the domain name of the E-mail address (the right part of
the E-mail address).
In our specific example, the domain name of the sender is o365info.com
The mail server addresses the DNS server who hosts the domain name o365info.com and looks
for information on the SPF record that is hosted under the o365info.com domain name.
The SPF record is implemented as a TXT record that includes relevant information about the mail
server that is authorized to send an E-mail message on behalf of the domain o365info.com .
In our specific example, the mail server verifies if the IP address of the source mail server (the
mail server that represents the sender) appear in the SPF record.
Case 1 in case that the IP address of the source mail server, appear as listed on the SPF
record, the SPF verification test result is Pass meaning; the sender is a legitimate sender
because his mail server is considered as a legitimate mail server.
Case 2 in case that the IP address of the source mail server, doesnt appear as listed on the
SPF record, the SPF verification test result is Fail meaning; the sender is not a legitimate
sender because his mail server is not a legitimate mail server.
SPF | The scenario in which E-mail message is classified as Spoof E-mail

In the following diagram, we can see the logic of the SPF verification process regarding the
scenario of Spoof mail:
In case that the mail server IP address that send the E-mail message on behalf of the
sender doesnt appear in the SPF record for the specific domain, the conclusion that the E-mail
message is a Spoof mail (spoof sender).
Disadvantage of SPF standard

The SPF method has a significant disadvantage that relates to the mail field that is verified in the
SPF verification process.
The SPF verification process fetch the E-mail address that appears in the mail envelope in
the MAIL FROM
The SPF verification process, doesnt relate or check the E-mail address that appears in the
mail header in the FROM
This method can be easily exploited by hostile elements, that can bypass the SPF verification
mechanism by providing two different identities.
1. The identity that in the MAIL FROM field will be a legitimate identity.
2. The identity that in the FROM field will be a spoofed identity.
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
articles:
How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
How to simulate Spoof E-mail attack and bypass SPF sender verification? | 2#2
Additional reading
Sender Policy Framework

Sender Policy Framework
Implementing SPF record | Part 8#17
How Does The DKIM Standard Protect Us From The Spoof Mail Scenario?
The DKIM method for verifying the mail sender identity legitimacy is implemented by a method,
in which an authorized entity digitally signs the E-mail message that is sent from the sender.
The Digital signature is based on existing PKI (public-key key infrastructure).
Using the options Digital signature enables the other side (the mail server that represents the
destination recipient in our scenario) to be sure that the information (the E-mail message) was
sent by a trusted authority.
Because the E-mail message was sent by a trusted authority (the mail server, they represent the
sender), the destination mail server can be sure that the sender is a legitimate sender (the
sender is who he claims to be).
The authority the digitally sign the sender E-mail message, is usually the mail server that
delivers the E-mail message on behalf of the sender.
In DKIM infrastructure, the entity that sign the E-mail message described as DKIM selector.
The information that is signed by the DKIM selector, includes a couple of mail fields, but in the
context of our topic, the main thing that we ought to know is that the mail field
named FROM that contain the sender identity (the sender E-mail address) is digitally signed.
Note if you want to read more detailed information on the DKIM standard and
the implementation of DKIM in Office 365 based environment, you can read the
article series
DKIM Domain Keys Identified Mail | Basic introduction | Part 1#5
DKIM sender verification processes flow.

The DKIM sender verification protocol, use the following mechanism for verifying the identity of
the sender:
The E-mail message that was sent from the source mail server includes.
The digital signature of the data that includes the E-mail address of the sender.
Information about the name (FQDN) of the mail server that signed the E-mail message
meaning the DKIM selector.
When the E-mail message reaches to the destination mail server, the mail server fetch from the
mail header (FROM field) the information on the sender E-mail address.
To be able to get information about the authority that digitally signed the E-mail message, the
destination mail server relates to the domain name of the E-mail address
(the right part of the E-mail address).
In our specific example, the domain name of the sender is o365info.com
The mail server fetch from the mail header, the host name of the DKIM selector that signed the
E-mail message.
The destination mail server addresses a DNS server who hosts the specific domain name and
looks for information on the DKIM record that is hosted under the o365info.com domain
name.
The DKIM record is implemented as a TXT record, that includes relevant information about the
host name of the DKIM selector.
In a DKIM scenario, the mail server will look for information about the host name of the DKIM
selector.
In case that the DKIM record includes the host name of the DKIM selector that appears in the
E-mail message, the mail server know that he is authorized authority, and that he can be
trusted.
Now, to the destination mail server, move on to the next phase, in which he needs to verify the
Digital signature that appears in the E-mail message.
The Digital signature verification process is implemented by a quite complicated process, in
which the destination mail server calculates by himself, the HASH value of the mail field
(including the mail field FROM that contain the sender E-mail address), and compare the HASH
value that he got to the HASH value that appears in the E-mail message.
Case 1 in case that the HASH value is identical, the meaning is that the data was not
altered in any way, and then we can be sure the sender is a legitimate sender.
Case 2 in case that the HASH value is not identical, the meaning is that the data was
altered, and for this reason, we cannot be sure the sender is a legitimate sender.
DKIM | The scenario in which E-mail message is classified as Spoof E-mail.

From the DKIM process point of view, the verification test includes two tests that must be
completed successfully.
Test 1 In case that the DKIM selector that appears in the E-mail message doesnt appear in the
DKIM record that is hosted under the sender domain name, the verification process considers as
failed meaning the E-mail considers as Spoof mail.
Test 2 In case that the HASH value of the digital signature is not valid (not identical), the
verification process considers as failed meaning the E-mail considers as Spoof mail.
How Does Exchange Protect Us From Spoof E-Mail Scenario?

Lets start with a declaration by default; Exchange is not configured to protect us from a
scenario of Spoof mail (spoofed sender).
We can even say that the Exchange server is indifferent for Spoof E-mail attacks or to the
identity of the sender.
Although the Exchange server is indifferent towards the sender identity legitimacy, we can use
an Exchange powerful option that will help us to identify legitimate senders in a specific scenario
in which we want to verify the identity of the sender that uses the domain name that is hosted
by the Exchange organization (domain name that the Exchange considered authoritative for).
The Exchange verification test is implemented by using a combination of two parts:
Information that is saved in the E-mail message header.

Exchange rule.
Using an Exchange rule, we can define a logical condition, which will enable us to identify a
scenario of a spoof sender (spoof mail).
When we use the term Spoof mail the meaning is a very specific scenario a scenario in which
hostile element is using our user identity, and try to attack one of our organization users.
The Exchange rule condition that we define is based on the following logicEach entity that uses our organizational identity (the E-mail address that includes our domain
name), is supposed to be a legitimate entity, that is hosted by our Exchange server.
Each legitimate entity that addresses the Exchange server should provide user credentials, so the
Exchange server will be able to know that this is a legitimate and trusted entity.
For example, when we open our Outlook, and access the data that are stored in our mailbox, our
user credentials transferred in the background on the Exchange server.
The information about the fact that entities provide or didnt provide user credentials, is
registered as part of the mail header.
In case that the entity provides user credentials, the entity authentication status is
internal.
In case that the entity didnt provide user credentials, the entity authentication status is
Anonymous.
The trick that we can use, is based upon a procedure in which we fetch the information on
the authentication status of senders, that their E-mail message includes our domain name.
For example in our specific example, the hostile element presents himself uses the E-mail
address John@o365info.com (a false identity).
John is a real Exchange recipient, that has an Exchange mailbox, etc.
The Exchange mail server that considers as authoritative for the domain name o365info.com is
expecting that the sender will provide user credentials because this is the right way that
legitimate recipient use for accessing their private data that is stored in the Exchange mailbox.
In our scenario, the element is a hostile element that doesnt have Johns credentials (user name
+ password).
For this reason, his authentication status is Anonymous but, at the same time, uses the E-mail
address of John.
This is our sign of that fact, that this is probably spoofed sender (Spoof mail).
The be able to tell Exchange server that we want to identify events of Spoof mail in which the
sender authentication status is anonymous, and the sender E-mail address includes our
domain name; we can create an Exchange rule that will monitor such events and do something
when he identifies such as event.
Its important to emphasize that this option is available only for organization that uses Exchange
mail infrastructure, and this is not a formal or public standard, but instead, a gimmick that we
can use in our favor as a Spoof mail deduction mechanism or, as an additional layer for
implementation of existing mail sender verification standard such as SPF.
Exchange rule | The scenario in which E -mail message is classified as Spoof E mail
The event of Spoof mail will be described by a combination of two conditions, which should
happen at the same time.
The sender needs to use E-mail address that includes the organization domain name, and
considers as an anonymous sender (sender that didnt provide user credentials).
How Does Exchange Online Protect Us From Spoof E-Mail Scenario?

The feature of the Phish Filter (and Phish Filter Policy), is a relatively new feature that is available
for Exchange Online customer meaning Office 365 customers.
The Phish Filter option is an EOP (Exchange Online protection) feature.
In Office 365 based environment, EOP serves as a mail security gateway.
The purpose of the Phish Filter is to enable Office 365 customers, to detect a common scenario
of Spoof mail, in which the attacker provides two different identities the sender identity that
appears on the MAIL FROM field (the mail envelope) + the sender identity that appears in
the FROM field (mail header).
Note If you want to read more information about this method that is used by
hostile elements, for bypassing existing sender verification mechanism such as SPF
you can read the article
How can hostile element execute Spoof E-mail attack and bypass existing SPF
implementation? | introduction | 1#2
The Phish Filter detects a Spoof mail event based on a very simple verification test:
When a sender addresses the Exchange Online mail server (if we want to be more accurate, the
Exchange Online protection), and use two sets of sender identities, the Exchange online Phish
Filter Policy, will verify if the sender information in the MAIL FROM field is identical to the
sender identity in the FROM mail filed.
In the case that the identities are different, this is a sign that something is wrong with the
specific E-mail message.
Exchange Online Phish Filter Policy | The scenario in which E-mail message is classified as
Spoof E-mail
The event of Spoof mail will be described as a scenario in which the E-mail address that
arrears in the MAIL FROM field is not aligned meaning, different from the E-mail address that
appears in the FROM field.
In this case, the E-mail message will be considered as High-risk E-mail message, and a warning
notification will be added to the original E-mail message.
How Does DMARC Protect Us From Spoof E-Mail Scenario?

The DMARC standard is a special stand because he doesnt include a Standalone mechanism
or protocol for implementing sender verification, but instead, relies upon another sender
authentication protocol SPF and DKIM.
The job of the DMARC standard regarding the sender verification process is
1. To check if a specific E-mail message was verified by one of the sender verification
standards SPF or DKIM.
2. To check if the result from the verification test is passed or failed.
3. To implement an additional layer of sender verification described as alignment.
In case that we use one of this sender authentication protocols, the DKIM expands the
verification process that is implemented by each of these protocols.
In other words, the DMARC is implementing more stricter sender verification tests versus the
sender verification standard SPF or DKIM.
The technical term that is used by the DMARC for describing the additional layer of sender
verification described as alignment.
For example, in case that we use the SPF or DKIM, from the DMARC point of view, its not
enough that the SPF or DKIM verification test is successful, but in addition, the DMARC dictate
additional condition, which needs to successfully implement.
The DMARC standard and the SPF alignment

In a scenario, in which our mail infrastructure is using the SPF standard for implementing sender
verification, each of the incoming mail will be stamped by the SPF verification test
as fail or pass.
Note in reality, the SPF standard includes additional status code, but in the current time, we
would like to simplify the description. For this reason, we will relate only the
to fail of pass status code.
When we use the DMARC standard, the first test that will be performed by the DMARC is to
verify if the SPF status is fail or pass.
In case that the SPF status is pass, the DMARC will continue to the next test, in which the
DMARC verifies the required SPF alignment.
The SPF alignment test is implemented by verifying if the E-mail address of the sender that
appears on the MAIL FROM field (the information that appears in the mail envelope) is identical
to the E-mail address that appears in the FROM field (the information that appears in the mail
header).
Case 1 DMARC SPF alignment test pass

In the following diagram, we can see an example in which the E-mail message includes two
sender identities. In our example, the sender identity that appears in the MAIL FROM is identical
to the sender identity that appears in the FROM field.
In this case, the SPF alignment test was successfully completed, and the DMARC stamps
the E-mail message with the status code dmarc=pass
Case 2 DMARC SPF alignment test fail

In the following diagram, we can see an example, in which the E-mail message includes two
sender identities. In our example, the sender identity that appears in the MAIL
FROM is different from to the sender identity that appears in the FROM field.
In this case, the SPF alignment test was not successfully completed, and the DMARC stamps
the E-mail message with the status code dmarc=fail
The DMARC standard and the DKIM alignment

In a scenario in which our mail infrastructure is using the DKIM standard for implementing
sender verification, each of the incoming mail will be stamped by the DKIM verification test
as fail or pass.
When we use the DMARC standard, the first test that will be performed by the DMARC is to
verify if the DKIM status is fail or pass.
In case that the DKIM status is pass, the DMARC will continue to the next test, in which the
DMARC verifies the required DKIM alignment.
The DKIM alignment test is implemented by verifying if the DKIM selector domain name,
is identical to the domain name of the sender who appears in the FROM field (the information
that is saved in the mail header).
Case 1 DMARC DKIM alignment test pass

In the following diagram, we can see an example of the information about the DKIM selector
name that signed the E-mail message. The information about the DKIM selector hostname is
saved as part of the E-mail message.
In our scenario, the DKIM selector name includes the domain name o365info.com
In the FROM field, we can see that the sender E-mail address uses also the domain name
o365info.com
In this case, the DKIM alignment test was successfully completed, and the DMARC stamps
the E-mail message with the status code dmarc=pass
Case 2 DMARC DKIM alignment test fail

In the following diagram, we can see an example of the information about the DKIM selector
name that signed the E-mail message. The information about the DKIM selector hostname is
saved as part of the E-mail message.
In our scenario, the DKIM selector name includes the domain name outlook.com
In the FROM field, we can see that the sender E-mail address uses also the domain name
o365info.com
In this case, the DKIM alignment test was not successfully completed, because the DKIM selector
domain name is not identical to the sender domain name.
The DMARC stamps the E-mail message with the status code dmarc=fail
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

How Does Sender Verification Work - How We Identify Spoof Mail) SPF, DKIM DMARC, Exchange - Part 9#9 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

How Does Sender Verification Work - How We Identify Spoof Mail) SPF, DKIM DMARC, Exchange - Part 9#9 PDF

Caricato da

Copyright:

Formati disponibili

Page 1 of 26 | How does sender verification work?

(How we identify Spoof mail) | The five

How does sender verification work? (How we

The process of sender verification, enables us to distinguish between a legitimate sender

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

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

The sender identity store

SPF sender verification processes flow

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

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

SPF | The scenario in which E-mail message is classified as Spoof E-mail

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

Disadvantage of SPF standard

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

Sender Policy Framework

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

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

DKIM sender verification processes flow.

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

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

DKIM | The scenario in which E-mail message is classified as Spoof E-mail.

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

How Does Exchange Protect Us From Spoof E-Mail Scenario?

Information that is saved in the E-mail message header.

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

How Does Exchange Online Protect Us From Spoof E-Mail Scenario?

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

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

How Does DMARC Protect Us From Spoof E-Mail Scenario?

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

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

The DMARC standard and the SPF alignment

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

Case 1 DMARC SPF alignment test pass

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

Case 2 DMARC SPF alignment test fail

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

The DMARC standard and the DKIM alignment

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

Case 1 DMARC DKIM alignment test pass

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

Case 2 DMARC DKIM alignment test fail

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

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

Potrebbero piacerti anche