skip to Main Content

Dealing with an E-mail Spoof Attack in Office 365 based environment | Introduction | Part 1#12

An organization IT manager call to Office 365 supports, worried and upset, declaring that he is very disappointed about the fact that “Office 365” allow the occurrence of a spoofed E-mail attack!

Besides of the urgent need for understanding, how could this happened; the additional urgent need is – to implement some security mechanism, that will identify and block the Spoof E-mail attack immediately!

In this current article series, we will review the subject of the Spoof E-mail phenomenon and focus on how to deal with such attacks using an Exchange Online rule.

A basic Q and A regarding the subject of Spoof E-mail and Office 365 environment

Q1: Does the ability to carry out spoofed E-mail attacks can be executed only to professional hackers?
A1: No, it’s very easy to “execute” a process, in which we “spoof” the identity of “other person”. We can very easily perform an SMTP session with a target mail server and “claim” that we are someone else.

Q2: How can it be that the act of impersonation, is so simple and easy?

A2: The SMTP protocol doesn’t include a built-in mechanism that can prevent from the hostile element, perform a “non-legitimate operation” (such as a fake identity of another person).
In other words, all the existing public mail infrastructure is exposed to Spoof E-mail attacks, and the technical person that manages the organization mail infrastructure should be familiar with the options and the possible solutions that can prevent most of the Spoof
E-mail attacks.

Q3: Is it possible to execute spoofing or Phishing attacks in Office 365 and Exchange Online-based environment?

A3: And the answer is: ”Yes”

Q4: Does it mean that the Office 365 and Exchange Online-based environment especially exposed to this attack?

A4: The answer is that – every mail infrastructure is exposed to this attack because the spoofing or Phishing attacks exploit existing vulnerabilities of the standard SMTP mail protocol.

Q5: Who is the “element” that needs to identify and block various types of E-mail attack such as spoofed E-mail attack?

A5: Technically speaking, the “protection mechanism” can be implemented on the mail server side, but at the same time also on the mail client side.

Most of the time, we will use a “protection infrastructure” for preventing spoofed E-mail attack on the “mail server side” meaning, the mail server or other mail security gateway, that knows how to identify E-mail attacks and stop them, reports to a designated person and so on.

Q6: So, can I assume that in Office 365 and Exchange Online based environment, the “server side” (Exchange Online) is configured to block automatically or prevent various types of E-mail attacks?

A6: Yes, and No. The Exchange Online infrastructure is a very advanced infrastructure that supports all the advanced mail security standards and another mechanism that can help you to identify and block various E-mail attacks.

But, it’s critical to understand that this “mail security standard” or other mail security mechanism are not “activated” automatically.

Exchange Online will block E-mail that includes a malware or “stamp” problematic E-mail message as “spam mail” but the responsibility to enable and configured the variety of “mail security mechanism” is our responsibility as the Exchange Online administrator.

For example – the ability to recognize and stop spoof E-mail is not “activated” automatically in the Exchange Online information.

To be able to deal with such attacks, we will have to be familiar with the different security mail standard that can help us to deal with Spoof E-mail or create a dedicated Exchange Online rule that will identify suspicious mail that looks like Spoof E-mail.

I like to think about Exchange Online as a “naked motherboard,” that includes all the required slots for the different hardware components such as video card, sound card, memory card and so on.

We are the “element” that needs to decide what “hardware component” we want\need and add this hardware component to the “naked motherboard.”

The same logic implemented when using Exchange Online infrastructure – we need to know what are the mail security standard (“hardware components”) that we want\need, and we need to “plug in” these “hardware components” (E-mail security standard) into the Exchange Online infrastructure and create the required configurations.

What is the meaning of Spoof E-mail or spoofing?

We will not provide detailed information about the differences between these “mail attacks” but instead, will satisfy with a very short and basic explanation.

