Posey's Tips & Tricks
Preventing Microsoft 365 Phishing Attacks, Part 1
Microsoft 365 includes built-in tools to defend against phishing attempts that use domain and user impersonation, but administrators need to understand how these protections work to avoid unintended disruptions.
Phishing attacks are one of the single biggest threats to any organization. And while you can help to thwart phishing attacks by enabling multifactor authentication and using attack simulations to train your users, there is quite a bit more that you can do. Microsoft 365 includes a number of features designed to prevent various types of phishing attacks.
Before I get too far into this discussion, I need to take a moment and clarify the difference between spoofing and impersonation. Although these two terms seemingly mean the same thing, Microsoft actually treats them differently. Microsoft defines spoofing as "an attacker forging the sender's email address or domain to make it look like a trusted source." Conversely, Microsoft defines impersonation as "an attacker mimicking a trusted user, domain or brand to trick the recipient into believing the email is genuine."
The difference between these two terms is that spoofing involves taking measures to impersonate a sender's actual email address or domain. Impersonation on the other hand, involves techniques such as misspelling or variations of an email address or domain. As an example, if someone were to impersonate me, they might misspell my name as Brian or Brein instead of Brien. The same basic technique can also be applied to a domain.
Another thing that I need to tell you before I get too far into this discussion is that most of the techniques that I will be discussing require Microsoft Defender for Office 365 Plan 2. So with that said, let's get started.
Impersonated Domain Protection
Impersonated domain protection checks inbound emails to see if they are attempting to impersonate a trusted domain. As an example, my own domain name is BrienPosey.com. If someone were to try to impersonate my domain name, they might use something like BrienPosey.net or BrienPosey.co. Additionally, the domain name might be slightly misspelled or some extra characters might be tacked onto the domain name. Some examples might include BreinPosey.com or BrienPososey.com
Microsoft 365's domain impersonation protection feature prevents certain domain names from being impersonated. You should, for instance, protect any domain names that you own. However, you can protect additional domain names.
It is worth noting that impersonated domain protection only works if the sender and recipient have never communicated by email before. If a particular sender and recipient have communicated, then the sender's domain name will not be treated as an impersonation attempt, even if it is.
User Impersonation
Just as Microsoft 365 allows you to protect your organization against domain impersonation, you can also protect against user impersonation. I don't want to rehash the concept of impersonation, because user impersonation is a lot like domain impersonation, except that it is the user who is being impersonated, not the domain. Even so, there is one important concept that I need to explain with regard to user impersonation.
This concept stems from the fact that there are completely legitimate actions that can look like impersonation. There are people in this world who have identical names. Similarly, there are people (myself, included) who have more than one email address.
Microsoft 365 lets you add up to 350 email addresses for which impersonation protection will be enabled. These can be internal or external addresses, or a mixture of the two. An organization might for instance add its CEO's email address to the list of addresses for which impersonation protection is enabled. This reduces the chances that someone will be able to impersonate the CEO.
As helpful as this might be, it's still worth considering the idea that I laid out a moment ago that legitimate actions can be viewed as impersonation attempts. To show you how this might work, let's pretend that you have enabled impersonation protection for your company's CEO. Just to make things interesting, let's also pretend that your CEO has a super common name. For the purposes of this blog post, I will use the name John Doe. Now that you have enabled impersonation protection for John Doe, there are a couple of things that can happen.
One of the unintended consequences is that the CEO might no longer be able to send messages to people within the company using his personal email account. Suppose for example, that the CEO's business email address was [email protected], but the CEO were to email someone within the company from the address [email protected]. That action would likely be seen as an impersonation attempt and the email would be blocked based on the user impersonation policy's settings.
Now, let's pretend that the CEO does not own the email address [email protected]. Instead, that email address belongs to an employee at a partner organization who just happens to have the same name as your CEO. Once again, messages from that email address will likely be blocked.
You will notice that I used the phrase, "messages from that email address will likely be blocked," as opposed to saying that the messages will be blocked. The reason why I say this is because if the email address has been used to converse with users within your organization prior to user impersonation protection being enabled, then future messages coming from that address will not be treated as impersonation attempts.
So now that I have explained the basics of user and domain impersonation, I want to show you how to enable impersonation protection. I will do so in Part 2 of this series.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.