Pausing to explain WHY you need to turn on MFA 

Leveraging MFA (multifactor authentication) is drummed into us from every angle, and it’s a popular topic at Practical 365. Thijs Lecomte addressed this in Ten Ways to Harden the Security of a Microsoft 365 Tenant, and Tony Redmond covers the topic in how to Improve MFA Effectiveness in your Microsoft 365 Tenant in 30 Minutes. The Practical 365 podcast is also full of comments on this subject.   

This article is going to go into “why” it’s important to turn on MFA. As systems administrators, we often get bogged down in security mandates so that we can lose track of why we do this. We hope sharing examples like this can help humanize the importance and seriousness of these activities. 

About two weeks ago, one of my colleagues, Chris Cahill, shared an attempted scam involving the sale of his house and the purchase of a new one. The scam used a combination of domain spoofing and business email compromise to try and take advantage of the high stakes and high-stress situation of real estate transactions. Chris spotted the duplicity, but he would not have needed to if MFA had been turned on in the first place within the real estate solicitor’s system. 

Chris and I sat down with Quest Software’s Bryan Patton, CISSP and fellow TEC 2022 speaker, last week to discuss the scam and record this short video. Bryan also shares some great tips on how your organization can address the issues raised. Take a look. 

The Nearly Lost House Deposit Story

Watch Bryan, Mike, and Chris discuss why you should turn on MFA.

As a recap of the video, this situation unfolded through various attacks and because MFA was not turned on. Let me explain. 

Domain Spoofing 

Domain Spoofing is just that, someone registers a similarly named domain and then uses it to mimic the behavior of the legitimate company. This change can be small, like or instead of the legitimate domain. Bad actors can then send email or put up a fake webpage with the domain. When set up correctly, spoofed domains can pass domain checks.  

Business Email Compromise (BEC) 

BEC attacks have several ways of occurring, but the end game is similar: a bad actor gets their hands on valuable email data they can use to steal funds and intellectual property. In this example, a bad actor used a technique like a password spray attack to compromise the user’s mailbox, harvested client data, copied email threads for target clients, and emailed the targets from a spoofed domain, mimicking the tone of the solicitor to increase the success of the attack.     

Multifactor Authentication (MFA) 

A quick review of MFA are the “factors”.  The factors are something you know, something you have, and something you are.  When protecting logins, you want to leverage multiple factors for authentication rather than rely on just a username and password, which can be compromised. 

Something you know is a username and password.  Something you have is a smart card, a key fob with a code, or, more commonly now, an app on your phone that gives you a code or push notification.  Finally, something you are encompasses systems that look at biometrics like fingerprints, face scans, and retina scans.   

For most Office 365 administrators, enabling MFA adds a factor from the “something you have” category like the Microsoft Authenticator app.  The key here is to not rely on basic authentication (username and password), which attackers target to compromise. According to Microsoft, MFA can block 99.9% of account compromise attacks. Closing off common attack routes for account compromise is why Microsoft will deprecate basic authentication for seven email connectivity protocols starting on October 1, 2022.

Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook. 

Double Trouble Mayhem 

As Chris shared with us in the video, during his house move he was in constant contact with his solicitor’s office. On a Thursday night, he got a reply from a previous email that stated it was time to set up a wire transfer to move funds from his account to the solicitor. When Chris replied asking for more details, they gave vague answers and new bank details he did not recognize. Feeling a bit worried, Chris looked at the sender and noticed the domain had changed, from address to simply .uk. He immediately realized an issue and contacted his solicitor using a number he had from other calls. They verified it was a scam, and Chris and his family did not fall victim. 

How did this happen? 

There is an open investigation in this situation, but we can piece together the basics based on the message headers, timeline, and commonality of what occurred. It is highly likely that a bad actor got the username and password for the solicitor or an administrator from another breach. There was no multifactor authentication enabled, so the attacker could log in as the user.  The bad actor then registered a similar domain name (domain spoofing) and, using the email threads, replied to active clients to try to redirect money transfers (BEC scam).  

Chris gets full marks for catching this, but the sad reality is that there is not much effort needed to execute this scam. The combination of domain spoofing and BEC would be tough to catch. In the video, Bryan raised the excellent point that we sometimes are too stressed and worried to catch these things in these significant life events. The actual email thread being used would throw off so many. 

What can I do to prevent these scams from affecting my organization? 

As a Systems Administrator, your only option is limited to protecting your system – turn on MFA. Domain Spoofing is out of your control, and you can only report the domains as you find them. BEC scams are much more preventable if you turn on MFA. In this situation, preventing the email breach with MFA enabled would have made this scam far less successful. If you have not done so, turn on MFA as an essential security measure to prevent this because the attacker would have needed more “factors” than just a stole username and password. 

Final Thoughts: Turn on MFA

It is important to educate as many as we can about scams like this. At work, attend staff meetings and share real examples like this. Go beyond the boring corporate training that is obvious, and instead, show real examples that are impacting the organization’s reputation and liability. These stories stick with people and help stop fraud. Ask your community to share their experiences as we did here. 

You are in a difficult position if you are still fighting to turn on MFA in your environment for ALL accounts. If your firm will not listen to Microsoft or experts like our Practical 365 authors, then sharing stories like this and the liability they are opening themselves up to may help move the needle. Being the system administrator in a data breach is a nightmare. Being in that situation where basic steps could have been prevented is even worse.  

Thank you to Chris Cahill & Bryan Patton for their contributions to this video and article.

Check out the Top 10 Security Events to Monitor in Azure Active Directory and Office 365 in this eBook. 

About the Author

Mike Weaver

Mike is a Senior Product Manager at Quest.  Mike specializes in Office 365 tenant-to-tenant migrations and PST migration projects. With a wealth of experience in mergers, acquisitions, and divestitures (MAD), Mike often writes about technology solutions and personnel considerations to ensure both successful integration and adoption.  Mike can also be found on Twitter (@MADMike_365) or from time to time on his blog (


  1. ronda weber

    Mike – I asked Jorge Lopez the same question after his session at the TEC conference and he answered my question. Thanks! Enjoyed your sessions as well!

  2. Ronda Weber

    Mike – We are currently using MFA but would like to deploy the new Push Notification for MFA. Is there an easy way to deploy this. So far I have only been able to deploy once I delete my old MFA authentication account and create the new Microsoft Authenticator account.

Leave a Reply