Most of the time, spam mail, and phishing attacks, are implemented by the hostile element that has an adamant, interest to hide their identity and present themselves using fake identities.

In mail based environment, the phenomenon in which the “source recipient” fake his identity and present himself as “someone else” described as spoofing.
The E-mail message that sent from this hostile element described as spoofed E-mail.

The scenario in which such element spoofs his identity is realized in two primary flavors:

Case 1 – in this scenario, the hostile element presents himself as a non-organization recipient but instead, a recipient from a legitimate organization.

For example – hostile element sends spam mail to the recipient from an organization that uses the public domain name – o365pilot.com

The hostile element presents himself as a recipient from an organization named – contoso.com (Let’s assume that the domain name “contoso.com” represents the domain name of a very famous bank)

This type of spoofed E-mail implemented when the hostile element wants to provide the impression, that he is a recipient from well-known and trusted institution such as – Bank, Insurance Company and so on.

In this type of scenario, the source recipient, and the destination recipient represented by using a different domain name.

E-mail spoofing - Hostile element impersonate himself to an external legitimate recipient -01

Case 2 – in this scenario, the hostile element presents himself as a legitimate organization recipient.

For example – hostile element, send spam mail to the recipient from an organization that uses the public domain name – o365pilot.com

The destination recipient is: Bob@o365pilot.com

The hostile element presents himself as a recipient from the same organization, by impersonating himself to the organization recipient named – Suzan@o365pilot.com

In other words, the source recipient and the destination recipient are represented by using the same domain name.

This type of spoofed E-mail implemented when the hostile element wants to provide the impression, that he is a “legitimate and trusted organization recipient” such as the company CEO and so on.

E-mail spoofing - Hostile element impersonate himself to an internal legitimate recipient -02

Available Options in order to deal with the phenomenon of spoofed E-mail

In this section, I would like to briefly review the “existing tools and procedures” that is available for our war with the phenomenon of the spoofed E-mail.

In the following diagram, we can see a high-level representation of the available “tools” that we can use.

The existing ways to deal with the phenomenon of spoofed E-mail-01

Dealing with spoofed E-mail | Process and procedures

Educating our users regarding mail infrastructure threats and vulnerability

Let’s start with the “less technical” part that relates to the subject if – “what can I do in a scenario in which our users report about spoofed E-mail”?

User education – because the subject of “user education” doesn’t consider as a “technical solution” or some “magic technology,” we tend to neglect the issue most of the time and, immediately move on to the “technical solutions.”

This is a common mistake because, in a scenario that we are educating our users regarding the different threats and dangers such as spoofed E-mail, we can prevent the realization of attacks, which can lead to theft of personal information, damage to business activity and so on.

Bottom line – try to be “proactive” by educating your users about – how to identify spoofed
E-mail, about the importance of reporting such as the type of events, etc.

Report spoofed E-mail

One of the essential tasks in a scenario of a spoofed E-mail attack relates to the subject of – reporting the “right person” about the occurrence of spoofed E-mail incident.

The subject of “reporting” refers to the parts:

  1. The ability of an organization’s user to know who to contact at an event of a possible spoofed E-mail.
  2. The ability to save a copy of the original spoofed E-mail that will be sent to a designated recipient, such as the organization security team or the Exchange Online administer. In the next article, we will review how to create an Exchange Online incident report that will send a copy of the spoofed E-mail to the pre-defined recipient.
  3. The process in which we report about the spoofed E-mail to “Office 365 representative”. In the article – Report Spoof E-mail and send E-mail for Inspection in Office 365|Part 12#12, we will review how we can use OWA mail client for reporting about a spoofed E-mail.

Dealing with spoofed E-mail | Technical solutions

  1. “E-mail security standard” that relates to spoofed E-mail

Under the section of “E-mail security standard” that relates to spoofed E-mail, we can mention the standard such as SPF, DKIM, and DMARC

Each of these standards created for providing some kind of a solution for dealing with the phenomenon of “spoofed E-mail”.

