How does sender verification work how we identify spoof mail) spf, dkim dmarc, exchange part 9#9

Page 1 of 26 | 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

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

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

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.

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


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

http://o365info.com/




The Five Hero’s 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, doesn’t 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 doesn’t 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, doesn’t 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





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-to-simulate-spoof-e-mail-attack-and-bypass-spf-sender-verification-part2-of-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.





http://www.openspf.org/

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

http://o365info.com/implementing-spf-record-part-8-17/




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.





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




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 doesn’t 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?

Let’s 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 logic-

Each 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 didn’t 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 didn’t 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 –[email protected] (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 doesn’t have John’s 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.

It’s 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 didn’t 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 doesn’t 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, it’s 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





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

Date post:	27-Jul-2016
Category:	Documents
Upload:	o365infocom
View:	218 times
Download:	1 times

How does sender verification work how we identify spoof mail) spf, dkim dmarc, exchange part 9#9

Documents