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 applying a procedure, which check and verify the sender identity (check if the sender considers 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 in which the sender verification process is implemented by the following infrastructures:

1. Mail sender verification standards – SPF, DKIM and DMARC.
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 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 relies on Exchange Online.

The concept behind this method implemented by looking at the status of the authentication information about the recipient – the information that stored in the X-MS-Exchange-Organization-AuthAs mail field.

The underlying 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.”

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

If we want to be more accurate, the SPF standard refers to the “right part” of the E-mail address meaning, the domain name, and the DKIM standard refers 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 of the DMARC standard regarding the subject of verifying sender identity 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,” DMARC 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 displayed in the FROM field

3. Exchange based environment | Recipient authentication status.

In Exchange based environment, we can use an additional “peace of information,” that appears in 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 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 stored in the X-MS-Exchange-Organization-AuthAs mail field for identifying an event of a Spoof mail attack “(spoof sender).

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

4. Exchange Online – Phish Filter

The term “Phish Filter,” describe a particular 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 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, which is applied 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 performed 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 checking if the source mail server is authorized to send E-mail on behalf of the particular domain.

The verification process implemented by using a dedicated SPF record (TXT record) that includes the IP address of the authorized mail server\s for a particular domain.

2. DKIM standard

The DKIM sender identity verification 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 target mail server verifies the sender identity by checking the digital signature that displayed 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 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 is displayed 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.

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 hosted on an Exchange

In a scenario in which the “sender” use an E-mail address that includes the domain name that hosted on the Exchange server, the underlying assumption is – that this is an “Exchange user” that has an Exchange mailbox. 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 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 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 based on Exchange mail server or Exchange Online (Office 365 customers).

The major differences between the Exchange-based solutions vs. 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 settings such as DNS records.

2. Incoming mail flow

The Exchange based solution’s mechanism, for the identification of 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 primary 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 on behalf of our domain name.

Also, 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 use 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 vs. “not doing anything,” and leave your organization mail infrastructure exposed to a variety of risk and dangers.

Using a particular sender verification mechanism vs. 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 “correct 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 describe 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.

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 particular “cocktail” that can describe 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 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 target recipient, and after the target mail server reads all the required information that 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 target recipient, and the mail server will need to “return the E-mail” to his original sender.

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

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

The next article in the current article series

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