The common denominator for implementing one of this “mail security standard” is, the need to publish a dedicated DNS record (a TXT record) that “declare”

  • Who we are the allowed “entities” that can represent our organization mail infrastructure.
  • What to do in the case that the “other side” discovers that he got an E-mail message from an element that doesn’t answer the condition of a “legitimate E-mail message.”

The main “disadvantage” of this “mail security standard” is that there is a learning curve, in which we need to learn and understand what is offered a solution by each of these mail standards, what are the characters of each standard, what are the required configuration settings that need to implemented, how to monitor the mail flow after implementing one or all of this standard and so on.

Existing E-mail security standard that deal with spoofed E-mail-02

As mentioned, we will not get into the specific details for each of this “mail security standard” but instead, just briefly mention that

SPF standard

The SPF standard based on a concept; in which we try to validate the identity of “approved mail server” that is entitled to send an E-mail message on behalf of a particular domain name.

The “identity of the mail server” is represented by the mail server IP address.

DKIM

The DKIM standard is based on a concept; in which we try to validate the identity of the source recipient domain name. When a specific recipient uses an E-mail address that includes a specific domain name, the DKIM standard defines a method in which we can verify that the domain is “approved” and verified.

DMARC

The DMARC standard is based on a test that verified and checks the SPF + DKIM mail security standard.

Bottom line – the need to be familiar with this “E-mail security standard” that relates to spoofed E-mail can consider as a mandatory need for each mail infrastructure administrator.

In the current article, we will now review this “E-mail security standard” that relates to spoofed E-mail and in the future, a dedicated article will be written about each of these mail security standards.

Implementing the option of – Exchange Online Spoofed E-mail rule

The current article series dedicated to reviewing different options for using an Exchange Online rule; that will create for identifying spoofed E-mail and respond accordingly.

Note – the information that will review is related to Office 365 and Exchange Online infrastructure, but most, if the information is relevant also for Exchange on-Premise environment.

One of the most distinct advantages of using the Exchange Online rule for dealing with a spoofed E-mail scenario is – that we can create the Exchange rule in a couple of seconds, without the of advanced technical knowledge and the need to set up and publish various DNS records (such as when we need to implement some mail security standards such as – SPF, DKIM, and DMARC).

The logic that is used by Exchange Online Spoof E-mail rule

The most basic question that can appear in our mind is – how does Exchange Online rule be able to identify a scenario in which the “source recipient” try to execute Spoof E-mail attack?

The answer is that the Exchange Online rule that we create implemented by using a underlying assumption in which we define a “trusted organization users” as a user that proof his identity by providing the Exchange Online server his user credentials.

For example – some recipient connects the Exchange Online server and “claims” that he is a legitimate organization user named Suzan that uses the E-mail address
Suzan@o365pilot.com and he wants to send E-mail message to Bob@o365pilot.com

By default, Exchange Online cannot “know” if Suzan is really someone who claims to be because from the “SMTP protocol point of view” as long as the E-mail address that the recipient uses syntactically correct, the recipient is “OK.”

To be able to add another “layer” to the Exchange Online server that will enable him to perform additional checks regarding the subject of “recipient identity” that claim to be a legitimate organization user, we can add an Exchange Online rule, that will based on the following logic:

  • If the source recipient says that he is an “organization recipient” meaning, the recipient whom his E-mail address includes our organization domain name, the user should be considered as an authenticated user.
  • If not, the conclusion is that this user is trying to spoof the identity of a legitimate organization recipient.

    Exchange infrastructure - using Exchange spoofed E-mail rule - Dealing with spoofed E-mail-03

The Exchange rule term “External sender” versus “Internal sender”

When using the Exchange Online rule, that will enable us to distinguish between a legitimate organization recipient and non-legitimate organization recipient, we use the terms: external sender and internal sender.

  1. The term – external sender defines an “entity” (source recipient) that present herself by using an E-mail address that includes our domain name but doesn’t provide any user credentials. In other words – non-authenticated user \ recipient.
    When using the Exchange Online rule wizard, this type of sender defines as – “outside the organization“.
  2. The term – internal sender defines an “entity” (source recipient) that present herself by using an E-mail address that includes our domain name and in addition provides user credentials. In other words – authenticated user \ recipient.
    When using an Exchange Online rule wizard, this type of sender defines as – “inside the organization“.

Our main goal is to be able to distinguish legitimate organization users (recipient) from a non-legitimate element that claim to be one of our organization users.

Our underlying assumption is that a “legitimate organization user” that have an Exchange Online mailbox must provide his credentials (username + password) before he asks from Exchange Online to deliver email messages to the other Exchange Online recipient.

In a scenario of a hostile element that tries to present himself as a legitimate organization user, the hostile element will not be able to provide valid user credentials.

The meaning of the Exchange term - External versus internal sender -02

The logic that will be implemented by the Exchange Online rule will be based on the following conditions:

If a host address Exchange Online and present himself by using an E-mail address that “belong to the organization” (using an E-mail address that includes the domain name o365pilot.com in our scenario) but without providing any user credentials, this host will be identified by Exchange Online as an external sender or a parallel term – outside the organization“.

In this case, the Exchange Online rule that will created will “stamp” this host as a “problematic host” that is trying to execute Spoof E-mail attack!

The second part of the Exchange Online will include an instruction regarding “what are actions” that will be executed by the Exchange Online in a scenario in which the sender is classified as an external sender (outside the organization).

The meaning of the Exchange term - External versus internal sender -01

In case that you wonder how does Exchange Online server distinguish between authenticate recipient versus non-authenticate recipient, the answer is – by using X-headers

The X-headers a data field that are populated with a specific value.
The X-headers field that defined authenticated recipient versus non-authenticate recipient described as – X-MS-Exchange-Organization-AuthAs.

The X-MS-Exchange-Organization-AuthAs field Specifies the authentication source. This X-header is always present when the security of a message has been evaluated.
The possible values are Anonymous, Internal, External, or Partner.

To be able to demonstrate the use of this X-headers a date filed, I use the following scenario:

An organization recipient named Suzan that uses the E-mail message – Suzan@o365pilot.com is sending E-mail messages to another organization recipient named Bob that uses the E-mail address Bob@o365pilot.com

Scenario 1 – in this scenario Suzan using her Outlook client for sending E-mail message to Bob. Suzan has to provide user credentials to be able to use the Outlook mail client. In other words, Suzan considered as an authenticated recipient.

Scenario 2– in this scenario we use a Telnet session for sending e-mail messages to Bob@o365pilot.com. In our scenario, we present ourselves as Suzan@o365pilot.com and doesn’t provide any user credentials.

In this scenario, Suzan considered as non-authenticated recipient

We took the E-mail message header that was sent to Bob and used the ExRCA message analyzer for inspecting the data in the E-mail header.

In the following screenshot, we can see the E-mail header of the mail that sent from the Outlook mail client (authenticated recipient).

We can see that the value of the X-MS-Exchange-Organization-AuthAs is “Internal”.
The meaning of “internal recipient” is trusted recipient, that could prove his identity by providing user credentials.

X-MS-Exchange-Organization-AuthAs -02

In the following screenshot, we can see the E-mail header of the mail that sent from the Telnet session client (non -authenticated recipient).

We can see that the value of the X-MS-Exchange-Organization-AuthAs is “Anonymous”.
The meaning is “Anonymous recipient” is non-trusted recipient that didn’t provide any user credentials (Anonymous session).

X-MS-Exchange-Organization-AuthAs -01

The Exchange Online Spoofed E-mail rule | The “action” (response).

Another thing that I would like to mention regarding the Exchange Online rule, that will be created for dealing with a scenario of spoofed E-mail is – the part of the Exchange Online rule “action”.

Each of the Exchange rules contracted from three different parts:

Part 1#3 – the Exchange rules condition.

This is the Exchange Online rule part that defines a particular condition that should met.
In our scenario, a condition in which the sender uses our organization E-mail address, but doesn’t provide user credentials that can prove his legitimate identity.

If we want to use a term from the development world, this is the “IF” part.

Part 2#3 – the Exchange rule action

This is the part in which we instruct Exchange “what to do” when a particular E-mail “answer” the condition that defined in the first part.

The action could be a particular action or a collection of “multiple actions” that will be triggered.

If we want to use a term from the development world, this is the “THEN” part.

Part 3#3 – the Exchange exceptions

This is the part in which we instruct the Exchange not to execute the rule in a specific scenario.

If we want to use a term from the development world, this is the “ELSE IF” part.

The variety of options available to us when using an Exchange Online rule

In Exchange Online environment, each of these “parts” can be configured with many possible options and parameters and the combination of these three parts and the different options that can be selected is each section such as the condition, the action and the acceptance procedure an enormous amount of choices and different rule variations

The current article series provide a couple of examples of the different versions of Exchange Online rule that will need to deal with a spoofed E-mail scenario.

The first part of the Exchange Online rule, which is the “condition” part will stay identical in all the articles.

The second part of the “actions”, is the part in which we will provide many variations of different “actions”, which will answer a particular business need.

For example – Exchange Online rule that will identify spoofed E-mail (E-mail that is sent from un-authenticate recipient) can “respond” to this event in many different ways such as:

  1. Send the spoofed E-mail to the destination recipient mailbox + generates and sends an incident report to a designated recipient.
  2. Send the spoofed E-mail to the quarantine + generates and sends an incident report to a designated recipient + E-mail notification to the destination recipient.
  3. Send the spoofed E-mail to the destination recipient mailbox + add predefined text to the email message + generate and send an incident report to a designated recipient.
  4. Send the spoofed E-mail to the destination recipient mailbox + updates the SCL value + generate and send an incident report to a designated recipient.

Plan carefully and thoroughly the implementation of the Exchange Online Spoofed E-mail rule

The purpose of the Exchange Online Spoofed E-mail rule is to identify an event of spoofed E-mail and “respond accordingly” by blocking the E-mail message, route the E-mail message to quarantine and so on.

This “response” is based on the fundamental assumption, that the E-mail message that identified as spoofed E-mail indeed spoofed E-mail.

The problem is that, in reality, the logic of the Exchange Online rule, could also identify a legitimate E-mail message as a spoofed E-mail.

For example, the Exchange Online Spoofed E-mail rule identifies an E-mail as “spoofed E-mail” in case that the sender E-mail address uses an E-mail address that includes our organization domain name, and the sender doesn’t provide user credentials.

This “behavior” could be related to the hostile element, but at the same time, could be related to a legitimate organization host.

For example, a scenario in which mail-enabled device such as a printer or scanner, use an organization E-mail address but doesn’t provide user credentials.

To avoid from such as the scenario in which a legitimate E-mail message identify as spoofed E-mail, we should carefully plan the creation and the activation of the Exchange Online Spoofed E-mail rule.

A careful planning of the Exchange Online rule implementation could include:

Creating a list of organization hosts and services, that address Exchange Online as their mail server and in the next phase adds an exception to the Exchange Online rule.

Another option is to create the required Exchange Online rule that will identify events of spoofed E-mail but will not respond with an action such as – deleting the E-mail, but instead, instruct the Exchange rule to only generate an incident report that will be sent to a pre-defined designated recipient, such as the Exchange Online administrator.

Another way to define this scenario could be the term “learning mode”. A specified period, which we use for analyzing and understand better when is the Exchange Online rule is triggered, etc.

Non-authenticated recipient good or bad

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *